Response stability monitor

What the monitor observes

This check records up to twelve sequential, explicitly started HTTP probes to the same controlled endpoint. Each accepted response must match a versioned schema and the current run and sequence. A 500 ms interval follows each probe before the next begins. The tool retains successful responses and failed attempts separately rather than converting failure into a guessed latency value. It measures application-response stability along this browser-to-service path, not the health of every device or application on the network.

How to make runs comparable

Keep the browser tab visible and use the same device, network, browser and background workload for a baseline. Start the monitor, review the observations and export the result only when you need a copy. Change one known condition before repeating. The interface never starts measurement just because you visit, reload or navigate to the page. The existing cross-tab measurement lock prevents this check from knowingly overlapping another measurement in the same browser origin. It cannot control other devices, browser profiles or installed applications.

Understanding delayed and failed samples

A validated response above 1000 ms is labelled slow using a disclosed application threshold. That threshold is not a diagnosis of a network outage. HTTP failures, per-request timeouts, invalid bodies and transport failures retain separate outcomes. Median uses the middle accepted observation, averaging the middle pair for an even count. The nearest-rank p95 uses the sorted successful observations and is unavailable with fewer than two. With twelve probes this is a small sample; it should not be presented as a precise estimate of long-term tail latency.

Important sampling limits

There are gaps between samples. A brief outage may begin and end between probes, so a clean result cannot prove that no micro-outage occurred. A failure is not measured IP packet loss, and the endpoint includes application handling and quota checks. Browser main-thread delays and backgrounding can contaminate timing. Raw observations are retained when this happens, but the result is partial and does not attribute the delay to the network. This phase does not inject failures, shape system traffic or identify an ISP, Wi-Fi radio or router as the cause.

Limits, cancellation and retained evidence

Each request has a two-second deadline and accepts at most 4 KiB of response data. The run deadline is twenty seconds, followed by bounded lease cleanup. Admission failure and quota denial stop the sequence without an automatic retry loop. Cancellation preserves observations already recorded, marks the run cancelled and requests session revocation. An 8 MiB admission allowance is reserved rather than transferred; each probe debits 256 KiB for conservative server-side accounting. Reports remain in page memory and are exported only on request, without session capabilities, cookies or IP addresses.

Method references and related tools

W3C Resource Timing explains browser timing and protocol visibility. Cloudflare Workers Response API documents the controlled response mechanism. These standards do not certify the measured network path.

WebSocket resilience · All tools · Overall measurement methodology