Test your SSE connection.

What this SSE test does

The check requests https://netokay.net/v1/control/stream from this browser and reads the response as it arrives. The server sends seven named events: start, five tick events about 500 ms apart, then done, in roughly 2.5 seconds. The table records when each event reached the page and the gap since the previous one.

It is a browser-to-NetOkay control check: it shows whether a short server-sent event stream reaches this browser event by event through its current network path. It does not open your own endpoint and cannot see your proxies.

Run the same SSE stream yourself

In a browser console, subscribe to the named events with EventSource. Each event carries a sequence number and the server-side elapsed time in milliseconds.

const source = new EventSource('https://netokay.net/v1/control/stream');
for (const name of ['start', 'tick', 'done']) {
  source.addEventListener(name, (event) => {
    console.log(new Date().toISOString(), name, event.data);
    if (name === 'done') source.close();
  });
}

From a terminal, watch the same stream with output buffering disabled:

curl -N --max-time 15 https://netokay.net/v1/control/stream

The NetOkay CLI observes it with --transport sse and can point at your own public HTTPS endpoint; see the CLI reference.

Reading the result

• Stream completion: whether all seven events, ending with done, arrived within the 15-second limit. An unfinished stream is an incomplete observation, not a diagnosis.
• Event arrival: over time means the events were spread across the stream, roughly matching the server's 500 ms rhythm. Close together means they landed within about one second of each other, which usually points to buffering somewhere on the path.

Arrival timing alone cannot say which application, intermediary, or client caused grouped delivery, and a 2.5-second stream cannot prove long-term stability.

Why events arrive all at once

When this check shows close together, or your own stream arrives in one block, something between the server and the reader is holding the response until it is complete. The check cannot tell these apart.

• A reverse proxy buffers upstream responses by default; Nginx does unless proxy_buffering is off for that route.
• Compression middleware collects a full chunk before it emits anything, so small events wait in the compressor.
• A CDN, WAF, or corporate proxy stores the whole response before forwarding it.
• The client reads the body only after the response ends, for example a fetch that awaits response.text() instead of reading the stream.

If this check arrives over time and your application does not, continue with SSE not streaming or arriving all at once?.

SSE test FAQ

Does this test my own SSE endpoint?

No. It only reads NetOkay's control stream. For your own public HTTPS endpoint, run the NetOkay CLI with --transport sse from the failing machine, or watch it with curl -N as shown above.

Why do all events arrive together?

Because something on the path buffered them. Proxy response buffering and compression are the usual causes; the guide above shows how to check each side separately.

SSE or WebSocket for streaming?

Server-sent events push text from server to client over an ordinary HTTP response, reconnect on their own, and pass through any proxy that streams responses. WebSocket carries messages in both directions but needs every hop to support the Upgrade handshake. Choose by the direction your data flows.