Uptime Check Interval Detection Time Calculator

Shows how long an outage can go unnoticed at a given check interval and confirmation setting, and how many monitoring requests that setup sends per month.

Your estimate

Worst case time to alert...

Average time to alert...

Requests per endpoint per day...

Total checks per month...

Estimates only. Assumptions are listed below, and you can change every input.

Picking a check interval is a trade between two things nobody states out loud: how quickly you find out you are down, and how much monitoring traffic your servers absorb. A 5 minute interval with two confirmations can leave an outage invisible for over 10 minutes. A 30 second interval from six locations quietly adds thousands of requests a day to every endpoint you watch.

This calculator works out the best case, average and worst case time to alert from your interval, the number of consecutive failed checks you require before alerting, and the delay your notification channel adds. It also totals the checks your setup generates per month across all monitors and locations, and the requests each endpoint receives per day, so you can size a monitoring plan and check that the traffic is acceptable.

How to use this tool

Enter your check interval in seconds and how many consecutive failed checks your monitoring requires before it alerts.
Add the delay your notification channel typically adds, then the number of locations and monitors in your account.
Read the worst case and average time to alert, and use the request and check totals to confirm your plan limits and server load are acceptable.

What the math assumes

Worst case assumes the outage begins right after a check completes, so a full interval passes before the first failure is seen; average assumes it begins halfway through an interval.
All locations are assumed to check on the same schedule and the alert waits for the required number of consecutive failures from the same location, so extra locations do not shorten detection in this model.
The check itself is assumed to fail instantly; if your monitor waits for a long timeout before declaring failure, add that timeout to the notification delay.
A month is counted as 30 days and every location checks every monitor at the same interval.
Each check is assumed to be one HTTP request; checks that follow redirects or load page assets send more.

Frequently asked questions

Why does requiring two failed checks double my detection time?

Because the monitor has to wait a full extra interval to see the second failure. At a 5 minute interval that adds 5 minutes on top of the first miss. If false alarms are your concern, a shorter interval with two confirmations usually beats a long interval with one.

Do more monitoring locations make detection faster?

Only if your monitoring service staggers the locations and alerts on the first confirmed failure from any of them. Many services require agreement between locations to avoid regional false positives, which is why this calculator does not credit extra locations with faster detection.

Is 4,000 requests a day per endpoint a problem?

For most web servers it is negligible, roughly one request every 20 seconds. It matters more when the endpoint runs an expensive query, when you pay per request on a serverless platform, or when rate limits or bot filters might block your own monitor.

Link to this toolhttps://pingcrumb.com/tools/check-interval-detection-time/

Free for readers and publishers alike. If you cite the result in an article, a link to this page helps others find it.

More free tools from PingCrumb

Website Downtime Cost Calculator: Estimates what a single outage costs a SaaS or online business in lost revenue, response labor and credits, so you can put a real number on uptime.
Uptime SLA Error Budget Calculator: Converts an uptime target like 99.9 percent into allowed minutes of downtime, then checks whether your real incident pattern fits inside that budget.

Know before your customers do

Uptime monitoring and hosted status pages.

Start monitoring