Most uptime monitors quietly round your reality. They poll every 30 seconds — or every two minutes on a free plan — and then report outages in seconds, giving the illusion of precision. But you cannot report what you never measured. If you check once every 30 seconds, a 4-second outage is either invisible or smeared across a 30-second window.
The interval floor is a measurement problem
Think of a check interval as the resolution of a camera. A coarse interval is a blurry photo: it can tell you something broke, but not exactly when it started, how long it lasted, or whether it happened twice. A fine interval is a sharp one. The difference isn't cosmetic — it changes what you're able to know.
Here's the arithmetic. Suppose your service has a 20-second outage:
- Every 2 minutes (120s): roughly a 1-in-6 chance any single check even lands inside the window. Most of the time, the outage simply never happened as far as your records are concerned.
- Every 30 seconds: you'll likely catch it, but the best you can say is "down for somewhere between 1 and 60 seconds." The true 20 seconds is a guess.
- Every 1 second: recorded as a ~20-second event with a precise start and end.
The brief, intermittent blips are exactly the failures that erode customer trust — and exactly the ones a coarse interval is worst at seeing. Long outages get caught either way; it's the short ones where resolution decides whether you ever find out.
Why exact-second timelines matter
Precision pays off in three concrete places:
- Incident response. A tight detection loop means alerts fire while the incident is still small, before it cascades into something bigger. Every minute of detection lag is added straight onto your total time-to-recovery.
- SLAs and credits. "Down for 4.2 seconds" is a defensible, auditable number. "Down for about a minute" is a guess — and coarse intervals tend to round against you, costing real money in credit disputes.
- Trust. Showing exact downtime on a public status page signals that you actually measure what you claim, rather than publishing a suspiciously perfect chart that nobody believes.
There's also a compounding effect on your historical uptime. A year of coarse measurements doesn't just have fuzzy individual incidents — it has a fuzzy total. Every short outage that slipped between checks is a small upward bias in your reported availability. Fine-grained measurement removes that bias, so the number you put in front of customers is the number that actually happened.
Fast polling needs confirmation
Polling fast naively means more false positives: a single failed check from one location is often a network hiccup, not a real outage. If you page someone every time, responders quickly learn to ignore alerts — which defeats the point of detecting fast in the first place.
The fix is confirmation before declaring DOWN. PingInsight checks from three live regions — us-east-2 (Ohio), us-west-2 (Oregon), and eu-west-1 (Ireland) — and confirms an outage only when at least two of the three agree, combined with a consecutive-failure threshold. That filters out single-probe blips while still catching genuine outages within seconds. The aim is alerts that are fast and almost always real, because those are the ones people actually answer.
What to do with the resolution you gain
Higher resolution is only worth it if you act on it. The natural progression: detect fast and confirmed, then wire a confirmed outage to open an incident, notify on-call, and update your status page automatically — auto-resolving with the exact downtime when service recovers. The precision then flows all the way through to the number your customers see.
If you've been living with a coarse interval, the place to start is measuring your most important endpoint finely enough to actually see its short outages. Read the practical guide to uptime monitoring for the full setup, or see the uptime monitoring feature page for how the engine works.