The degraded latency threshold

Up or down isn't the whole story. A system that answers every check in six seconds is technically up and practically broken for the people using it. The Degraded threshold (ms) field gives each monitor its own definition of "too slow": any successful check whose response time exceeds the threshold is marked degraded, and the monitor shows amber instead of green — slow, but up. (For the underlying concept, see what is latency.)

How it works

A Service class picker sits beside the field: pick what this monitor watches — a website, a payment flow, an in-region TCP service — and UpAll fills in a sensible number for you; pick Custom to type your own, or Off to disable degraded detection outright (more on that below). Each check type opens on its own recommended class the moment you pick it: HTTP starts at Website (content page), 2,000 ms; TCP port at In-region service, 500 ms; Ping at In-country host, 100 ms. On each check:

• Success, faster than the threshold → the check is healthy; the monitor is Up (green).
• Success, slower than the threshold → the check is degraded; the monitor shows Degraded (amber).
• Failure → the check counts toward the incident streak, whatever the timing.

Degraded is a signal, not an alarm. No incident opens and no email is sent when checks run slow — the threshold changes what you see, not who gets woken up. Slow responses surface as amber on the live status wall and monitor lists, as degraded periods in the uptime timeline, in the degraded tile on the monitor page, and on status pages — while the incident machinery stays quiet. That's deliberate: slowness is usually a trend to investigate, not a fire to fight, and mixing it into outage alerts buries the real fires. See monitor statuses explained.

Per-type maximums

The gap is principled. A ping round trip is pure network time, so anything approaching two seconds already means a saturated link or a struggling device — a higher threshold would define the problem away. HTTP and TCP times include real service work, so slower can still be legitimate; their ceiling sits just under the fixed 10-second timeout, past which a check is a failure anyway.

Choosing a value

The recommended class for each check type is a solid starting point — it's built from real-world reference points, not a guess. Two refinements still pay off:

• Set it from your baseline, not from hope. Let the monitor run, look at the latency chart, and place the threshold above normal variation but below "users are complaining" — the p95 line is a good anchor (percentiles and p95 explained). Switch the Service class to Custom to move off the recommended number.
• Go lower still for very quiet LAN gear. The Ping class already starts at 100 ms; if a device typically answers in single-digit milliseconds, tightening further (Custom, 20–50 ms) catches congestion sooner.

Disabling latency as a health signal

Pick Off in the Service class picker and latency stops being treated as health: no check is ever marked degraded, and the monitor only moves between Up, Down, Paused, and Unknown. The Degraded threshold (ms) field itself is read-only whenever a class other than Custom is driving it — Off is what actually turns detection off, not an empty box. Response times are still measured and charted — you lose nothing historically (reading monitor charts).

Off makes sense for targets that are slow by design — a backup link, a distant site — where amber would be permanent and meaningless. For anything client-facing, keep a threshold: it's the earliest warning you get, and it often arrives days before the outage.