Degrade gracefully and finish the board

If streaming is unavailable, the board keeps its last confirmed data, labels its age, polls cautiously, and offers a refresh. This is a small part of a live service-status board that streams incidents without losing its ordinary HTTP foundation, but the boundary it creates affects everything that follows.

A live feature should become less live during failure, not become unusable or silently wrong. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to remove the ordinary HTTP path after the live demo succeeds. It makes later failures harder to locate. Instead, keep the snapshot route, expose freshness, switch to a bounded fallback, and test recovery back to the preferred channel. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Ship a live feature that has limits, useful telemetry, a degradation path, and a repeatable failure test matrix. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Run the complete matrix: first load, duplicate event, stale event, disconnect, server restart, slow client, revoked user, and fallback. Hand the result to someone else and see whether the behavior is clear without an oral explanation.