How SSE Automatic Reconnection Works in JavaScript

Server-Sent Events (SSE) provide a native, persistent HTTP connection enabling servers to push real-time updates to web clients using the EventSource interface. One of the primary advantages of SSE over WebSockets is its built-in, automatic reconnection capability, which requires no custom polling or retry loops in client-side JavaScript. This article explains how the browser orchestrates these reconnects, how the server configures retry delays, and how the Last-Event-ID mechanism guarantees seamless data recovery after network interruptions.

The Native EventSource Reconnect Cycle

When you instantiate a connection using const eventSource = new EventSource('/events');, the browser creates a long-lived HTTP connection. If this connection terminates unexpectedly due to network issues, a server restart, or a timeout, the browser’s built-in networking layer automatically initiates a reconnect.

During a connection drop: 1. The eventSource.readyState changes from 1 (OPEN) to 0 (CONNECTING). 2. The onerror event handler triggers on the client, notifying the application of the issue. 3. The browser pauses for a pre-configured delay period. 4. The browser automatically issues a new HTTP GET request to the same URL without requiring developer intervention. 5. Once re-established, readyState returns to 1, and event streaming resumes.

Controlling Delay with the retry Field

By default, most browsers wait roughly 3,000 milliseconds (3 seconds) before attempting to reconnect. The server can dynamically change this interval by sending a retry instruction anywhere in the event stream:

retry: 5000
data: Connection configured with a 5-second retry interval.

When the browser receives this message, it updates its internal retry timer to the specified number of milliseconds (in this case, 5 seconds). If the connection breaks at any subsequent point, the browser will wait 5 seconds instead of the default duration before sending the next connection request.

Resuming Streams Using Last-Event-ID

To prevent data loss during connection drops, the SSE protocol includes state-tracking functionality via event IDs. The server can attach an id field to any message:

id: 101
data: First update

id: 102
data: Second update

The browser tracks the most recently received ID in memory. When the connection drops after receiving event 102 and the browser automatically reconnects, it includes an HTTP header in the new request:

Last-Event-ID: 102

The server reads this header and can immediately replay or resume messages starting from ID 103, ensuring no messages are missed while the client was disconnected.

Preventing Automatic Reconnections

Automatic reconnection will continue indefinitely unless one of the following conditions occurs: