A five minute check interval detects an outage an average of two and a half minutes after it starts, and up to five minutes in the worst case. Add the confirmation checks most monitors require before alerting, and the delivery time of the alert itself, and the realistic detection budget is ten to fifteen minutes. Whether that is enough depends entirely on one number: what fifteen minutes of downtime costs you.
This article gives you the arithmetic in full, sets it against the uptime targets people commit to, covers the real costs of checking more often, and offers a rule for choosing an interval that is not simply the smallest number your plan allows.
The arithmetic of detection delay
An outage begins at a random moment relative to your check schedule, so the expected wait until the next check is half the interval. A five minute interval gives an average of two and a half minutes and a worst case of five. That is the first component and the one everybody knows.
The second is confirmation. Nearly every monitoring system requires more than one consecutive failure before alerting, because a single failed check is frequently a network blip rather than an outage, and alerting on it produces the false positives that teach people to ignore alerts. If your monitor requires two consecutive failures, that adds another full interval. Three failures adds two. On a five minute interval with a two failure threshold, you are now between seven and a half and ten minutes from outage start to alert generation.
The third is delivery. An email lands in seconds or in minutes depending on the receiving system. An SMS depends on carrier delivery. A push notification depends on the phone being awake. A Slack message depends on somebody looking at Slack. None of this is under your monitoring vendor's control, and it is realistically another one to five minutes before a human being knows. The total for a five minute interval is ten to fifteen minutes from failure to awareness, and that is the number to plan with rather than the interval on the settings page.
Setting that against your uptime target
Uptime commitments turn this from an abstraction into a budget. Three nines, or 99.9 percent, allows about forty three minutes of downtime per month. Three and a half nines, 99.95 percent, allows roughly twenty two minutes. Four nines, 99.99 percent, allows about four and a half minutes per month in total.
Put the detection budget next to those numbers and the problem becomes obvious. A ten to fifteen minute detection delay consumes a quarter to a third of a 99.9 percent monthly allowance before anyone has started fixing anything, and it exceeds the entire monthly allowance for 99.99 percent in a single incident. If you have committed to four nines in a customer contract and you are checking every five minutes, the monitoring configuration alone makes the commitment unmeetable. A one minute interval with a two failure threshold brings detection to roughly two to three minutes plus delivery, which is a different conversation entirely. Our guide to website monitoring practice covers how these pieces fit together across a whole monitoring setup.
What checking more often actually costs
Shorter intervals are not free, and the costs are worth naming rather than assuming away. The obvious one is price, since most vendors tier on check frequency. The less obvious ones matter more.
More frequent checks mean more requests to your origin. For a small site this is irrelevant. For an expensive endpoint, a rate-limited API, or a service billed per invocation, a one minute check from seventeen locations is a meaningful amount of traffic arriving forever. The second cost is false positives: shorter intervals sample more moments, which means they catch more transient blips, and unless your confirmation threshold rises alongside the frequency you will get more alerts about nothing. The third is a subtler version of the same thing. Teams that move to one minute checks without adjusting their thresholds often end up trusting alerts less than they did before, which makes the faster detection worthless.
The honest summary is that interval and confirmation threshold are one decision rather than two. Halving the interval while holding the threshold constant halves your detection time and roughly doubles your exposure to blips. Halving the interval and raising the threshold from two to three keeps the noise steady and still improves detection meaningfully.
A rule for choosing
Start from cost rather than from capability. Work out what an hour of downtime costs the business in revenue, in support load, in contractual credits, and in the less measurable currency of customers who quietly leave. Divide it down to a per minute figure. Then ask what you would pay to remove ten minutes from every incident this year, and compare that to the price difference between check intervals.
For most brochure sites, a blog, or an internal tool, five minutes is genuinely fine and one minute is spending money to feel thorough. For an e-commerce checkout, a payment flow, a login service, or an API other businesses build on, five minutes is too slow and the cost calculation usually justifies one minute immediately. Between those poles, the deciding question is whether anyone is on call. Sixty second detection delivered to a team that reads alerts the next morning is an expensive way to timestamp an outage precisely. Match the interval to your response capability, then improve both together. Worth checking before you assume a shorter interval costs more: some vendors, Odown included, offer one minute checks on every plan and tier on monitor count instead, in which case the interval decision costs you nothing.
Common mistakes in choosing a check interval
Treating the interval as the detection time. The interval is one of three components. Confirmation checks and alert delivery usually double it, and the total is the number that matters.
Committing to four nines while checking every five minutes. A 99.99 percent target allows about four and a half minutes of downtime a month. A detection budget of ten to fifteen minutes makes that target unreachable regardless of how good the infrastructure is.
Shortening the interval without raising the confirmation threshold. More frequent checks sample more transient blips. Without a matching threshold change, the result is more false alarms and less trust in the alerting.
Ignoring the load on the endpoint being checked. A one minute check from many locations against an expensive or rate-limited endpoint is real, permanent traffic. Point frequent checks at a cheap health route.
Buying faster detection without anyone to respond. Cutting detection to two minutes achieves nothing if the alert waits until morning. Interval and response capability need to improve together.
FAQ
How long does it take to detect an outage with a 5 minute check interval?
Two and a half minutes on average until the first failed check, five in the worst case, plus a full interval for each additional confirmation failure required, plus alert delivery. Ten to fifteen minutes end to end is typical.
Is a 1 minute check interval worth paying for?
It is when downtime is expensive and somebody is available to respond. For a checkout flow, a payment service, or an API other businesses depend on, the reduction in detection time usually pays for itself in one incident.
Why do monitors wait for several failures before alerting?
A single failed check is often a transient network problem rather than an outage. Requiring consecutive failures filters those out, at the cost of one additional interval of delay for each failure required.
Does checking more often put load on my server?
Yes, though usually a trivial amount. It matters when the checked endpoint is expensive to serve, rate limited, or billed per request, which is why frequent checks should target a lightweight health endpoint rather than a full page.
Closing thought
The interval on the settings page is not the detection time, and treating it as such is how teams end up with uptime commitments their monitoring cannot support. The real number is the interval plus the confirmation checks plus the delivery, and it is usually two or three times larger than people expect. Work it out once, write it down, and check it against whatever uptime figure appears in your contracts.
Then decide with the cost in front of you rather than the feature list. Odown runs checks from seventeen locations with configurable intervals and confirmation thresholds, so you can set detection to match what an outage actually costs rather than to whatever the default was. One minute checks and all seventeen locations are included on every plan, including the twelve dollar Basic tier, so the interval is a decision about detection rather than about budget. The pricing page shows what separates the tiers.
