SSE stream stability

What this stream check establishes

This diagnostic receives six numbered server-sent data events from our fixed endpoint. It validates event type, run identity, scenario, sequence number and payload contract before counting an event. A complete result requires the matching final marker and end of the response. HTTP 200 alone is not a successful test. Choose the continuous scenario to observe uninterrupted delivery, or the controlled interruption scenario to exercise a single explicit resume. Neither mode tests an arbitrary website or your own production API.

Continuous control and planned interruption

The continuous scenario expects IDs 1 through 6 in one response. In the resume scenario the service sends IDs 1 through 3, a checkpoint and a deliberate end of stream. This client waits 500 ms, then makes exactly one request with Last-Event-ID: 3 and expects IDs 4 through 6. A missing checkpoint, incorrect sequence, invalid response or denied resume prevents a continuity success. This is an application-level synthetic scenario, not a network disconnection, a TCP reset or proof of durable event storage.

Why this uses a fetch-based SSE reader

A fetch reader allows the existing signed session headers to remain outside URLs. The diagnostic incrementally parses UTF-8 event framing, comments, CR/LF line endings, data fields and event IDs across arbitrary response chunks. Its strict mode rejects malformed UTF-8 rather than silently repairing it. This tests the implemented diagnostic reader and controlled service, not native EventSource automatic reconnection or every browser client. Responses are processed as bytes arrive; a completed download is not substituted for actual streaming.

Reading continuity and timing separately

Validated IDs establish the observed event sequence for this run. Arrival timestamps use the browser monotonic clock; within-stream gaps describe observed delivery spacing rather than packet loss or one-way network latency. Server handling, browser scheduling and proxy buffering can affect those gaps. Recovery is measured from the observed planned EOF to the first validated event on the resumed response and includes the configured 500 ms wait. Existing browser timing gates may make the result partial while retaining a verified sequence and raw observations.

Budgets, Stop and privacy

Six data events use a nominal 250 ms cadence. Each response has a six-second deadline, a 32 KiB read cap and independent parser limits. The run has a twenty-second deadline plus bounded cleanup. At most two streams are used by a run, and the session coordinator permits at most two concurrently. Stop closes in-flight server streams and requests session revocation; no retry loop runs after an unexpected failure. Admission reserves an 8 MiB allowance without transferring it; each stream conservatively debits 256 KiB. Reports remain in page memory until explicitly exported and omit credentials, event payloads, cookies and IP addresses.

Use results as controlled evidence

Run the continuous control first under a stable foreground browser, then the planned-resume scenario without changing other conditions. Export reports only when you need to compare them. A verified resume demonstrates the six-event diagnostic sequence under those conditions; it does not certify your application retry policy, real-world outage recovery or long-term availability. The separate HTTP response inspector and stability monitor provide different observations without claiming to isolate Wi-Fi, router or ISP faults.

Method references and related tools

WHATWG server-sent events defines event framing and Last-Event-ID. Cloudflare Streams describes response streaming. 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