Monitoring
How checks and confirmation work
Failure and recovery confirmation cycles that prevent false alerts.
statusloop does not open an incident on the first failed check. Confirmation rules differ slightly by resource type.
Uptime monitors
| Rule | Value | Effect |
|---|---|---|
| Failure confirmation | 2 cycles | Two consecutive failed check cycles before status down and incident open |
| Recovery confirmation | 2 cycles | Two consecutive successes before incident closes |
| Minimum incident duration | 60 s | Incident must be open at least one minute before recovery can close it |
| Slowdown threshold | 5 failed cycles | After five failures, interval drops to 15 minutes until recovery |
With a 15-second scheduler tick, two cycles means roughly 30 seconds of confirmed failure before alerting (plus your chosen check interval for the actual HTTP/TCP probe).
Healthchecks
Healthchecks use expected ping time + grace period instead of consecutive probe failures. See Healthchecks overview.
Servers
Servers are marked down when heartbeats stop. Threshold: max(45 s, interval × 2.5) without a heartbeat. See Server monitoring.
Mute
While muted, monitors skip checks and status is frozen — no new incidents from that monitor until unmute.
Was this helpful?