Detection delay is the first tradeoff
If a monitor checks every five minutes, an outage can begin seconds after a successful check and remain invisible until the next scheduled check. That means a 5-minute interval can create nearly five minutes of detection delay before anyone starts investigating.
A 1-minute interval narrows that blind spot. That matters for checkout, login, production APIs, order intake, webhook receivers, and any route tied directly to revenue or support volume. It matters less for a brochure site, a low-traffic internal dashboard, or a page where a short outage will not affect operations.
Typical detection window before the first failed check appears.
Better for routes where every minute of failure matters.
The SLA math changes the decision
A 99.9% monthly target allows roughly 44 minutes of downtime in an average month. A 99.99% target allows about 4 minutes and 23 seconds. With a 99.99% target, one 5-minute detection delay can consume the entire monthly budget before the responder opens the dashboard.
That does not mean every monitor needs a 1-minute interval. It means the interval should follow the page's business role. Monitor the revenue path more aggressively than the marketing blog.
A practical interval policy
| Route or service | Suggested interval | Why |
|---|---|---|
| Login, checkout, payment, order API | 1 minute when available | Failures become customer-facing quickly and need early rollback decisions. |
| Homepage, docs, pricing, public status page | 5 minutes is usually enough | Fast detection still matters, but a few minutes rarely changes incident handling. |
| Internal admin tools | 5 to 15 minutes | Alerting should match staff dependency and working hours. |
| Background jobs and cron routes | Interval tied to job schedule | A job that runs hourly should be monitored differently from a public API. |
Short intervals need better alert rules
The shorter the interval, the more important confirmation logic becomes. A single failed request can be a packet loss event, a transient DNS issue, or a short upstream hiccup. A production alert should usually require more than one failed check unless the endpoint is extremely critical.
A good pattern is to separate "investigate" signals from "wake someone up" signals. For example, two failed 1-minute checks on checkout can create a high-priority alert. A single failed 5-minute check on a marketing page can stay as a dashboard warning until a second failure confirms it.
Response time belongs in the interval decision
An endpoint does not have to be fully down to hurt users. If login normally responds in 300ms and suddenly takes 8 seconds, support tickets may begin before the monitor marks the service down. Use response-time thresholds on critical endpoints so slow failure is visible before total failure.
Start simple, then tighten the routes that prove value
Most teams should begin with 5-minute checks across their public surface, then tighten the interval on the few paths where faster detection would change what they do. The right question is not "Can we monitor this every minute?" It is "Would one-minute detection change our response before customers notice?"
Use the uptime SLA calculator to translate your uptime goal into a downtime budget before setting interval rules.