How often should an uptime monitor check your site? Less than the interval decides

Every uptime monitoring vendor sells the check interval as the headline number. Free plans check every five minutes, paid plans every minute, the top plan every thirty seconds. The implied promise is that a one-minute interval means you learn about an outage within a minute.

A one-minute interval does not mean that. The interval is one term in a sum, and on most setups it is not the biggest one. The rest of this post works through the sum with real numbers, so you can pick an interval for the right reasons instead of buying the fastest one on the pricing page.

How often should an uptime monitor check?

A monitor should check every 60 seconds for anything customer-facing, and the interval is only one term in detection time.

• Sixty seconds for anything a customer or another system touches: your app, your API, your login page, your checkout.
• Five minutes for things nobody gets paged about: a marketing site behind a CDN, a docs site, a staging environment.
• Thirty seconds only when you have measured that thirty seconds of earlier detection is worth something to you, and your service can absorb the extra probe traffic without rate limiting it.

The interval is only one term in the detection time. A five-minute monitor that confirms a failure on its next scheduled probe reports a hard outage more than ten minutes after it started. A one-minute monitor that waits out a fixed confirmation window adds that window on top of the interval.

How long does it take to detect an outage?

Detection time is a sum of four steps, not the interval alone. Say your server stops answering at time zero. Before an alert reaches you, four things have to happen in order.

1. The next probe has to come due. If the last probe ran just before the failure, that is a full interval of waiting. On average it is half an interval.
2. The probe has to give up. A server that returns a 503 fails in under a second. A server that hangs makes the probe wait for its timeout. Ours is ten seconds; most vendors sit between five and thirty.
3. The failure has to be confirmed. Any monitor worth using does not alert on a single failed probe, because a single failed probe is very often the monitor's own network hiccup, not your outage. Confirmation means the failure has to persist. The questions are how long, and when the probe that settles it runs.
4. Enough locations have to agree. If you require two regions to confirm before paging (you should, for anything that pages a human), each region runs its own confirmation.

Then the alert itself has to be delivered, which is usually seconds but is not zero.

Step three is the one the pricing pages skip. A lot of monitors confirm by simply waiting for the check's next scheduled run, which means confirmation costs a second full interval. Ours waits for the failure to last three minutes. The real data is why: nearly every brief failure between one probe region and a healthy service is over inside a minute. A fixed three-minute window rules out almost all of them, while a real outage keeps failing straight through it.

What do the worked numbers look like?

A 60-second monitor reports a hard outage in 140 to 261 seconds, depending on how it confirms. The table assumes the worst case: a hanging server, a ten-second timeout and one region.

"Next probe" confirmation waits a full interval for the second probe. "Three-minute streak" is what our fleet does. The region goes down on the first failed probe that lands at least three minutes after the first failure. When the normal schedule would land a few seconds short of that mark, one more probe from the same region is scheduled for just after it.

On average the wait for the first probe is half an interval, so a 60-second monitor reports a hard outage about three and a half minutes after it starts. On a five-minute interval the second probe already lands past the three-minute mark, so nothing is added.

Three things fall out of that table.

The five-minute plan is a ten-minute plan when confirmation waits for the next scheduled probe. That is the plan most people are on, because it is the free one, and most people have never been told the real number.

Halving the interval from 60 to 30 seconds buys thirty seconds on a monitor with a three-minute streak, and costs twice the probe traffic. That is a fine trade for a payment endpoint. It is a pointless one for a blog.

The confirmation rule buys more than the interval does, in both directions. A three-minute window costs more than a thirty-second interval saves, and it is the reason a page that reaches you is almost never a blip. If a vendor will not tell you how they confirm a failure, that is the question to ask before you compare intervals.

For a server that fails fast instead of hanging, drop the timeout terms: a 60-second interval with a three-minute streak confirms a 503 in about 241 seconds worst case, and about 211 seconds on average.

Why not check every ten seconds?

Because the failure rate of the probes does not go to zero, and the probes are traffic.

Every probe is a chance for a transient failure that has nothing to do with you. Examples are a dropped packet between the probe host and your edge, a DNS resolver that took too long once, or a route that flapped for two seconds. The confirmation rule exists to absorb those. Multiply the probe count by six and you multiply the number of those events by six. Confirmation still catches nearly all of them, but "nearly all" of a bigger number is a bigger number of pages at 3 a.m. for nothing.

The probes also hit your service. Four regions at a ten-second interval is 24 synthetic requests a minute per monitor, forever. On a busy service that is noise. On a small one it can be a meaningful share of traffic. Anything behind a WAF or rate limiter sees exactly the pattern that gets an IP challenged or blocked. When that happens the monitor reports you down and you are not, which is the false positive you were trying to avoid, delivered by a different route.

