Website uptime monitoring and false alarms

What it means

An uptime probe is a check of specified service behavior from a particular observation point. Its meaning depends on what it tests: receiving a response is not the same as validating page content or completing a user action.

The hardest sampling mistake is treating two successful checks as proof that everything worked between them. The simulation makes that unobserved gap explicit. It places instantaneous probes on a fixed schedule and counts how many fall inside an outage you supply; it does not contact or diagnose a real website.

Try it

Simulation: begin with Probe interval (s) = 60, Outage starts at (s) = 10 and Outage duration (s) = 25. Change only Outage duration (s) to 70, then inspect the count and explanation. Select Compare with baseline to display the two outcomes; this is a comparison with the fixed starting example, not a history of edits. Reset returns to the starting inputs and clears errors and the comparison.

The initial example and explanation remain readable without JavaScript; the interactive controls require JavaScript. Nothing is sent to a website or monitoring service.

The initial result is “0 probe(s) intersect the outage.” Outage [10, 35) seconds; first candidate probe 60s. The next probe is at or after recovery, so this schedule misses the event. A successful sample describes that instant and vantage point; it does not prove continuous global availability.

Keep Probe interval (s) at 60 and Outage starts at (s) at 10. Only the outage duration changes, so the comparison isolates whether extending the event across the next scheduled probe changes the count.

Reset restores Probe interval (s) to 60, Outage starts at (s) to 10 and Outage duration (s) to 25. It clears input errors and the comparison with baseline. There is no running clock or stored event history. Reset preserves your independent choices to open or close FAQ answers and About this model.

How it works

With a 60-second interval, the scheduled probe instants are 0, 60, 120 seconds, and so on. The first candidate is the first scheduled instant at or after the outage starts. It counts only if it occurs before recovery. This intermediate comparison—not the duration alone—determines whether the schedule samples the event.

The notation [start, end) means that the starting instant is included and the ending instant is excluded. Under this declared rule, a probe exactly at outage start is inside the event; a probe exactly at recovery is outside it. For example, an outage [60, 120) contains one probe, at second 60, not two. A zero-duration outage at second 60 contains no probe, even though 60 is a scheduled instant.

Keep sampling, check results and alerts separate. This model counts samples inside a supplied event. A real check evaluates its configured success condition, and an alert policy decides when those results warrant notification. A failure from one location can be genuine while a claim of site-wide failure still exceeds the evidence.

Worked example

This is a synthetic baseline, not a captured monitoring record.

Recovery occurs at 10 + 25 = 35 seconds, giving the outage [10, 35). The probe at second 0 is too early, and the first candidate at second 60 is too late. Therefore, 0 probe(s) intersect the outage.

Under these assumptions, the service could be unavailable throughout that 25-second event while both surrounding probe instants fall outside it. The count is correct for the supplied schedule; interpreting it as “no outage occurred” would be the error.

What changes when the condition changes

Change only Outage duration (s) from 25 to 70. Keep the interval at 60 seconds and the start at 10 seconds.

The result becomes “1 probe(s) intersect the outage.” Outage [10, 80) seconds; first candidate probe 60s. At least one scheduled sample intersects the event.

Recovery now occurs after the probe at second 60, so that probe falls inside the outage. The schedule did not improve; the longer event crossed an existing sample instant. This demonstrates an intersection, not an alert being delivered: alert rules are outside the model.

In practice

For a service you own or are authorized to observe, begin with a read-only review of existing monitoring configuration and recorded results. Record the target, success condition, probe location, interval and affected time window. A useful observation is specific: this check failed from this location at this time—not simply “the website was down.”

Compare like with like. Another permitted vantage point or relevant user-journey evidence can help establish whether the symptom extends beyond the original check. A failed request and an incorrect page are different observations; a check that tests only one cannot establish the other. Keep conflicting results rather than averaging away their context.

Stop short of a corrective production change when the evidence does not distinguish a target failure from a path or monitoring problem. Treat the cause as unknown and identify the missing observation. Neither this simulated count nor an isolated successful probe justifies disabling alerts or declaring recovery. This page supports evidence interpretation, not a production monitoring change procedure.

Limits and unknowns

The scene starts with a known synthetic outage and asks whether scheduled instants intersect it. It does not discover an outage, measure an uptime percentage, or determine what real visitors experienced. Real probes take time and can be affected by timeouts, routing and regional conditions.

The count also does not show whether a monitoring system would notify you: content rules, repeated-failure requirements and notification delivery are not evaluated. Actual service availability and the cause of any real failed check remain unknown without independent observations.

Invalid input removes the calculated outcome; it is not a zero-probe result. Correct the entry or use Reset before interpreting another result. No account, server, request or production setting is accessed.

What to carry forward

Report what your monitoring actually established: which check passed or failed, from where, and when. Before treating that evidence as a broader availability claim, ask which times, paths and user actions were not tested. That gap determines the next evidence to collect.