The simple version
Faster checks mean faster detection but cost more (in money or in self-hosted infrastructure). Slower checks save money but extend the window between an outage starting and you finding out.
Most people overthink this. For 90% of sites, anything between 30 seconds and 5 minutes is fine, and the differences between those numbers don’t matter as much as you’d think.
Here’s the actual decision framework.
How check frequency relates to detection time
If you check every 60 seconds, your worst-case detection time is 60 seconds. Your average detection time is 30 seconds (half the interval). Add maybe 10 seconds for the recheck that confirms the failure isn’t a flake, and you’re looking at 40 seconds median, 70 seconds worst-case from outage start to alert sent.
For a 30-second interval: 15 seconds median, ~40 seconds worst-case.
For a 5-minute interval: 2.5 minutes median, 5.5 minutes worst-case.
Then add notification delivery (10-30 seconds for push, 30 seconds to 2 minutes for SMS) and you have the full latency from “site goes down” to “you know about it.”
The diminishing returns curve
The first jump — going from “no monitoring” to “checks every 5 minutes” — is enormous. You go from “I’ll find out hours later from a customer” to “I’ll find out in under 5 minutes.”
The next jump — from 5 minutes to 1 minute — is smaller. You save 4 minutes of detection time. Real, but not life-changing.
The jump from 1 minute to 30 seconds saves another 30 seconds. From 30 seconds to 15 seconds saves another 15. From 15 to 10 saves 5.
You can see the shape: each halving of the interval halves the gain. At some point you’re paying real money to save seconds, and the seconds don’t matter for your business.
Picking by what your site does
Personal site, blog, portfolio: Every 3–5 minutes is fine. The downside of a 4-minute outage going undetected for 4 more minutes is nothing.
Small business marketing site: Every 1–3 minutes. You want to know within a few minutes that the homepage is broken, but the marginal value of 30-second checks is low.
E-commerce, lead capture, transactional: Every 30–60 seconds. The cost of an undetected outage scales with the conversion you’re losing per minute. Detect fast.
APIs, real-time services, anything with SLAs: Every 15–30 seconds. You’re likely promising customers fast detection, and your alerting infrastructure needs to support it.
Internal tools: Every 5–15 minutes. The cost of slow detection is “annoyed employees, not lost revenue.” Lower frequency saves operational overhead.
The honest answer for most operators is 60 seconds. Fast enough that any real outage gets caught within 2 minutes, slow enough that costs and false-alarm volume stay manageable.
Why faster isn’t always better
Three downsides to very aggressive check frequencies:
1. Cost. Most monitoring services price by check frequency. A 30-second check is twice as expensive as a 60-second check, four times as expensive as a 2-minute check. For a single monitor that’s pennies; for 50 monitors it adds up.
2. Server load. A 15-second check is 5,760 requests per day per region. From 3 regions, that’s 17,280 daily requests on the URL you’re checking. For a static homepage that’s nothing. For an API endpoint that hits the database on every request, that’s traffic worth thinking about.
3. Noise. Faster checks catch more transient failures. A 30-second flake might happen once a week per monitor. A 5-second flake happens many times a day. If your alerting isn’t aggressive about deduping and rechecking, faster checks mean more 3 AM pages for non-incidents.
The second-region recheck pattern (alert only when both regions agree a failure is real) helps a lot here. With it, you can run aggressive intervals without proportional noise increase. Without it, fast intervals will train you to ignore the pager.
Check what, not just how often
Frequency is one variable. The other one — often more important — is what you’re checking.
A 30-second check on your homepage tells you whether the homepage is reachable. It doesn’t tell you whether your login page works. Or your API. Or your checkout flow. Or the cron job that processes overnight orders.
For most sites, the biggest improvement isn’t increasing check frequency — it’s adding monitors for the other critical paths. A 60-second check on each of (homepage, login, checkout, API health) is better than a 15-second check on just the homepage. You catch more failures, even though each one takes slightly longer to detect.
A useful mental model: what’s the page or endpoint that, if it returned a 500, would lose you the most money or customers? That’s the monitor that deserves the most aggressive check frequency. The others can run slower.
The TLS/SSL check is special
One monitor that’s worth its own consideration: SSL certificate expiry. This isn’t a high-frequency check — once a day is plenty. The point isn’t to detect the cert expiring at the moment it happens (it’s too late by then). The point is to know weeks in advance.
A daily SSL check that alerts at 30, 14, and 7 days before expiry prevents an entire category of outage. Most monitoring services do this automatically as part of any HTTPS uptime check. Make sure yours is one of them.
Two-tier monitoring for cost-sensitive teams
If you have many monitors and budget matters, a useful pattern is two-tier frequency:
- High-priority monitors (production, revenue, customer-facing) at fast intervals — 30–60 seconds
- Lower-priority monitors (internal tools, staging, vendor APIs) at slower intervals — 3–5 minutes
This is how most monitoring services price their tiers anyway — paid plans buy you faster checks on the things that matter, while everything else stays on the free or basic tier.
For MyUptimeBot’s plans the breakdown is: free tier checks every 3 minutes, Essential drops to 60 seconds, Professional to 45 seconds, Elite to 30 seconds. The progression isn’t because we want to charge more — it’s because faster checks are genuinely more expensive to deliver.
The mistake to avoid
The most common mistake is setting up monitoring with a single low-frequency check (every 5 minutes), seeing green checks for weeks, and concluding “monitoring is set up, we’re good.” Then an outage happens, the check happened to fire 4 minutes before the outage started, and you found out from a customer 9 minutes in.
If you want monitoring to actually catch outages quickly, the interval matters less than the rest of the setup — multi-region checks, proper alerting, monitoring the right URLs, and someone actually receiving the alerts. A 5-minute check setup correctly beats a 15-second check setup poorly.
Pick once, move on
Most operators land on 60-second checks and never think about it again. That’s the right answer for most cases. If you have a specific reason to be faster — promised SLAs, high-revenue site, time-sensitive transactions — go to 30 seconds. If you’re cost-conscious and the site is low-stakes, 3 minutes is plenty.
This is one of those decisions where the perfect answer is the enemy of the good-enough answer. Pick a reasonable number, set it up, and move on to the actual hard work — figuring out which URLs to monitor, who gets paged, and what happens when the alert fires.
