For anything that makes money, check every 30 to 60 seconds. For internal tools and low-stakes pages, 5 minutes is fine. The reason is arithmetic rather than preference: you find out about an outage roughly half a check interval after it starts, so a 5-minute interval hides an average of 2.5 minutes of downtime and up to 5 in the worst case, while a 30-second interval hides about 15 seconds.
That single number drives more of your incident response than any dashboard feature. Every minute before detection is a minute nobody is fixing anything, and it lands at the front of the timeline where it is most expensive. Here is how to pick the interval per monitor rather than guessing one for everything.
How often should you check uptime?
Match the interval to what breaking costs. A checkout flow, a login endpoint or a public API deserves 30 to 60 seconds because failed requests turn into lost revenue and support tickets immediately. A marketing page, a docs site or an internal admin panel can sit at 5 minutes without anyone noticing the difference. The mistake is setting one interval for the whole account and then either paying for speed you do not need or missing outages on the things that matter.
| What you are watching | Suggested interval | Average time to detect | Why |
|---|---|---|---|
| Checkout, payments, signup | 30 seconds | About 15 seconds | Every failed attempt is lost revenue and a support ticket |
| Public API others build on | 30 seconds | About 15 seconds | Your outage becomes your customers' outage |
| Main marketing site | 60 seconds | About 30 seconds | Visible to everyone, but a short blip rarely costs a sale |
| App dashboard after login | 60 seconds | About 30 seconds | Users notice fast, though they usually retry before complaining |
| Docs, blog, status page | 5 minutes | About 2.5 minutes | Low stakes, and cheap to leave on a slower tier |
| Internal admin tools | 5 minutes | About 2.5 minutes | A known audience who will tell you directly |
| Nightly backups and cron jobs | Grace period, not an interval | Window you set | Measured by a missed check-in rather than a probe |
The math behind the interval
An outage can start at any point between two checks, so on average it begins halfway through the gap. That gives you a simple rule: expected detection delay is half the interval, and the worst case is the full interval. A 5-minute check averages 2.5 minutes of blind time. A 60-second check averages 30 seconds. A 30-second check averages about 15.
Put that against your uptime target and it gets sharper. A 99.9% target allows about 43 minutes of downtime a month. If you are on 5-minute checks, a single undetected outage can burn 5 of those 43 minutes before anyone even starts working on it, which is more than a tenth of your monthly budget spent on not knowing. There is more on that arithmetic in our guide to what counts as a good uptime percentage and in how error budgets work.
Does checking more often cause false alarms?
It can, and this is the real argument against short intervals. A faster interval samples more often, so it catches more transient blips: a momentary network hiccup, a load balancer draining a node, a slow response that crosses your timeout for one request. If every one of those pages somebody at 3am, the team learns to ignore alerts, which is worse than checking slowly.
The fix is confirmation rather than a slower interval. Before an alert fires, the check should be repeated from a different location, and only a failure everywhere should page you. That is why AlertPing confirms from Frankfurt, Virginia and Singapore before sending anything: one region timing out is a routing problem, three regions timing out is an outage. You get 30-second detection without the noise that usually comes with it.
What check interval do monitoring tools actually offer?
Check intervals are usually the thing vendors put behind the price wall, so the interval you want often decides the plan you buy. Free plans across the market cluster at 5 minutes. Entry paid plans typically land at 60 seconds. Thirty seconds tends to sit near the top of the price list, which is why comparisons like StatusCake vs UptimeRobot come down to how much you are willing to pay for the gap between five minutes and one.
Worth knowing before you shop: some tools quote their fastest interval as a headline number that only applies to a subset of check types, or only on the top tier. Read the plan row rather than the hero line. Our own plans put 60-second checks on Starter at $19 and 30-second checks from Team at $59, and we would rather say that plainly than imply everything runs at 30 seconds.
Should every monitor use the same interval?
No, and mixing them is how you keep the bill sensible. Put your revenue path on the fastest interval you are paying for, then step everything else down. A typical small SaaS account might run four or five 30-second checks on checkout, login, the API and the app shell, then a dozen 5-minute checks on marketing pages, docs and third-party status endpoints. You spend the fast checks where a minute costs money.
The same logic applies to scheduled work, except the unit is different. A backup that runs nightly does not need a 30-second probe, it needs a window: if no check-in arrives within 25 hours, something is wrong. That is a dead man's switch rather than an interval, and it is the only way to catch a job that stopped running rather than one that ran and failed.
How often should you check an API?
Every 30 to 60 seconds for a production API, and check more than the status code. An API can return 200 while the response body is empty, the schema changed, or an upstream dependency is failing quietly underneath. Assertions on the body or a JSON path catch the outage that a plain availability check reports as healthy. Our API monitoring page covers how those checks are put together.
If the API is one other companies build on, treat it as your most important monitor regardless of traffic volume. A broken endpoint that thousands of integrations depend on generates a support load out of all proportion to its request count, and the people affected find out before you do unless the interval is short. If your team also relies on connecting a stack of third-party apps and APIs, monitor those integration endpoints too, because a dependency failing quietly looks exactly like your own code working fine.
Can you check too often?
Practically, yes, though the limit is usually about cost and courtesy rather than technology. Sub-30-second intervals add real load if you are running many monitors against the same origin, and they rarely change the outcome: the difference between detecting in 15 seconds and detecting in 8 is almost never what determines how long an incident lasts. Time to acknowledge and time to fix dominate.
If you find yourself wanting sub-30-second checks, the bottleneck is probably somewhere else in the chain. Look at whether alerts reach a person quickly, whether the on-call rotation has a clear escalation path, and whether the runbook says what to do. Shaving seconds off detection while an alert sits unread in a Slack channel for eleven minutes is optimizing the wrong end of the timeline, as our note on mean time to recovery lays out.
Setting intervals: a short checklist
Run through this once when you set up monitoring, then again whenever you add a significant feature.
- List every endpoint a paying customer touches, and put those on your fastest interval.
- Step everything internal or informational down to 5 minutes.
- Confirm from multiple regions before alerting, so a faster interval does not mean more noise.
- Give scheduled jobs a grace window instead of an interval.
- Check that the alert reaches a phone, not only a dashboard, outside working hours.
- Re-check the list after each launch, because new revenue paths rarely get monitors automatically.
Done properly this takes twenty minutes and is the highest-leverage monitoring work most teams never get around to. If you want the whole picture of what continuous checks cover, our website monitoring page walks through it, and website down alerts covers how the notification itself reaches you.