How to Choose the Right Monitoring Interval
"How often should I check my site?" sounds like a question with one answer: as often as possible. In practice, the check interval is only half of what decides how quickly you hear about an outage, and the faster you go, the more noise you invite. This guide shows the arithmetic behind detection time, gives concrete settings for common kinds of projects, and explains how to trade speed against false alarms on purpose rather than by accident.
Two settings decide detection time, not one
An uptime monitor works by sampling. Every interval it sends a request, and it only raises an alert after a number of consecutive failed checks, called the fail threshold. The threshold exists because single failed requests are common and usually meaningless: a dropped packet, a brief DNS hiccup, a deploy that restarted PHP-FPM for two seconds.
So the time between "the site broke" and "my phone buzzed" depends on both numbers:
- Worst case: the site fails right after a successful check. The first failing check comes almost a full interval later, and you then need the remaining failures to reach the threshold. Worst-case detection is therefore roughly
interval × fail threshold. - Average case: the outage starts, on average, halfway between two checks, so typical detection is about
interval × (fail threshold − 0.5). - Plus the request itself: if the failure mode is a hang rather than a refusal, each check also waits for its timeout before being counted as failed.
Worked example
A store is checked every 5 minutes with a fail threshold of 3. A database crash at 14:00:10, just after a successful check at 14:00:00, is first seen at 14:05, again at 14:10, and the third failure at 14:15 triggers the alert. That is about 15 minutes of downtime before anyone knows. Moving to 1-minute checks with a threshold of 2 brings the worst case to roughly 2 minutes.
| Interval | Threshold 1 | Threshold 2 | Threshold 3 | Threshold 5 |
|---|---|---|---|---|
| 1 min | ~1 min | ~2 min | ~3 min | ~5 min |
| 2 min | ~2 min | ~4 min | ~6 min | ~10 min |
| 5 min | ~5 min | ~10 min | ~15 min | ~25 min |
| 15 min | ~15 min | ~30 min | ~45 min | ~75 min |
| 60 min | ~1 h | ~2 h | ~3 h | ~5 h |
Read the table the other way round, too: if you can tolerate 10 minutes of unnoticed downtime, both "5 minutes × 2" and "2 minutes × 5" fit. The second costs more checks but is much better at ignoring one-off blips.
What the interval also controls: how short an outage you can see
Sampling has a second consequence that people often miss. An outage shorter than your interval can fall entirely between two checks and never be recorded. With hourly checks, a site that is down for 20 minutes every night may show 100% uptime. With 1-minute checks you will catch most of those episodes, though even then a 30-second restart may slip through.
This matters for your reports as much as for alerts. Uptime percentage is calculated from the checks you ran, so a coarse interval produces a flattering number. If you care about the real availability figure, for example to compare against a 99.9% target (about 43 minutes of downtime in a 30.4-day month), you need checks frequent enough to see outages of that size. The breakdown of what 99.9% and 99.99% actually allow shows how small those budgets get.
The cost of checking faster: false alarms
A faster interval does not create more failures, but it observes more of the brief ones. With a threshold of 1, every timeout during a deploy, every transient upstream error and every slow garbage-collection pause becomes an alert. People learn to ignore alerts that are usually wrong, and then they ignore the real one. That is the core of alert fatigue, and it is a bigger risk to your response time than a few extra minutes of detection.
The fix is not to slow down checks; it is to pair a short interval with a threshold of 2 or 3. You keep fast detection for real outages (two or three minutes at a 1-minute interval) while single-request blips are absorbed. Real outages tend to last; blips, by definition, do not.
There is also a load cost, but it is small. One request per minute is 1,440 requests a day, which a static page or a lightweight health endpoint handles without noticing. It only becomes a concern if the URL you check is expensive, for example an uncached search page that runs heavy database queries. In that case check a cheaper URL rather than checking less often.
Recommended settings by site type
These are starting points, not rules. Adjust once you have a week or two of data on how noisy your site really is.
| Site type | Interval | Fail threshold | Worst-case detection | Why |
|---|---|---|---|---|
| Personal blog, portfolio | 5–15 min | 2 | 10–30 min | Downtime is annoying, not costly. Catch it the same morning. |
| Brochure / small-business site | 5 min | 2 | ~10 min | Leads arrive through contact forms; an hour of downtime in business hours is noticed by customers before you. |
| E-commerce store | 1–2 min | 2–3 | 2–6 min | Every minute down is lost orders and abandoned carts. Also add a keyword check on a product page. |
| SaaS app or public API | 1 min | 2–3 | 2–3 min | Your customers' systems depend on you and will notice first. Check a health endpoint, not just the marketing site. |
| Internal tool, staging, admin panel | 15–30 min | 2 | 30–60 min | Users are colleagues who can tell you directly; the main goal is noticing overnight failures before the workday. |
| Batch / daily job endpoint | Hourly or daily | 1 | 1 h–1 day | If something only needs to work once a day, checking it every minute adds noise, not information. |
How the fail threshold interacts with the interval
Think of the threshold as "how long must a failure persist before I care", expressed in checks rather than minutes. That framing helps when you change the interval: if you move from 5-minute to 1-minute checks and keep a threshold of 2, your tolerance drops from 10 minutes to 2. That might be exactly what you want, or it might start paging you for every deploy.
Some practical guidance:
- Threshold 1 only makes sense with long intervals (hourly or daily), where waiting for a second check would cost too much time, or for endpoints so stable that any failure is meaningful.
- Threshold 2 is a good default. One retry absorbs most transient errors.
- Threshold 3–5 suits fast intervals on sites with known flakiness, such as shared hosting or an upstream API you do not control.
- Do not raise the threshold to hide a real problem. If a site fails a single check several times a day, that is intermittent downtime worth investigating. A detector for short, repeated failures is more useful than a higher threshold that silences them; see detecting flapping websites.
Don't forget the reminder interval
Once an alert fires, a separate setting decides how often you are reminded while the outage continues. It is independent of the check interval: you can check every minute but be reminded only every 30 or 60 minutes. Short reminders help when an alert might be missed (it arrived at 3 a.m. on a muted phone); long reminders avoid a flood when someone is already working on it. A recovery message when the site comes back closes the loop either way.
Plan minimums in Uptime Monitor
Uptime Monitor offers check intervals of 1, 2, 3, 4, 5, 10, 15 and 30 minutes, hourly and daily. The fastest interval you can choose depends on the plan:
| Plan | Websites | Fastest check | Shortest reminder interval |
|---|---|---|---|
| Starter (free) | 1 | every 5 min | 60 min |
| Plus ($9/month) | 10 | every 2 min | 30 min |
| Professional ($19/month) | 20 | every 1 min | 5 min |
Checks run from a single monitoring location, so a threshold of 2 or more is also your protection against a network blip between the monitor and your server being mistaken for an outage.
A quick decision process
- Decide the longest outage you could tolerate going unnoticed, in minutes. Be honest: "never" is not an answer, "10 minutes during business hours" is.
- Pick a fail threshold: 2 by default, 3 if the site or its host is known to be a little noisy.
- Divide your tolerance by the threshold. That is the slowest interval that meets your goal. Round down to the nearest available option.
- Check the URL is cheap to request at that rate. If not, monitor a lighter page or a dedicated health endpoint.
- Set a reminder interval that matches how your team responds.
- Review after two weeks. If you had alerts that resolved on their own within one or two checks, raise the threshold by one. If you found out about an outage from a customer, shorten the interval.
FAQ
Is a 1-minute interval overkill for a small site?
Not in terms of load, since one request per minute is negligible. It is overkill only if nobody would act on an alert within minutes anyway. If your realistic response time is "next morning", a 5- or 15-minute interval gives you the same outcome with less noise.
Why did my monitor miss an outage my users reported?
Most often the outage was shorter than the interval and fell between two checks, or it was shorter than interval × threshold and recovered before the alert fired. A shorter interval, or short-outage detection, will surface those episodes.
Should staging be monitored at all?
Yes, at a slow interval. A staging environment that has been down for a week is a common reason releases slip, and an hourly check costs nothing.
Key takeaways
- Worst-case detection ≈ interval × fail threshold. Plan with both numbers.
- Short intervals reveal short outages and make your uptime figures honest.
- Fight false alarms with a threshold of 2–3, not with a slower interval.
- Match settings to the cost of downtime: minutes for stores and APIs, tens of minutes for blogs, hours for internal tools.
- Revisit the settings after real data, not before.
Uptime Monitor lets you set the interval, fail threshold and reminder interval per website, so a store can run at 1-minute checks while a staging server sits at hourly. The free Starter plan covers one site at 5-minute checks; if you need faster detection, the Plus and Professional plans go down to 2 and 1 minutes.
