Why 1-minute uptime checks matter (and when 5-minute is fine)

The question nobody asks until they have to

How long should you wait between uptime checks? Most people pick the free-tier default (usually 5 minutes), don't think about it again, and only realise it matters the day customers find out about an outage before they do.

I want to walk through the math, the tradeoffs, and the cases where each interval is genuinely the right choice — instead of just "buy the most expensive plan" or "free is fine."

The math: expected detection time

Every check interval has the same shape: an outage starts at a random moment between probes, and you find out at the next probe. So:

• Best case: outage starts 1 second before the next probe. You find out almost immediately.
• Worst case: outage starts 1 second after a probe succeeded. You wait the full interval.
• Average case: half the interval. This is what matters for capacity planning.

So the practical numbers look like this:

Interval    Avg detection    Worst case
30 sec      15 sec           30 sec
1 min       30 sec           1 min
5 min       2.5 min          5 min
15 min      7.5 min          15 min

That's assuming probes always succeed when the site is up and always fail when the site is down. In practice you also need to handle false positives (more on that below), but the table above is the baseline.

What downtime actually costs

For a content site with 1,000 visits a day, 5 minutes of downtime affects ~3 users and is invisible to the rest. Reasonable to ignore.

For a SaaS doing $10k MRR with even traffic, 5 minutes of downtime costs ~$1.16 in lost revenue (statistically). Still small. But:

• 5 minutes is enough time for someone to give up on signup and never come back.
• 5 minutes is enough for a Stripe webhook to time out and silently desync your subscription state.
• 5 minutes is enough for one of those 5-star Twitter rants you can't un-receive.

The number that matters isn't lost revenue per minute. It's whether a 5-minute average detection delay creates a different kind of bad day for you than a 30-second one.

When 1-minute is genuinely worth it

• You charge for transactions. Checkout, payments, API-as-a-service, real-time apps. Every minute down is a measurable revenue hit, and customers notice immediately.
• You deploy frequently. If you ship 3-5 times a day, regression detection at 5-minute intervals means you might roll out 2-3 deploys before noticing one of them broke. 1-min cuts this.
• Your alert is your one safety net. No on-call rotation, no Sentry alerts, no canary deploys. The uptime monitor is how you find out. Faster is better.
• Your product's contract is reliability.If you're an uptime monitor, a payment processor, or anything else where customers are paying for the "always works" property, you can't answer "sorry, I'll know in 5 minutes."

When 5-minute is genuinely fine

• Personal sites and blogs. If 5 minutes of downtime is invisible to your audience, paying for 1-min is paying for nothing.
• Soft-launch period. Before your product has 100 users, the cost of a 5-min outage is rounding error. Save the money, upgrade later.
• Non-customer-facing infra.Internal tools, CI pipelines, analytics ingestion — if a 5-min lag in detection doesn't change your response, 1-min doesn't buy you anything.
• You're monitoring as a sanity check, not an SLA. You want to know roughly when something dies. 5-min checks are perfect.

The thing nobody tells you: false positives

Shorter intervals catch more transient blips. A 1-minute monitor will see momentary network issues, brief CDN errors, and DNS hiccups that a 5-minute monitor would miss entirely. This is sometimes good (you catch real customer pain) and sometimes annoying (alert fatigue).

The fix isn't to use 5-minute checks. It's to combine:

• 1-minute interval for fast detection.
• Failure threshold ≥ 2 — only alert after 2 consecutive failed probes. Most flapping disappears.
• Alert recovery threshold— only declare "recovered" after 1-2 consecutive successful probes, so a flickering site doesn't spam your inbox with up/down/up/down.

SitePulse's default is 1 failure = alert, which is fine for most cases. If a specific monitor is flapping, raise its threshold to 2 or 3 in monitor settings. Same pattern works on UptimeRobot, BetterStack, StatusCake — every major monitor.

Why 30-second checks are usually overkill

Going from 1-min to 30-sec halves your average detection time (30s → 15s) but doubles your probe volume. Most providers charge accordingly. For 99% of indie products, that 15-second improvement isn't worth it.

The exception: real-time financial systems, gaming infrastructure, or anything where 30 seconds of degradation is a contract breach. That's not most of us.

What I actually recommend

1. Start with 5-minute on the free tier of any major monitor.
2. Upgrade to 1-minute the day your product crosses either of these lines: (a) you have paying customers, (b) you deploy more than once a day, (c) outages have started costing you sleep.
3. Don't bother with 30-sec unless you have a contractual reason.
4. Set failure threshold to 2 on any monitor that flaps.
5. Probe a cheap /health endpoint, not your homepage, if your homepage is expensive to render.

For SitePulse specifically: 5-min is free (5 monitors), 1-min is $9/mo on Pro. If you cross the line above, the upgrade pays for itself the first time it catches a deploy regression before a customer does.