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.

It does not. The interval is one term in a sum, and on most setups it is not the biggest one. 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.

The short answer

• 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.

If you take one thing from this post: a monitor that confirms a failure on its next scheduled probe is roughly twice as slow as its interval suggests. A five-minute monitor with that confirmation rule tells you about a hard outage more than ten minutes after it started.

Detection time is a sum, not an interval

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 a second probe. The question is when that second probe 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. Others fire a dedicated re-check a few seconds after the first failure. That single design choice matters more than the interval you paid for.

The worked numbers

Worst case, hanging server, ten-second timeout, one region. "Next probe" confirmation waits a full interval for the second probe; "fast re-check" runs the second probe five seconds after the first failure, which is what our fleet does.

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 fast re-check, 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. Going from next-probe confirmation to a fast re-check at a fixed 60-second interval saves 55 seconds. Going from 60 seconds to 30 seconds at a fixed confirmation rule saves 30. 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 fast re-check confirms a 503 in about 65 seconds worst case, and about 35 seconds on average.

Why not just 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: a dropped packet between the probe host and your edge, a DNS resolver that took too long once, 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, and on anything behind a WAF or rate limiter it is 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 the fleet checking 900-plus public services for our free outage pages does not run at ten seconds. It runs at intervals the target services can tolerate indefinitely, and it confirms before it says anything. We wrote up how that fleet decides a service is really down in Outage report #1, and the same rules apply to every check on a paid plan.

Where the real speed is: confirmation and quorum

Here is exactly what our probes do, because the design is more useful than the interval number.

• A region flips to down only after two consecutive failed probes. One failure updates the raw history and nothing else. This rule has been in place since the first commit and has never been loosened.
• After a first failure, the same region re-probes about five seconds later instead of waiting for the check's interval to come around again. That is what turns the 140-second row into the 85-second row above. A blip still cannot open an incident on its own; it just gets ruled in or out faster.
• 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. It is also not what "checks every minute" tells you, and it is the part that decides 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.

Pick the interval by what the endpoint is for

Customer-facing pages and APIs: 60 seconds. This is the floor we set for every check on every plan, free included, and the reason is in the table. With a fast re-check it lands a confirmed alert inside a minute and a half worst case, which is faster than your customers will get around to emailing you.

Endpoints other systems depend on: 60 seconds, 30 if you have measured why. If a partner integration polls you, or your own mobile app fails closed when an API is unreachable, the extra thirty seconds can be worth it. 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.

The interval as a pricing lever, and where we landed

Vendors gate the interval by plan because it is the easiest number to gate. UptimeRobot's help documentation, 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 two-failure confirmation and the fast re-check 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.

A checklist you can use today

1. Find out how your monitor confirms a failure. Next scheduled probe, or a dedicated re-check? Double your interval in your head if it is the former.
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.

If you want to see the two-failure rule and the fast re-check working on your own endpoint, Monitor's free tier runs ten checks at 60 seconds from four regions, and the per-region timeline shows every probe, including the ones that got ruled out.