Monitoring
How to choose the right monitoring interval
Every minute, every five or every hour? The check interval determines how quickly you find out about an outage. Here's how to choose it based on the service and your budget.
UptimeAnchor team · · 7 min read
When you create a monitor, one of the first decisions is the interval: how often UptimeAnchor should check that the service responds. It looks like a detail, but it's the factor that most affects detection time, meaning how long passes between the start of a problem and the moment you hear about it.
Worst-case detection time
If you check every 5 minutes and the service goes down one second after a successful check, you'll only notice at the next check. On top of that comes confirmation: to avoid false alarms, a failure has to repeat before an incident is opened. Worst-case detection time is therefore roughly the interval multiplied by the number of checks needed to confirm the problem.
| Interval | Typical detection | Worst case (2 confirmations) |
|---|---|---|
| 30 seconds | under 1 minute | about 1 minute |
| 1 minute | 1–2 minutes | about 2 minutes |
| 5 minutes | 5–10 minutes | about 10 minutes |
| 15 minutes | 15–30 minutes | about 30 minutes |
What does a minute of downtime cost?
The most concrete way to decide is to estimate the cost of one minute of downtime. For an online store turning over €2,000 a day, ten minutes of broken checkout is worth about €14 in lost sales, not counting the customers who won't come back. For an API used by partners under an SLA, even a few minutes can trigger penalties.
- Services that generate revenue directly (checkout, payments, login): 30 seconds or 1 minute.
- Public APIs and services with an SLA: 1 minute, from multiple regions.
- Corporate websites, blogs, landing pages: 5 minutes is often enough.
- Staging environments and internal tools: 5–15 minutes.
- Domain and certificate expiry: daily checks are enough, but with early reminders.
More frequent doesn't mean noisier
A common worry is that more frequent checks produce more false alarms. In fact the opposite happens: with a short interval, confirmation of a failure arrives sooner and transient problems, such as a single network timeout, clear up on their own before an alert is sent. The key is to combine a short interval, confirmation over several checks and, where possible, multiple regions.
The timeout matters as much as the interval
A service that responds in 25 seconds is technically online, but for your users it's broken. Set a realistic timeout, for example 10–15 seconds for a web page, and keep an eye on the response time chart: a gradual rise in latency is often the first sign of trouble ahead.
In short
- Rank your services by business impact.
- Give critical services 30 seconds or 1 minute and the rest 5 minutes.
- Enable multiple regions on your most important monitors.
- Set a timeout that matches the user experience.
- Review your choices every few months as the service grows.