Response time monitoring: catch slow before it becomes down

What the number measures

For HTTP-based monitors Tenium starts the clock when the request goes out and stops it when the response body has arrived, reading up to roughly 1 MB. That is a time to the full response, not a time to the first byte, so it follows what a visitor perceives more closely. TCP and ping monitors store their own connect and round-trip times, and DNS monitors store the lookup time.

Every plan stores the number for every check and charts it. What changes with the plan is the alerting: a slow threshold with a degraded incident is on Pro ($29) and Agency ($59), alongside the 30-second interval.

How the slow threshold decides

You give a limit in milliseconds. Tenium averages the last three checks and, when the average is above the limit, opens a degraded incident, not a down one. Averaging three values means one cold start or one noisy request does not page anyone, while a real regression is still caught within a few minutes at a one-minute interval.

Set the limit from evidence. Let the monitor run for a week, read the chart, and choose about twice the usual value. A limit at the median alerts every afternoon. Remember the checks come from several regions: the farthest region reads slower than the nearest, so the limit has to hold for the farthest one.

Slow is a different incident from down

A timeout fails the check outright, so a response that takes longer than the monitor's timeout is down, not slow. The slow band is everything between normal and the timeout, and that is where databases under load, exhausted worker pools and failing third-party calls live for hours before they fall over.

Treat the degraded alert as a prompt to look at load, the database and upstream APIs, in that order. If it correlates with a provider incident, a third-party feed will say so. The response time test is a quick way to see the number from the live regions before you pick a threshold.