One cycle, eight regions
When a check is due, GeeksUptime writes down every region you selected for that check, then probes each of them exactly once. There are no hidden retries. That keeps latency honest and avoids doubling load on your service.
You set a failure threshold — how many regions must fail before the run counts as down. One bad network path is not an outage unless you say it is.
Example: Checkout · threshold 2 of 8 · London and Frankfurt failing
Up, down, and unknown
A definitive answer from your service — a status code, 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.
- 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. An incident opens on that cycle.
- Unknown — we could not tell. The previous incident state is preserved; nothing is paged.
Incidents
When the threshold is met, one incident opens for that outage — not one per region. 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 the service recovers (definitive successes bring failures back below threshold), the incident resolves itself.
Maintenance windows
Schedule a window for a workspace or specific checks in your timezone. Monitoring keeps recording results the entire time. New incidents and outbound notifications stay suppressed until the window ends. Results still appear in history and exports.
Certificates
Domains are checked daily for expiry and certificate fingerprint changes. Notices route through the same notification groups as uptime. Expiry alerts fire on milestone days before the certificate ends; fingerprint changes fire when the live serial changes.