There is a reason checks do not run at ten seconds by default. A sensible interval is one the target can tolerate indefinitely, and a check should confirm a failure before it says anything. Those rules apply to every check on a paid plan.

What makes alerts fast and trustworthy?

Confirmation rules and region quorum decide real alert speed, more than the interval. Here is exactly what our probes do, because the design is more useful than the interval number.

• A region flips to down only after it has failed continuously for three minutes, every probe since the first failure failing. One success starts the count over. Until then a failure updates the raw history and nothing else.
• Once a failing streak is within a minute or so of the three-minute mark, the same region re-probes just after it instead of waiting for the check's interval to come around again. That is what keeps a 60-second check at about three minutes instead of four. A blip still cannot open an incident on its own; the re-probe records an ordinary success if the target has recovered.
• Recovery flips on a single successful probe. Being slow to declare an outage is caution. Being slow to declare recovery is just wrong for longer.
• Operator alerts can require a quorum of regions. Set the threshold to two and a single region seeing failures pages nobody, while the public record still shows that region as down. Slack, PagerDuty, and webhooks fire once a second region independently confirms. A regional routing problem near one probe host stops being your problem to wake up for.

None of that is exotic. The rules are also not what "checks every minute" tells you, and they decide whether you trust the alert when it arrives. The longer version of the false-positive and false-negative reasoning is in the uptime monitoring guide.

Which interval fits which endpoint?

Match the interval to what the endpoint is for.

Customer-facing pages and APIs: 60 seconds. This is the fastest interval on Free and Growth (Scale and MSP go down to 30 seconds), and the reason is in the table. A confirmed alert lands about three and a half minutes after a hard outage starts, four at worst, which is still before most customers get around to emailing you and long after every blip has cleared.

Endpoints other systems depend on: 60 seconds, 30 if you have measured why. The extra thirty seconds can be worth it if a partner integration polls you, or your own mobile app fails closed when an API is unreachable. Do the arithmetic with your real traffic first. The downtime cost calculator is there for exactly this, and it will often tell you the thirty seconds is not the expensive part.

Marketing sites, docs, anything behind a CDN: 5 minutes is fine. A CDN edge answering 200 mostly proves the CDN is up, and a five-minute check confirms that comfortably. The check is worth having (TLS expiry and DNS mistakes show up here), but nobody should be paged for it.

Cron jobs and background workers: not a probe interval at all. A job that runs every hour cannot be polled; there is no URL to probe. Use a heartbeat check: the job pings a URL when it finishes, and the alert fires when the ping is late. The interval is the job's schedule plus a grace period, and it lives on the job, not on the monitor.

Certificates and domains: once a day. A certificate expiring in twelve days does not need to be discovered every minute.

Why do vendors charge more for shorter intervals?

Vendors gate the interval by plan because it is the easiest number to gate. UptimeRobot's pricing page, at the time of writing, lists five-minute checks on the free plan, one-minute checks on paid plans, and thirty seconds on the top plan. Most of the market looks similar.

We considered the same ladder when we built ours and decided against slowing the free tier down. Every free check on RealUptime can run at 60 seconds from all four core regions (Virginia, California, Frankfurt, Tokyo), with the three-minute failure rule and the re-probe described above. The free tier includes ten monitors and no card. The Scale plan unlocks a 30-second floor, which is a real capability the fleet had to prove it could honor before we sold it, not a number we picked to make the free tier look slow.

We will be honest that this is not a moat. Any vendor can change a number on a pricing page. What we think is harder to copy is publishing how the confirmation actually works, keeping a public register of the ways our own monitor can fail, and showing per-region results instead of one green badge that hides them.

What is the checklist?

Six steps cover the decision.

1. Find out how your monitor confirms a failure. Next scheduled probe, a fixed window, or a single re-check? Add that to your interval in your head.
2. Set anything customer-facing to 60 seconds. Leave marketing pages at five minutes.
3. Turn on multi-region checks, and require two regions before anything pages a human.
4. Check the timeout. Ten seconds is a sensible default; anything above thirty is hiding slow-death outages from you.
5. Move cron-style work to heartbeats instead of trying to probe it.
6. Run the downtime cost numbers before paying for 30-second checks. If the answer says yes, pay for them on that one endpoint, not on everything.

To see the three-minute rule and the re-probe on your own endpoint, use Monitor's free tier. It runs ten checks at 60 seconds from four regions. The per-region timeline shows every probe, including the ones that got ruled out.