Monitoring check interval detection-delay estimator

See the blind window between polling checks. Illustrate how a check interval and consecutive failures affect detection, without connecting to a service.

Choose the check timing

Free and account-free. Inputs stay in memory on this page; they are not saved or sent anywhere. A download creates a local text file.

Check interval

Interval unit

Fixed elapsed time between check starts: 0.001 seconds to 24 hours. Use a decimal point, up to three decimal places. No dates or daylight-saving adjustment.

Consecutive failures

Failure response delay (seconds)

A whole number from 1 to 100. The latest detection must fit within 7 days.

0 explicitly models immediate failed checks. To illustrate a timeout, enter its duration in seconds. Each failure is assumed to take this same time, shorter than the interval; overlapping checks are not modeled.

Worked example: 60-second interval, three failures, immediate failure responses.

Earliest detection

120 s

Latest detection

180 s

Outage begins0 s
First failed result0 s–60 s
Failure 3 confirms detection120 s–180 s

Fixed check starts every 60 s; 3 consecutive failures; each failure completes after 0 s. Persistent outage, arbitrary onset, no overlapping checks, jitter, retries or notification delay. Bounds are limiting cases, not measured detection times.

What this timing model assumes

Earliest = (failures − 1) × interval + failure response delay.
Latest = failures × interval + failure response delay.

An outage just before a check can be noticed sooner; an outage just after one can wait almost a full interval for the first failed check. The outage persists through every required failure. A recovery would break that sequence. The endpoints are limiting cases because exact simultaneous onset and check order are unspecified.

The schedule starts checks at fixed times, rather than waiting an interval after each result. The response delay shifts the final result once; it is not multiplied by the threshold. A scheduler that waits after each completion, overlapping checks, retries, variable timeouts, jitter, missed runs and notification delivery need their own model. This illustration is not an SLA or a prediction of a real monitor.

ObserveifyNow does not run background polling. It reads published Uptime Kuma status pages in the browser when the service permits that origin. Protected infrastructure reads require the native app. Local notifications compare successful foreground refreshes; background checks are unavailable.

Why 60 seconds and three failures means 120–180 seconds

With immediate failed checks, the first failure arrives between 0 and 60 seconds after outage onset. The second follows 60 seconds later and the third another 60 seconds later: detection falls between 120 and 180 seconds (2–3 minutes). A single-failure threshold instead gives 0–60 seconds.

If every failed check takes 10 seconds to time out on that same fixed-start schedule, three failures give 130–190 seconds. This includes the response delay but still excludes notification latency and real-world scheduling variation.

Connect a published status page for free, account-free reads, or calculate a downtime budget for a separate availability target.