When you set up a monitor, one setting quietly decides how good your monitoring actually is: how often it checks. It seems minor, but it directly sets your floor for how fast you can possibly detect a problem — and it's a genuine trade-off, not a "more is always better."
Why the interval matters so much
Your check interval is the maximum time you can be down before you even start to know. Check every 30 minutes, and an outage that starts at 12:01 might not be noticed until 12:30 — 29 minutes of silent downtime baked in before anyone's alerted.
Your detection time can never be faster than your check interval. A one-hour interval means up to an hour of blind downtime, no matter how good your alerting is. The interval sets the floor.
The trade-off
Shorter isn't free, so it's a balance:
| Shorter interval (e.g. 30s–1m) | Longer interval (e.g. 5–15m) |
|---|---|
| Faster detection | Slower detection |
| Lower MTTD | More blind time |
| More checks (cost, sometimes plan-gated) | Cheaper, lighter |
| Tighter SLA confidence | Looser |
The art is matching the interval to how much that service is worth — not maxing it out everywhere.
How to choose
Match the frequency to the stakes:
| Service | Suggested interval |
|---|---|
| Checkout, payments, core API | 30s–1m — every second of downtime hurts |
| Main website / app | 1m — fast detection, low cost |
| Marketing pages, blog | 5m — fine; downtime is low-stakes |
| Internal/back-office tools | 5–15m — relaxed |
| Certificate / domain expiry | Daily — it's a calendar, not a heartbeat |
Notice the last row: not everything is a "heartbeat." Certificate expiry doesn't need a 1-minute check — once a day is plenty, because it's about a date weeks away.
Interval vs. confirmation
A short interval pairs naturally with confirmation to avoid noise. Checking every 30 seconds and confirming a failure across multiple locations before alerting gives you fast detection without paging on every transient blip. Speed and signal, together.
A simple rule of thumb
Ask: "If this were down, how long is too long to not know?" Whatever that answer is, your interval should be shorter. For revenue-critical things it's seconds; for a blog it's minutes; for a certificate it's a day.
Don't reflexively set everything to the fastest interval — it costs more and rarely helps on low-stakes services. Spend your frequency where downtime actually hurts.
The bottom line
| In one line | |
|---|---|
| What it sets | The floor on how fast you can detect a problem. |
| Trade-off | Faster detection vs more checks / cost. |
| Choose by | The value of the service — seconds for critical, minutes for the rest. |
| Pair with | Multi-location confirmation, so fast doesn't mean noisy. |
The right interval isn't "as fast as possible" — it's "fast enough for what this service is worth." Tighten it where downtime costs you money, relax it where it doesn't, and you get fast detection and a sensible bill.
Related: Uptime Monitoring 101, incident metrics; compare plans on pricing.