Response Time Monitoring: Phases, Percentiles, Regions

Response time monitoring records how long a service takes to answer a request, sampled on a schedule from outside your network. Done well it catches degradation days before it turns into an outage. Done the usual way, with one average from one location, it tells you almost nothing useful about what your users experience.

What does the number actually include?

Response time is a sum of phases, not a single event. For an HTTP check it covers DNS resolution, the TCP connect, the TLS handshake, time to first byte and the content download. Site24x7's knowledge base spells out the same chain, and the ordering matters because each phase blames something different.

Phase	What a slow value points at
DNS resolution	Resolver or a short TTL on a cold record
TCP connect	Network path, packet loss, an overloaded load balancer
TLS handshake	Certificate chain length, an OCSP fetch, an old cipher config
Time to first byte	Your application, the database, a cold serverless start
Content download	Payload size, compression, the last mile

Without the split you get one number and a shrug. With it, a 900 millisecond result resolves to "the TLS handshake takes 400 milliseconds because the chain has an extra intermediate", which is a fixable sentence. Google's web.dev guide to TTFB covers the server-side half of that chain in more depth.

Response time, latency, and page load time

These three get used interchangeably and they measure different things. Latency is the travel time for a packet to reach the server and come back, with no processing included. Response time adds the server's own work. Page load time adds everything the browser does afterwards: parsing, subresources, scripts, rendering.

Metric	Measures	Typical tool
Latency	Round-trip network time	ICMP ping, TCP connect timing
Response time	Network plus server processing	An external HTTP or API check
Page load time	Everything up to a rendered page	A real browser or field data

OpenStatus documents the first distinction clearly, and Pingdom's write-up covers the second. An external check reports the middle row. It does not render JavaScript, so treat a fast response time as necessary rather than sufficient.

Why does an average response time mislead?

Because the average is dominated by the requests nobody complains about. If 95 out of 100 requests return in 120 milliseconds and five take four seconds, the mean is 314 milliseconds and looks healthy. The five users who waited four seconds are the ones filing tickets.

Percentiles fix this. Response-time history here retains p50, p95 and p99 for every monitor, and the gap between p50 and p99 is the real signal. A p50 of 120 milliseconds next to a p99 of 4 seconds means a long tail, usually a cache miss path, a cold start or an unindexed query. A p50 and p99 that move together mean the whole service is slowing down.

We prefer alerting on p95 over a fixed threshold on every sample. A single slow check is noise. A p95 that crosses your target and stays there for three intervals is a trend, and only the second one deserves to wake someone.

Setting up response time monitoring that pages you correctly

Set an explicit slow-response threshold on the check rather than eyeballing a graph. This monitor fails on a non-200 and separately warns when a successful request gets slow:

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "checkout api",
    "type": "api",
    "target": "https://example.com/api/checkout",
    "intervalSec": 30,
    "expectedStatus": [200],
    "responseTimeThresholdMs": 800,
    "regions": ["london", "sydney"]
  }'

Two details are worth setting deliberately. The interval decides your resolution: 30 seconds on paid plans, 1 minute on the free tier as of September 2026. The region list decides what the number means at all, and a check run only from London says nothing about a user in Sydney.

Slow-response alerting is a paid feature as of September 2026. The free plan still records the full waterfall and the history, so a degradation is visible on the chart. The alert itself needs the Individual plan or above.

How often should the check sample?

Sampling frequency sets the smallest slowdown you can see. A one-minute interval gives 1,440 samples a day, which is plenty to build a stable p95 but coarse enough to miss a two-minute spike during a deploy. A 30-second interval doubles the resolution and doubles the noise, so tighten the confirmation rules at the same time.

There is a second cost that rarely gets mentioned. Every check is real traffic against a real endpoint, and a 30-second check from six regions is 17,280 requests a day. Point the monitor at a lightweight health route rather than at a page that hits the database, or you will be measuring the load you created.

For most services we would start at 60 seconds and watch a week of p95 data. Move to 30 seconds only on the endpoints where a minute of blindness costs real money. Checkout and login qualify. A marketing page does not.

Keep the interval consistent once you pick it, because changing it mid-quarter rewrites the shape of your history. A percentile computed from 1,440 daily samples is not comparable to one computed from 2,880.

Where should the response time monitoring threshold sit?

Start from the user, not from the graph. A synchronous API call inside a checkout flow should answer in under 500 milliseconds. A dashboard aggregation that runs once per page can take 2 seconds. A webhook receiver just needs to beat the sender's timeout, which is often 10 seconds.

In our testing the most useful first threshold is the current p95 rounded up, not a number from a blog post. Watch it for a week, then tighten it. Setting 200 milliseconds on a service that lives at 600 produces a week of alerts and a muted channel, which is worse than no monitoring at all.

Run the check from at least two of the six probe regions available as of September 2026, and compare rather than average them. A response time that is 120 milliseconds from Los Angeles and 900 milliseconds from Singapore is a CDN or routing problem, not an application problem. Egress addresses for each region are listed on the probe IPs page.

Common mistakes

Alerting on every slow sample. One 900 millisecond check on a service that normally answers in 200 is a blip. Require consecutive breaches, and confirm from a second region first, which is the same logic behind cross-region quorum confirmation.

Comparing regions as one blended average. Blending Sydney into a global mean hides the region that is actually broken. Keep the per-region series and read them side by side.

Treating a fast response as a healthy service. A 200 status returned in 80 milliseconds can still be a cached error page or an empty result set. Add a keyword or JSON assertion so the check reads the body, and remember that saturation inside the process stays invisible to any external probe. That limitation is covered in the post on the four golden signals.

Chasing a number you cannot sustain. Availability targets have the same trap, as the five nines math shows.

Good response time monitoring is three decisions: measure the phases and not just the total, report percentiles and not the mean, and compare regions instead of blending them. Get those right and a slow database index shows up as a p99 drift on a Tuesday rather than as a pager alert on Saturday night.

You can set the first check up in a few minutes on the free plan, which includes 10 monitors and a one-minute interval as of September 2026.