Blazor Server Reconnection and Circuit Lifetime: What Actually Survives a Network Blip

A user types a long note in a Blazor Server form, the Wi‑Fi drops for a few seconds, and the page shows a reconnecting overlay. When the connection returns the form is still there. A minute later the same blip happens and the form is gone. That difference is not random. It is the circuit lifetime and the reconnection window.

Thesis: Blazor Server keeps component state on the server inside a SignalR circuit scoped to one browser tab. Reconnection can restore that in‑memory state only while the circuit is retained. Once the circuit is disposed the state is gone unless you persisted it yourself.

Circuit is the unit of state, not the browser

Blazor Server executes components on the server and sends render diffs to the browser over a SignalR circuit. The circuit is created when the page loads and is tied to that tab. UI state lives in the component tree on the server, not in the browser DOM.

Because of that, a transient network loss does not immediately destroy state. The framework tries to re‑establish the SignalR connection automatically. If it succeeds within the retention window, the same circuit is reused and the component tree continues where it left off.

If reconnection fails past the timeout, the circuit is disposed on the server and all in‑memory component state is released. A new connection creates a new circuit with fresh state.

Reconnection UX you can control

The default reconnecting overlay is built in. You can replace it to make the experience explicit and to avoid user actions during reconnect.

A common customization point is the root component. In a Blazor Server app the host page renders the app and the framework shows a reconnecting UI while the circuit is in the reconnecting state.

// Program.cs
builder.Services.AddServerSideBlazor(options => {
    options.DisconnectedCircuitRetentionPeriod = TimeSpan.FromMinutes(3);
});

Run this in the web project where Program.cs lives. It requires edit permission for the project file. The setting controls how long the server keeps a disconnected circuit alive waiting for a reconnect. A longer period improves UX for brief drops but increases server memory use.

To surface circuit events for diagnostics, enable logging for the circuits category in appsettings.json. This is a safe read‑only change.

{\"Logging\": {\n  \"LogLevel\": {\n    \"Microsoft.AspNetCore.Components.Server.Circuits\": \"Information\"\n  }\n}\n}

Expected checks are log entries indicating circuit started, reconnected, and disposed. Those entries help you confirm the timing of retention and disposal. Risk: verbose logging in production increases log volume.

Circuit limits and scale‑out trade‑offs

Each active circuit consumes server memory and a SignalR connection. Circuit count is limited by server memory and connection limits. High concurrency can exhaust resources if circuits are not disposed promptly.

Reconnection does not survive a server restart or app pool recycle. State that was only in memory is lost when the circuit is recreated.

Scale‑out adds constraints. Without a backplane or sticky sessions, a reconnected client may attach to a different server instance and lose its previous circuit because the circuit state is not shared. Hosting design must account for that.

Check it yourself

Open the app in a browser and use dev tools to throttle or disconnect the network. Observe the automatic reconnecting UI and whether the UI recovers or resets after the retention period.

Open the same app in multiple tabs. Each tab creates an independent circuit. Changes in one tab do not affect component state in another tab, which confirms the per‑tab scope.

For production readiness, persist important in‑progress data outside the circuit, for example to a database or session store, and treat reconnection as a UX convenience, not a durability guarantee.