Four check types, one decision model
HTTP, ping, DNS, and TCP checks all produce the same regional Up, Down, or Unknown outcomes. They feed the same run-level quorum, incident, availability, maintenance, export, report, and alert-routing pipeline.
- HTTP/HTTPS — validate response classes, redirects, GET/POST bodies, and bounded literal content rules.
- Ping — ICMP reachability from Finland.
- DNS — assert A, AAAA, CNAME, MX, NS, or TXT values from all eight regions. Every expected value must be present; extra answers are allowed.
- TCP — open a raw connection from Finland or four Google Cloud regions. The probe sends no application bytes and can passively inspect at most 4 KiB for an optional literal banner rule.
DNS and TCP checks are available on Complete and Ultimate. They accept public targets only. TCP hostnames are resolved and every address is checked again immediately before connection, so a private, reserved, or rebound address is never probed.
One cycle, compatible 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 rejected HTTP response, DNS NXDOMAIN or expected-value mismatch, refused TCP connection, failed content/banner assertion, or ping loss — can move a region to failure. Runner transport/configuration failures, resolver failures, unsafe addresses, worker timeouts, and 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.