Short outages recorded as long downtime
Sometimes a very short interruption - say a router restart of a few seconds - is recorded as several minutes of downtime. This page explains why, and what you can do about it.
Why it happens
Section titled “Why it happens”Two things stretch the recorded duration beyond the real interruption:
- The check waits for its timeout. When a server stops responding, the check can’t fail instantly - it waits up to its configured timeout before giving up. A high timeout (say 55 seconds) means each failed check takes nearly a minute.
- Recovery is noticed on the next cycle. Once a monitor is down, the next check happens on its schedule. The moment the site comes back is only observed at that next check, so the gap in between is counted as downtime.
Together, a genuinely brief outage can be recorded as a few minutes. The outage was real - the duration is rounded up by how monitoring works from the outside.
What you can do today
Section titled “What you can do today”- Lower the timeout on the monitor (for example from 55s toward 30s) so a failed check concludes faster and records a shorter outage.
- Keep re-check confirmation on (it is by default) so a single flaky location can’t page you - see How down detection works.
How to verify what happened
Section titled “How to verify what happened”GET /monitor/{id}/span (or expand=spans on a monitor read) reports the exact recorded down span; the
result log (GET /monitor/{id}/result) shows each individual check’s timestamp either side of it, so you can
see how much of the recorded duration is the timeout versus the gap until the next scheduled check.
Coming improvements
Section titled “Coming improvements”We’re improving two things on our side:
- Faster recovery detection - re-testing a down monitor more frequently so the “back up” moment is caught quickly.
- An optional “ignore short outages” setting - a per-monitor threshold so a blip shorter than you choose is not counted or alerted.