The arithmetic
An outage cannot be detected before the next check after it starts, so with an interval of T minutes the average detection delay is T/2 and the worst case is T, plus any confirmation time. The number of checks in a 30-day month per location is 43,200 divided by T. Outages shorter than the interval can be missed entirely.
Trade-offs
Shorter intervals detect sooner and give more chances of a false failure, so they pair with confirmation from a second location. They also load the monitored site a little and are often limited by plan or price: UptimeRobot, for example, lists 5 minutes on its Free plan and 60, 30 and 15 seconds on its paid ones, while Oh Dear’s documentation says uptime checks happen every minute from the primary location (both read 2026-10-28). Google’s SRE book makes the point from the other side: for a service allowed no more than 9 hours of downtime a year (99.9 percent), probing for a 200 status more than once or twice a minute is “probably unnecessarily frequent”.
Different checks, different intervals
A page check suits one to five minutes. A certificate’s expiry date changes slowly, so hourly is plenty. Domain expiry is daily. Scheduled jobs follow their own period.
A worked example
A check every 5 minutes makes 8,640 requests a month per location and detects an outage 2.5 minutes after it starts on average, 5 minutes at worst. A check every minute makes 43,200 requests and detects within 1 minute at worst, before any confirmation step. Confirmation from a second location or a second consecutive failure adds time on top. Pick the interval from how fast the client needs to hear, then look at what confirmation costs in delay.
What to check
The cost of a minute of downtime for the client, who responds and how fast, and whether the interval and confirmation rule match.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.