Check interval sets a hard floor on how fast any monitor can detect an outage: on average, detection lags the true start of an incident by half the interval, and worst case by the full interval. A 2-minute interval means you know within 2 minutes at worst; a 10-minute interval means up to 10 minutes of blindness on every single incident, and short incidents can fall entirely between checks and never be seen at all.
That sounds like a small difference until you put real incidents and real revenue against it. Here is the math.
How does check interval limit detection speed?
A monitor only learns anything at the moments it checks. If checks run every N minutes and an outage starts at a random moment, the next check lands, on average, N/2 minutes later, and up to N minutes later in the worst case. No amount of alerting speed downstream can recover that time; it is lost before the monitor knows anything happened.
- 2-minute checks: average detection floor 1 minute, worst case 2 minutes.
- 5-minute checks: average 2.5 minutes, worst case 5.
- 10-minute checks: average 5 minutes, worst case 10.
Can a longer interval miss an outage completely?
Yes, and it happens more than people expect. Any outage shorter than the check interval can start and end entirely between two checks, in which case the monitor records unbroken uptime while customers saw errors. A 10-minute interval is structurally blind to every incident under 10 minutes and sees incidents between 10 and 20 minutes only if the timing happens to cooperate.
Short incidents are not hypothetical. In StatusBird's 90-day dataset (84 services, as of July 2026), Omnisend logged 2 incidents averaging just 2 minutes each, ShipMonk had a 12-minute incident, and Afterpay logged 2 incidents averaging 14 minutes. Under a 10-minute check interval, most of those would likely never have been recorded; under 2-minute checks, they were.
Walk through it: an 8-minute payment outage
Suppose your payment provider fails for exactly 8 minutes during a busy evening.
| Check interval | What the monitor sees | When you find out |
|---|---|---|
| 2 minutes | 3 or 4 failed checks; incident recorded with tight start and end times | Within 2 minutes of the start, with 6+ minutes left to react |
| 5 minutes | 1 or 2 failed checks; duration blurry | Up to 5 minutes in, with as little as 3 minutes of incident left |
| 10 minutes | Often zero failed checks; incident may never be recorded | Possibly never; you learn from customer emails, if at all |
The 2-minute row is the only one where the alert arrives while acting still matters: pause ad campaigns, post a banner, switch on the backup processor. It is also the only row that leaves a defensible record for an SLA credit claim, because with 10-minute checks even a detected incident has start and end times each uncertain by up to 10 minutes.
Does a few minutes of detection really cost revenue?
During normal traffic, maybe modestly. During peak traffic, unambiguously. In a BFCM flash sale your store does a normal day's revenue in hours, so each minute of undetected checkout failure carries many times its usual cost, while your ads keep buying clicks that land on errors. The interval you chose in March decides how many of those minutes you eat in November; that is why the BFCM readiness guide treats monitoring cadence as a checklist item, and why the downtime cost calculator prices downtime per minute, not per incident.
Do long outages make the interval irrelevant?
No, for two reasons. It is true that many incidents are long: in the same 90-day dataset, the median service-level average incident duration was 166 minutes, and the average incident overall ran about 352 minutes. For those, any interval eventually notices. But first, the damage is front-loaded, and the difference between reacting at minute 2 and minute 10 is real money at the exact moment reacting helps most. Second, the short-incident blind spot never goes away: a stack that only suffers brief blips under a coarse interval looks perfect while quietly failing customers. Interval choice is one of the four measurement levers that make uptime numbers differ between sources, covered in how uptime is measured.
What interval should a store actually use?
For revenue-touching services (storefront, platform, payments, checkout dependencies), 1-to-2-minute checks are the practical standard: fast enough that detection delay stops being the bottleneck, without meaningfully burdening anything. For lower-stakes services, 5 minutes is defensible. What is hard to defend is protecting a store with the 10-minute-plus intervals common on free tiers and never knowing what they failed to see; the free-tier trade-offs are laid out honestly in free uptime monitoring tools for small stores. StatusBird runs 2-minute checks on all 84 services it monitors, on every plan, which is exactly why its dataset contains 2-minute incidents at all.
Detection speed you can actually act on
StatusBird checks every monitored service every 2 minutes on every plan, so you hear about an outage while reacting still saves revenue. Start free with 3 services.
Start monitoring free