Compare SSE and WebSockets

Incident updates flow server to browser. Operator commands flow browser to server. That split is the whole decision, not a popularity contest between protocols.

SSE is a long HTTP response with Content-Type: text/event-stream. The server pushes events; the browser reads them with EventSource. Reconnection is built in. See Server-Sent Events for the full picture.

WebSockets start as an HTTP upgrade, then become a framed two-way channel on ws: or wss:. Both sides send messages at any time. See Introduction to WebSockets.

Same board, two shapes

For viewers, the arrow is one-way:

Status server ===SSE===> Viewer tabs

For operators who acknowledge incidents and send notes, you need return traffic:

Operator console <==WebSocket==> Status server

You can mix both. Viewers subscribe to /events over SSE. Operators open /operator over WebSockets. HTTP still loads the first snapshot and posts commands that do not need a live socket.

What pushes you away from SSE

SSE cannot carry client messages on the same connection. If operators sent ten commands per second, opening a second channel for each command gets awkward fast.

SSE also rides on HTTP/1.1 connection limits when you open many streams on one origin. One or two streams is normal. A dozen tabs each holding their own stream can hurt on old HTTP/1.1 deployments.

What pushes you away from WebSockets

WebSockets cost more moving parts: upgrade headers, proxy config, your own heartbeat, your own reconnect logic. A read-only feed that updates a few times per minute rarely earns that overhead.

Sketch both options for your board. List authentication, proxies, reconnect behavior, and the snapshot fallback for each. The sketch that needs fewer custom parts usually wins.

Try this on your own project: draw message arrows for each actor, mark direction and frequency, then pick SSE, WebSockets, or polling per arrow instead of one label for the whole app.