Introduction
Most uptime products have two moods: green and red. That feels clean until a single region hiccups, a probe times out on your network instead of the customer’s, and the pager fires for an outage that never happened. Teams stop trusting the tool. Then the real outage arrives, and nobody looks.
GeeksUptime treats that as a product problem, not a “tune your thresholds” footnote. A check cycle can end up, down, or unknown — and only a definitive down opens an incident.
The binary trap
Binary monitors collapse three different situations into one red light:
- Your service actually failed for users in that region.
- One path between the probe and your host was bad.
- The monitoring system itself could not finish the question.
Those are not the same night for an on-call engineer. The first deserves a wake-up. The second deserves a quorum. The third deserves humility — and silence.
One cycle, every selected region, once
When a check is due, GeeksUptime records every region you configured for that check, then probes each of them exactly once. There are no hidden retries that quietly inflate latency or double the load on a struggling origin. You choose how many of those regions must report a real failure before the run counts as down. One flaky transit path is not an outage unless you say it is.
That threshold is the product version of “trust, but verify with geography.” Eight regions give you room to require two or three concurrent failures before paging. A single-location check stays honest about what it can prove — and what it cannot.
Unknown is a first-class state
A definitive answer from your service — the status code you asked for, a refused connection, a content match that failed — can move a region to failure. Our own timeouts, transport errors, or unreadable results become unknown.
Unknown never opens an incident, never sends an alert, and never counts against availability.
That is deliberate. If the probe could not tell, pretending it saw an outage invents evidence. If the probe could not tell, pretending the site was healthy invents confidence. Unknown preserves the previous incident state and waits for a cycle that actually finished the question.
- Up — every selected region returned a definitive result, and failures stayed below your threshold.
- Down — enough regions returned a real failure to meet your threshold. One incident opens for that outage.
- Unknown — we could not tell. Nothing is paged.
Incidents track the outage, not the region
When the threshold is met, GeeksUptime opens one incident for that outage — not eight fragmented tickets. It carries the failing locations and the history leading up to the failure. Acknowledge to tell the rest of the team you have it. When definitive successes bring failures back below threshold, the incident resolves itself.
Maintenance windows sit on the same philosophy: keep recording results, suppress new incidents and outbound notifications for the window, and leave history intact for the postmortem you still want to read later.
Why the colours on the site mean status
On the public site and in the product, saturated green, amber, red, and grey are reserved for real monitoring states. Decorative accents use a different colour on purpose. If a marketing page treated every highlight as “healthy green,” the instrument would stop meaning anything the moment you signed in.
Status is a promise. We try not to spend that promise on decoration.
Where to go next
The operational contract — cycles, quorum, certificates, and what webhooks fire — lives in the docs. This post is the why. The docs are the how.
- How monitoring works — the same rules without the essay.
- Webhooks & alerts — what your systems receive when down is real.
- Features — regions, routing, and the rest of the product surface.