Response Time Monitoring: What to Measure and When to Alert.

"The site is slow" is one of the most common complaints and one of the hardest to act on - unless you have been measuring response time all along. A response-time history tells you whether today is really slower, since when, from where, and which part of the request got slower.

Key takeaways

• Response time is the sum of several phases: DNS, TCP connect, TLS, server processing and transfer.
• Track percentiles or ranges, not only the average - averages hide the slow requests users notice.
• Compare locations: slow from one city but not others points at the network, not the server.
• Alert on sustained slowness above a threshold, separately from downtime.
• Watch the trend after every deploy; slow creep is easier to fix early.

What a response time measurement includes

For an HTTPS check, the total time splits into phases:

You can see the same breakdown yourself:

curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.com/

Note that monitoring response time is the time to fetch one URL, not the time a browser needs to render the full page with images and scripts. Both matter; they are measured differently. See why monitor and browser times differ.

Averages hide the pain

If 95 requests take 200 ms and 5 take 6 seconds, the average is about 490 ms - which describes nobody's experience. Better views:

• Percentiles (p50, p95, p99): "95% of checks were faster than X".
• Min/max bands per hour, which show spikes.
• Per-location lines, which show whether one region suffers.

Using locations to find the cause

noc724 records response time per check and per location, so these patterns are visible on the monitor's chart. See response time monitoring.

Setting slowness alerts

1. Look at a normal week and note typical and peak values.
2. Set a threshold well above normal peaks - for example 2-3x the usual p95.
3. Require persistence - several consecutive slow checks, so a single spike doesn't alert.
4. Send it to the team channel, not the pager, unless slowness makes the service unusable.

Keep the request timeout higher than the slowness threshold; otherwise "slow" becomes "down" and you lose the distinction.

What good looks like

There is no universal target, but for orientation:

• Server response (TTFB) under 200-500 ms for dynamic pages is comfortable.
• API endpoints used interactively should usually answer within a few hundred milliseconds.
• Static files served by a CDN should arrive in tens of milliseconds near the edge.

Your own history and your users' tolerance matter more than any published figure.

Frequently asked questions

• Why is the first check after a quiet period slower?

  +

  Caches and connection pools are cold, and some platforms put idle apps to sleep. If cold starts matter for your users, keep the service warm or move caching closer.

• Does a faster check interval make response time data better?

  +

  It gives more points and catches short spikes, but trends are visible with 1-5 minute intervals too.

• Should I alert on response time or only on downtime?

  +

  Both, separately. Downtime needs immediate action; slowness usually needs investigation during working hours unless it is severe.