The uptime monitoring interval is the gap between two checks of your site, and it sets the longest you can be down without knowing. A 5-minute interval means up to 5 minutes blind before the first failed check, and with the usual two-failure confirmation, up to 10 minutes before an alert. A 30-second interval cuts that to about 1 minute.
This post does the maths for every common interval, shows how confirmation checks multiply the delay, and ends with a decision table so you can pick a number for each site instead of taking whatever a free plan gives you.
How the check interval sets your worst-case detection time
An uptime monitor does not watch your site. It samples it. Every N seconds a probe sends an HTTP request, waits for the response, and records up or down. Between samples, nothing is known.
If your site fails at a random moment, the next check could be due in one second or in the full interval. So for a single check with interval I:
- Worst-case detection delay: I (the site went down just after a successful check)
- Average detection delay: I / 2 (failures are spread evenly across the interval)
- Add: the request timeout for a hanging server (often 10 to 30 seconds) and alert dispatch time (seconds for email, Slack or a webhook)
Some vendors, including Uptrends in its check interval explanation, define the interval as the time between the end of one check and the start of the next. A slow check then stretches the real cycle beyond the nominal interval: a 10-second check on a 1-minute interval produces roughly 70-second cycles. It is worth knowing how your tool counts.
Detection delay by interval: the table
The table assumes a single failed check is enough to alert, which is rarely how monitors are configured. The next section adds confirmations.
| Interval | Checks per day | Average delay to first failure | Worst-case delay |
|---|---|---|---|
| 30 seconds | 2,880 | 15 s | 30 s |
| 1 minute | 1,440 | 30 s | 1 min |
| 2 minutes | 720 | 1 min | 2 min |
| 5 minutes | 288 | 2 min 30 s | 5 min |
| 15 minutes | 96 | 7 min 30 s | 15 min |
| 60 minutes | 24 | 30 min | 60 min |
The jump from 5 minutes to 1 minute removes four minutes of worst-case blindness. The jump from 1 minute to 30 seconds removes 30 seconds. Both matter, but the first one matters ten times more, which is why 1 minute is the sensible floor for anything that earns money.
Confirmation checks multiply the delay: interval x consecutive failures
Almost every monitor waits for more than one failed check before it opens an incident. That is the right design: a single timeout can be a routing blip or a probe-side problem, and nobody wants to be paged for it. Upmonora defaults to 2 consecutive failures, and the thinking behind that number is covered in false positive alerts and failure thresholds.
The cost is that the confirmation checks are spaced by the same interval. With N consecutive failures required:
- Worst-case alert delay: N x I
- Average alert delay: I / 2 + (N - 1) x I
Here is the same table with the default of 2 confirmations, which is what most people are actually running:
| Interval | Average alert delay (2 failures) | Worst case (2 failures) | Worst case (3 failures) |
|---|---|---|---|
| 30 seconds | 45 s | 1 min | 1 min 30 s |
| 1 minute | 1 min 30 s | 2 min | 3 min |
| 2 minutes | 3 min | 4 min | 6 min |
| 5 minutes | 7 min 30 s | 10 min | 15 min |
| 15 minutes | 22 min 30 s | 30 min | 45 min |
| 60 minutes | 1 h 30 min | 2 h | 3 h |
Read the 5-minute row twice. A free monitor with two confirmations takes 7.5 minutes on average and 10 minutes at worst to tell you anything, and that is before a 30-second timeout on each check and the time it takes you to read the alert. Some tools re-check immediately from a second location after a failure instead of waiting a full interval, which shortens the confirmation step. Check whether yours does; many do not.
Worked example with Upmonora defaults: a Business plan monitor at 30 seconds with 2 consecutive failures opens an incident within 60 seconds of the outage at worst. The same monitor on the Free plan at 5 minutes opens it within 10 minutes at worst. Both are correct behaviour. One of them is a lot more useful at 3 a.m.
Short outages you will never see with 5-minute checks
Detection delay is only half of the problem. The other half is outages that end before the monitor notices them at all.
An outage of length L is observed by at least one check only if a check falls inside it. With a single-check alert, the probability of catching it is L / I when L is shorter than I. With 2 confirmations the outage must last long enough for two checks to land inside it, so anything shorter than I is never confirmed and anything shorter than 2 x I is a coin toss.
- 5-minute checks, 2 confirmations: every outage under 5 minutes is invisible; outages of 5 to 10 minutes are caught roughly half the time.
- 1-minute checks, 2 confirmations: outages under 1 minute are invisible; 1 to 2 minute outages are caught roughly half the time.
- 30-second checks, 2 confirmations: outages under 30 seconds are invisible; everything over 1 minute is confirmed.
Short outages are common. A PHP-FPM restart, a deploy that swaps containers, a database failover, a burst of 502s while a load balancer drains a node: all of these are 20 to 90 second events. On a 5-minute monitor they never appear, so your 100 percent uptime figure is partly a measurement artefact. Longer checks do not change your real uptime, they change how much of it you can see. That matters when you report an SLA, as how uptime is calculated explains.
Does checking every 30 seconds load your server?
No. The numbers are small:
- One check every 30 seconds is 2,880 requests per day, or 0.03 requests per second.
- From 6 regions that is 17,280 requests per day, or 0.2 requests per second.
- One human visitor loading a typical page with 60 to 100 sub-resources generates more requests in two seconds than a 30-second monitor sends in half an hour.
Two settings make it lighter still. First, use a HEAD request where the page allows it. Under RFC 9110 HEAD is identical to GET except that the server must not send content, so the server still runs the request through its stack and returns headers and a status code, but transfers no body. Second, check a light page or a dedicated health check endpoint rather than a heavy dynamic homepage that renders 40 database queries per hit.
The one real caveat: if you check a dynamic page that bypasses cache, every probe is a full render. That is still only 0.03 requests per second. If that load worries you, the site has a bigger problem than monitoring.
The Google SRE book makes the opposite point about frequency in its chapter on monitoring distributed systems: probing a service that targets 99.9 percent availability more than once or twice a minute is probably more than you need. That is a fair ceiling. It is also an argument for 1-minute checks, not 5-minute ones.
Which interval for which site: a decision table
| Site type | Interval | Consecutive failures | Worst-case alert delay | Why |
|---|---|---|---|---|
| Personal blog, portfolio, side project | 5 min | 2 | 10 min | Nobody is on call. You want to know it broke, not when. |
| Agency client sites, brochure sites | 1 to 2 min | 2 | 2 to 4 min | The client notices before you do if detection is slower than this. |
| SaaS application, customer dashboards | 30 s to 1 min | 2 | 1 to 2 min | Support tickets start within minutes of an outage. Beat them. |
| Ecommerce checkout, booking, payments | 30 s | 2 | 1 min | Every minute of a dead checkout is lost orders you can count. |
| Public API with an SLA | 30 s | 2 to 3 | 1 min to 1 min 30 s | SLA credits are measured in minutes; detection must be faster than the budget. |
| Status page or marketing site that rarely changes | 5 min | 2 | 10 min | Low cost of a late alert; fewer checks keep the noise down. |
| Internal tool, staging, dev | 5 to 15 min | 2 | 10 to 30 min | Business hours only matter. Pause it outside them. |
Two rules sit behind that table. Pick the interval from the cost of a late alert, which the cost of website downtime helps you estimate. And set the confirmation count from how noisy the network path is, not from how much you dislike alerts; a flapping site needs a fix, not a looser monitor.
Why most free plans check every 5 minutes
Five minutes is the standard free interval across the industry. UptimeRobot's free plan lists a 5-minute interval, with 60 seconds on its entry paid tier and 15 seconds on its top tier (checked in October 2026). Upmonora's Free plan is also 5 minutes, Starter is 1 minute and Business is 30 seconds; the full breakdown is on the pricing page.
The reason is cost, not spite. A 30-second check costs ten times the probe capacity, bandwidth and storage of a 5-minute check, and that is per region. Free tiers exist to let you try a product on sites where a 10-minute blind spot does not hurt. They are a reasonable default for the personal-blog row of the table above and an unreasonable one for anything with a checkout.
Checks from more than one region: how it affects timing
Checks from several regions change two things.
Confidence. If a probe in Frankfurt fails and a probe in Virginia succeeds, the site is probably up and the problem is on the path. Multi-region monitors use this to avoid false alerts: Upmonora marks a site down only when a majority of regions agree, and raises a separate regional-issue alert when a single region fails. The number of regions is per plan, from 1 on Free to 6 on Business.
Effective sampling rate. If the regions run on a staggered schedule, three regions at a 1-minute interval sample the site roughly every 20 seconds between them, which shortens the time to the first observation. The confirmation step still waits for a majority to agree, so do not count on it to cut the alert delay by the same factor. Treat regions as a false-positive filter first and a speed boost second.
Recommended settings for a new monitor
- Interval: 1 minute by default. Drop to 30 seconds for checkout, login, API and anything with an SLA. Go to 5 minutes only for sites where nobody is on call.
- Consecutive failures before an incident: 2. Raise to 3 for a known-flaky path; never 1 for a public site.
- Timeout: 10 to 30 seconds. A 30-second timeout on a 30-second interval means a hanging server is reported after the first missed window, which is what you want.
- Method: HEAD for static pages and CDN-fronted homepages; GET when the server treats HEAD differently or returns an error for it.
- Target: a page that exercises what matters, such as a product page or a health endpoint, with the expected status code set so a cached error page cannot pass as up.
- Regions: at least 2 if your plan allows it, so one bad network path cannot wake you.
- Maintenance windows: schedule them for deploys so a planned restart does not open an incident.
Before you commit to an interval, run a free check at upmonora.com/check to see how your site responds from outside, including response time and status, so you set a timeout that matches reality rather than a guess.
Upmonora runs uptime checks at any interval from 30 seconds to 1 hour, opens one incident after 2 consecutive failures by default, and closes it the moment a check succeeds, with the exact downtime recorded. Start free with 5 monitors at a 5-minute interval, or move to 1-minute and 30-second checks when a site earns it.
Frequently asked questions
How often should uptime checks run?
Uptime checks should run every 30 seconds to 1 minute for any site where downtime costs money or trust, such as ecommerce, SaaS and APIs. Every 5 minutes is acceptable for hobby sites, internal tools and low-traffic brochure sites. Pick the interval from how long you can afford not to know the site is down, not from how often a free plan happens to check.
Is 5-minute uptime monitoring enough?
Five-minute uptime monitoring is enough for sites where a 10 to 15 minute blind spot is acceptable. With the usual two consecutive failures required before an alert, a 5-minute monitor takes between 5 and 10 minutes to confirm an outage, and it misses most outages shorter than 5 minutes entirely. For a revenue-generating site that is too slow.
How long does it take to detect downtime with 1-minute checks?
With 1-minute checks a single failed check lands within 60 seconds of the outage starting, on average after 30 seconds. If the monitor waits for two consecutive failures before alerting, which is the common default, the alert arrives 90 seconds after the outage on average and 2 minutes at worst, plus a few seconds for the request timeout and alert delivery.
Does checking a website every 30 seconds affect performance?
No. A 30-second uptime check is 2,880 requests per day, or one request every 30 seconds, which is far below the traffic a single real visitor generates when loading a page with images and scripts. Using a HEAD request instead of GET makes it cheaper still because the server sends headers only. Checks from several regions multiply the count but it remains a rounding error for any web server.
