How Detection Works
The three-step ladder UptimeHunt uses to turn a single failed check into a confirmed incident — confirmation bursts, history colours, and location-specific problem detection.
How Detection Works
A single failed check, on its own, rarely means a service is down — it could be one probe having a bad second on one network path. UptimeHunt runs every failure through a short ladder before treating it as a real problem, so the difference between "one location had a blip" and "the service is actually down" is visible throughout the app: the coloured history strips, the incident list, and your alerts.
Step 1: an automatic confirmation burst
The instant a check fails, UptimeHunt doesn't wait for the service's normal schedule to come back around. It immediately dispatches extra, independent checks from other probe locations — landing within seconds of the original failure.
This does two things at once:
- If the extra checks come back healthy, the original failure is treated as what it almost always is: a one-off blip from that one location — a network hiccup, a resolver timeout — not evidence the service itself is unreachable.
- If the extra checks also fail, the failure has independent corroboration almost immediately, instead of waiting for the service's normal check interval to slowly build up enough evidence on its own.
You never see this burst as clutter in your check history — the extra checks land in the same window as the original failure and simply confirm (or refute) it.
Step 2: how a bucket's colour is decided
Zoomed-out views — the Services list History column, cron run strips, status-page bars, and the service detail chart's status strip — group many individual checks into time buckets and colour each one, using the same base rule (with one deliberate exception, covered in Step 3):
| Colour | Meaning |
|---|---|
| 🟢 Green | Every probe that reported in this window was healthy — or exactly one probe failed with nothing else backing it up |
| 🟠 Amber (degraded) | At least two independent probes failed in this window, and the failures made up a meaningful share of the checks in it |
| 🔴 Red (down) | Every probe that reported in this window failed — no healthy result at all |
| ⚪ Hollow (missed) | No result arrived for this window — a gap in monitoring data, not evidence the service was down |
Two things are worth calling out:
- A single failing probe never colours a bucket by itself. One location having a bad moment isn't evidence about the target — it's a property of that one machine, one network path, one DNS resolver. A real problem almost always shows up on a second, independent probe within seconds (see Step 1 above); a lone blip doesn't.
- At a wide zoom, a handful of failures out of thousands of checks doesn't count either. A 12-hour bucket covering thousands of checks shouldn't turn amber because two probes each had one bad request somewhere inside it — that's noise, not a degradation worth flagging. Amber requires the failures to make up a real share of the window's traffic, not just a plurality of unlucky probes.
These rules protect against false alarms at a glance. They deliberately do not hide a real short outage: if the alert engine confirms an incident happened inside a bucket — even a brief, total one — that bucket is coloured to match, regardless of how small a share of the wider window it covers. A confirmed incident is the authoritative last word on a bucket's colour on every surface it reaches — with one deliberate exception, covered next.
Step 3: single-location failures are their own signal
Steps 1 and 2 are about breadth — corroboration from other locations. But sometimes exactly one probe location keeps failing while every other location stays healthy. That's not noise — it tells you the problem is specific to a route, an ISP, or that location's path to your service, even though the service is reachable from everywhere else.
UptimeHunt doesn't wait around to find out. The same burst ladder from Step 1 confirms or refutes the failure within seconds, and when the extra checks show the failure is confined to a single location — that probe failing while the rest of the fleet stays healthy — UptimeHunt opens a local-scope incident naming the affected location — for example, "Unreachable from São Paulo since 14:02 — every other location is fine."
This incident behaves like any other: it appears in your incident list and in Needs attention, it can trigger alerts through your configured integrations, and it closes automatically once that location's checks recover. On your public status page, it shows as degraded — visitors see something is off without a false "fully down" alarm.
Related
- Checks — what a single check execution records
- Probes — the distributed agents whose corroboration drives detection
- Incidents — how incidents open and close, severity, and the full lifecycle
- Service Details — where bucket colours and the status strip appear