Your monitor is green. It has been green all night. But sometime around 2 a.m., your site was down for three minutes while a bad deploy rolled out and rolled back. Your customers hit errors. Some of them closed the tab and didn't come back. You found out about it the next morning — from a user email, not an alert.
A 5-minute polling interval can miss entire outages. And for most teams running free or entry-level monitoring, 5 minutes is the default. Here's the math on what that actually costs you.
How Polling Intervals Create Detection Gaps
With a 5-minute check interval, your monitor fires at T=0, T=5, T=10, T=15, and so on. The checks are evenly spaced — but outages don't schedule themselves around your polling window.
Say your site goes down at T=1 and recovers at T=3. Your next check fires at T=5 — after the outage has already resolved. The check passes. No alert fires. The outage never appears in your dashboard. It's completely invisible to your monitoring system, and the only evidence it happened is in your server logs and your users' frustration.
Now say your site goes down at T=1 and stays down. The check at T=5 catches it — but by then you're already four minutes into the outage. Your alert fires. You wake up. You start investigating. Add another few minutes before any remediation begins. By the time your site is back, the outage might be twelve minutes long — but monitoring only detected it four minutes in.
The Math: Average Detection Lag Is 2.5 Minutes
If outages start at random times, the start of an outage is uniformly distributed across the 5-minute polling window. On average, an outage starts 2.5 minutes after the last check — so the next check arrives 2.5 minutes into the outage.
That's your average detection lag: 2.5 minutes. It can be as low as a few seconds (if an outage starts just before a scheduled check) or as high as just under 5 minutes (if it starts just after one).
And that's just detection. Add response time — the time for a human to wake up, acknowledge the alert, diagnose the problem, and begin remediation — and the total user impact window expands further. A site that is technically down for 5 minutes may not have a fix deployed until minute 10 or 12, because the alert didn't fire until minute 4 or 5.
The short-outage case is the most dangerous. A deployment that causes a 90-second spike of 500 errors is exactly the kind of event that causes user churn without ever appearing in your alerting dashboard. It's also the most common type of outage in practice. A 2-minute outage that starts and ends between two checks never fires an alert — the full impact lands on your users and your monitoring dashboard stays green.
Why This Matters Beyond Just "Downtime"
The business impact of an undetected outage is often larger than the technical impact. Here's what happens in the gap between your site going down and your monitor detecting it:
- Silent churn. SaaS users who hit errors don't always open support tickets. They close the tab. Some percentage of them don't come back. You'll never know the outage caused it — it won't show up in your incident log, only in your MRR graph a few weeks later.
- SEO damage. Googlebot crawls your site on its own schedule. If your site returns 500s during a crawl, those errors get indexed. For a site with significant organic traffic, a few minutes of 500 errors during a crawl can suppress rankings for days.
- Failed webhooks. Any webhook deliveries attempted during the undetected window fail silently. Depending on your retry logic and your customer's integration, those payloads may be lost — or your customer's automation may silently break without anyone connecting it to the outage.
- Delayed incident response. Your on-call team can't start the incident response clock until the alert fires. Every minute of detection lag is a minute of delayed remediation. For a P1 incident with an SLA clock ticking, this matters a lot.
How Much the Interval Actually Matters
The math here is straightforward. At 5-minute polling, your average detection lag is 2.5 minutes and you'll reliably miss any outage shorter than 5 minutes. Drop to 1-minute checks and average lag falls to about 30 seconds — short enough to catch most real-world incidents before users start filing tickets. At 30-second intervals, you're looking at roughly 15 seconds of lag, which means a 90-second deploy spike shows up in your alerts before it's over.
Even at the free tier, Nines provides multi-region coverage — so you know not just that your site is down, but where it's down. That distinction matters for fast diagnosis even when the check interval is longer.
If your application handles payments, real-time data, or any user-facing workflow where a 2-minute outage causes a support escalation, the 5-minute default is working against you.
What You're Not Seeing
Sub-5-minute outages are common. Bad deploys, flapping instances, transient database connection exhaustion — these tend to resolve quickly, often within 2–3 minutes. With 5-minute polling, the majority of them are completely invisible. They don't appear in your incident log. They don't trigger alerts. The only record they leave is in your server logs and, eventually, your churn numbers.
Upgrade to 1-Minute Checks
If detection lag matters to your application — and it should if you're running anything user-facing — consider upgrading to 1-minute check intervals. The difference in detection lag is significant: from an average of 2.5 minutes down to 30 seconds. That's not a rounding error; it's the difference between catching a 90-second outage and missing it entirely.
Sign up for Nines free and get 1-minute checks on your monitors today.