How Fast Should Your Uptime Checks Actually Run?

There is a number every uptime monitoring vendor puts in the pricing table, and almost nobody explains what it means for the buyer. That number is the polling interval. Sixty seconds. Thirty seconds. Five minutes on the free tier. The higher tiers get the smaller number and the buyer nods and assumes faster is better.

Faster is usually better. But not always, not by as much as the vendors imply, and the tradeoffs are worth understanding before signing up for the tier that halves the interval and doubles the invoice.

What a polling interval actually measures

An external uptime monitor works by sending an HTTP request to your URL from a probe server on some regular schedule. The polling interval is the time between two consecutive checks from the same probe. If the interval is 60 seconds and your site goes down between checks, the fastest possible detection time is the moment of the next check, which could be anywhere from zero to 60 seconds later. On average, half the interval.

So the interval sets an upper bound on detection latency. A 60 second interval means the worst case time to detect an outage is 60 seconds. The average is 30 seconds. A 5 minute interval means the worst case is 5 minutes, average 2.5 minutes.

That is the entire math. The rest of the discussion is about whether the difference between average 30 seconds and average 2.5 minutes actually matters for your specific situation.

When 5 minute intervals are fine

Marketing pages hate this section but it is true. For a lot of sites, 5 minute polling is enough.

• A personal blog with maybe fifty visitors a day. If the site is down for four minutes at 11 PM and you find out at 11:04, nobody noticed.
• A staging or QA environment that only your team uses. You'll notice when you try to load it. A monitor is nice to have but not urgent.
• Marketing landing pages that primarily drive organic search traffic. Search crawlers don't care about a few minutes of outage. Real users may reload once and move on.
• Internal tools that run on a schedule and are checked when someone needs them, not continuously.

If your site fits any of these, the free tier of any monitoring tool at 5 or 10 minute intervals is a rational choice. The Hobby plan on SIOPS runs longer intervals (over 60 minutes) but includes the loud alarm channel, which for a personal project is probably the right tradeoff. You don't need fast detection. You need the alert to actually reach you when the eventual check does fail.

When 60 seconds is the right answer

Sixty second polling is the default choice for the vast majority of small business sites and most freelance client work. Here is why.

The average visitor's tolerance for a broken page before hitting the back button is about eight seconds. If your site is down for two minutes, most visitors during that window will bounce and possibly not return. If your site is down for ten minutes, you have a real problem. If your site is down for an hour without you knowing, you have a business problem.

A 60 second polling interval means the outage will be detected within a minute of it starting. The alert path adds another 10 to 30 seconds for the notification to reach your phone. So you'll know within about 90 seconds, worst case. That gives you time to react, either by fixing the underlying issue if it's simple (a bad deploy, a saturated database connection pool) or by escalating to whoever can.

For most freelancers and small teams, 60 seconds is the sweet spot. Fast enough to matter, cheap enough to include in the base plan of a serious monitoring tool. SIOPS Serious runs under 60 seconds at $3.5 per month per project, which is roughly the price point where 60 second polling stops being a premium feature and starts being table stakes.

When 30 seconds or faster actually earns its keep

Here is where the vendor marketing tends to overshoot. 30 second polling is genuinely useful in specific cases. It is oversold outside those cases.

The cases where 30 seconds pays off:

• E commerce sites during promotional windows. If you're running a Black Friday sale and a checkout flow breaks, every 30 seconds of undetected downtime is measurable lost revenue. Halving the interval halves the maximum exposure.
• API endpoints that back real time features. If your API powers a chat app or a live dashboard, users will notice a 60 second outage as a broken experience. 30 second detection lets you initiate a failover faster.
• Payment processing endpoints. Regulated fintech and payment services often have SLAs that require sub minute detection. This is contractual, not just nice to have.
• Sites where the on call engineer commits to a strict acknowledgement SLA. If you promise the client "we ack within 5 minutes of an incident starting," you need to actually detect the incident with minutes of budget to spare. 30 second polling gives you that budget.

The cases where 30 seconds is a waste:

• Sites with a slow underlying infrastructure. If your average time to recover from a database restart is 8 minutes, detecting the outage in 30 seconds versus 60 seconds is a rounding error against your recovery time. Fix the recovery first.
• Sites that produce false positives at short intervals. Some cheap shared hosting will rate limit or briefly time out under load. A 30 second check catches transient blips that a 60 second check would smooth over. The result is alert fatigue and eventually a silenced app, which is worse than slower detection.

If you're paying for 30 second polling and you don't fall into the first list, you're probably wasting money.

The overlooked variable: probe count

Detection latency is not just about how often one probe checks. It is also about how many probes check from different geographic locations. A single probe can be wrong. It can be misrouted. It can hit a captcha on a WAF. It can be blocklisted by your CDN's rate limiter.

Serious monitoring tools run each check from two or more probe locations and only fire an alert when both fail. This dramatically reduces false positives and slightly increases detection time (both probes have to fail in the same window).

If your monitor fires immediately on a single failed check from a single probe, expect false positives. If it retries from a second location before firing, expect zero or near zero false positives at the cost of maybe another 10 to 15 seconds of latency. The second option is almost always the right tradeoff for a solo operator who does not have time to investigate a false alarm.

SIOPS runs each check across multiple probes and only alarms when the failure is confirmed. This is not the fastest possible detection but it is the most reliable one for the price, and reliability is what actually matters when the alarm wakes you at 3 AM.

The number that actually matters: alert time

Polling interval gets all the attention. The number that matters more is total alert time, which is the sum of:

1. Time from failure to detection (bounded by polling interval, averaged as half of it).
2. Time from detection to confirmation across probes (usually 10 to 30 seconds).
3. Time from confirmation to notification delivery on your phone (usually 5 to 15 seconds for a push, up to a minute for SMS or a phone call).
4. Time from notification delivery to you actually hearing it (this is zero if you're on your laptop, or infinity if your phone is on Do Not Disturb and the tool doesn't use Critical Alerts).

The last one is where most tools quietly fail. You can have 30 second polling and 20 seconds of confirmation delay and 5 second push latency and it does not matter if the notification is silenced by DND. Total alert time in that case is however many hours until you wake up naturally, which is not a monitoring product. It is a log file.

Optimising the polling interval below 60 seconds without also fixing the notification path is like tuning the engine of a car with no wheels.

What we recommend as a rough guide

Here is the shortlist we hand freelancers and small teams who ask.

• Personal projects and staging environments: 5 to 60 minute polling on a free tier. Get the alarm right so you at least know within an hour.
• Client sites, small business, most agencies: 60 second polling with alarm alerting. This is the SIOPS Serious plan at $3.5 per month per project.
• E commerce during peak, payment endpoints, real time APIs: 30 second polling with escalation policies and a second on call engineer. This is the SIOPS Pro tier or an equivalent higher spec option.
• Anything else: default to 60 seconds and spend the money you saved on making sure the alert actually wakes someone up.

Fast checks are cheap now. Reliable alerts are still surprisingly rare. Prioritise the second one.