Response time, broken down and tracked over months

Five numbers instead of one

A single “response time” hides where the time went. Each check records DNS lookup, TCP connect, TLS handshake, time to first byte and content download as separate figures, per region. That split is what turns “the site feels slow” into a sentence you can act on: a long DNS time is a resolver or TTL problem, a long connect is distance or an overloaded load balancer, a long TLS time is certificate chain or session reuse, a long first byte is the application or the database behind it, and a long download is page weight.

For the headline figure, the monitor page charts total time per region over a range you pick, so a Singapore line sitting 170 ms above London is visible at a glance. Most of that gap is physics and no amount of server tuning removes it; a CDN or a nearer origin does.

Why one slow request does not page you

An alert on “response time above 2 seconds” fires on every single slow request, and every site has some. A response-time rule on Tenium is evaluated over a rolling window of recent checks across the regions in scope, not on one sample, and the documented default reads that window as a 95th percentile. In plain terms: a lone outlier is absorbed, but when a meaningful share of requests is slow, the figure rises and the alert fires.

A worked example. A shop usually answers in 400 ms and you set the threshold at 1,500 ms. A cache purge makes one check take 4 seconds and the next several come back at 420 ms: nothing happens. A database starts struggling and most requests in the window take 1,800 ms or more: the rule trips and you get a degraded alert, before the site is down. Response-time alerts are part of Pro and Agency. Every plan gets the charts.

Scoping a rule to where your customers are

Thresholds default to all regions, but you can narrow a rule to one. If your customers are in Singapore, alert when the Singapore p95 exceeds 2 seconds and ignore London. If they are in Estonia, do the opposite. Pick the threshold from the baseline, not from a round number: look at two weeks of data, take the usual p95, and set the alert at roughly double. Tighten it later if it never fires.

• Under 200 ms time to first byte from the user’s own region: good.
• 200 to 500 ms: acceptable for dynamic pages.
• Over one second: the range in which visitors start to leave.
• Cross-continent requests add around 100 to 250 ms of unavoidable latency, so compare like with like.

Quiet hours and flapping

A slow site is rarely worth waking someone for. Response-time alerts are classed as non-critical, so a contact’s quiet hours delay them until morning, while downtime alerts are never delayed. Together with the p95 rule this keeps the noisy category from drowning the one that matters.

Slowness can also be caused by something you do not control. When an incident has an upstream provider behind it, such as a CDN or a payment API, the alert says so, so you can tell a client the real cause.

What ends up in the client report

The monthly report includes a response-time chart per monitor group and lists the slowest monitors, with month-over-month change in the summary. For an agency this is often more persuasive than uptime, because a site that is “up” at 99.98% and 3 seconds slow is the thing the client actually complains about. The branded PDF is a Pro feature, one report per account, and Agency gets one per client; Starter gets a plain summary email. See client reports.

Limits worth knowing

Checks are synthetic: they measure from our data centres, not from a visitor’s phone, so they show server and network performance rather than browser rendering or Core Web Vitals. The fastest check interval is 1 min on Starter and 30 s from Pro, so a window of ten recent checks spans roughly 10 minutes at the Starter interval. The free response time test gives you a one-off reading before you commit to monitoring.