Nothing is emitted on a Server-Sent Events stream for twenty minutes and clients quietly vanish — what does an idle stream need?

## Silence is the hazard A fourteen-hour firing reports a stage change every few minutes and says absolutely nothing in between. From outside the process, those quiet stretches look exactly like a hung server: the response is open, no bytes are moving, and nobody on the path can tell the difference between "nothing has happened" and "nothing will ever happen again". The emitting side's answer is to stop being silent. Write something that costs nothing and means nothing. ## What it writes - **A comment line** — a line the event-stream grammar defines as ignorable, carrying no field and dispatching no event. (Its exact spelling is part of the format itself; the duty to send one periodically is the emitting side's.) - **Nothing reaches the application.** No handler fires, no counter moves, no `data` is delivered. That is the property that makes it safe to send on a timer. - **Nothing about it is addressed to the client's behaviour.** It does not set a delay, does not identify a position in the feed, and does not acknowledge anything the client sent. ## How often, and how strongly the specification says it | claim | strength | |---|---| | send a comment on an idle stream | an authoring note — a recommendation, not a requirement | | roughly every fifteen seconds | the interval the note suggests | | a client may assume one is coming | no: a conforming client must work without it | | the interval is negotiable with the client | no mechanism exists for that | This MUST-versus-suggestion distinction matters in an interview. A candidate who says "the spec requires a heartbeat every fifteen seconds" has promoted an authoring note to a protocol rule and, worse, implied a client may depend on one. The honest statement is: nothing on the wire obliges you, and you should do it anyway. ## The two things it actually buys 1. **It keeps the path warm.** The stated reason for the note is that a quiet connection is liable to be dropped after a short idle period by something in between. Fifteen seconds is comfortably under the intervals that do that. (What an intermediary does to a long-lived response, and how to configure around it, is a separate subject.) 2. **It bounds time-to-discovery of a departed receiver.** A one-way response gives the emitting side no inbound signal, so a receiver that left is usually discovered when a write fails. On a stream that writes every fifteen seconds, that discovery is bounded by fifteen seconds. On the kiln stream without comments, the next write might be twenty minutes away — and until then the emitting side happily keeps a subscription alive for a viewer who closed the page. The second reason is the one that survives even in a deployment with nothing in between, which is why "only an intermediary makes this necessary" is a weak answer. ## What it is not - **It is not the reconnect delay.** The field that tells a client how long to wait before re-opening applies to a response that has already ended; it does nothing for one currently open. Confusing the two is the most common error on this material. - **It is not an application-level heartbeat.** Sending a real event with an empty or dummy payload does keep the path warm, but it dispatches an event, so every client now has to recognise and discard it. The comment exists to avoid exactly that tax. - **It is not a liveness probe with a reply.** Nothing comes back. A duplex protocol can send a probe and expect an answer; a one-way response has no channel for one. - **It is not a substitute for bounding how long the response lives.** A stream can be diligently kept alive for fourteen hours and still be a response held open longer than is wise. ## The operational shape In practice the emit loop waits on the source with a timeout rather than waiting indefinitely. When the source produces an event, write and flush it. When the wait times out, write and flush a comment instead. That single change gives you both properties at once — the stream is never quiet for longer than the timeout, and the write path is exercised on the same cadence — and it costs a handful of bytes per interval per open response. That cost is worth stating out loud at scale: a few bytes every fifteen seconds is nothing per viewer and is a real, continuous write volume across many thousands of open responses, which is one more reason the interval is a choice rather than a constant handed down by the protocol.