Handling Network Disconnections and Reconnection in SignalR Applications

For example, a real-time dashboard may need to keep trying for a longer period, while a short-lived interactive session may stop reconnecting after a limited number of attempts.

SignalR allows developers to configure custom retry delays.

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .withAutomaticReconnect({
        nextRetryDelayInMilliseconds: retryContext => {

            if (retryContext.elapsedMilliseconds > 120000) {
                return null;
            }

            const delay = Math.min(
                1000 * Math.pow(
                    2,
                    retryContext.previousRetryCount
                ),
                30000
            );

            return delay;
        }
    })
    .build();

This policy uses exponential backoff.

The waiting time increases after each unsuccessful attempt, up to a maximum of 30 seconds.

The policy stops retrying when the total elapsed reconnection time exceeds two minutes.

Returning null tells SignalR to stop automatic reconnection.

Exponential backoff is useful because it prevents clients from continuously sending connection requests when the server is unavailable.

For applications with many simultaneous clients, adding random jitter to retry delays can further reduce the possibility of all clients reconnecting at the same time.

Implementing Automatic Reconnection in a .NET Client

SignalR is not limited to browser applications. You can also use it in desktop applications, background services, and other .NET clients.

The .NET client provides similar functionality through WithAutomaticReconnect.

First, create a connection:

using Microsoft.AspNetCore.SignalR.Client;

var connection = new HubConnectionBuilder()
    .WithUrl("https://localhost:7001/chathub")
    .WithAutomaticReconnect()
    .Build();

Next, handle connection lifecycle events.

connection.Reconnecting += error =>
{
    Console.WriteLine(
        "Connection lost. Attempting to reconnect.");

    return Task.CompletedTask;
};

connection.Reconnected += connectionId =>
{
    Console.WriteLine(
        "Connection restored successfully.");

    return Task.CompletedTask;
};

connection.Closed += error =>
{
    Console.WriteLine(
        "SignalR connection closed.");

    return Task.CompletedTask;
};

Finally, start the connection.

await connection.StartAsync();

The .NET client follows the same default retry schedule as the JavaScript client.

However, just like the JavaScript implementation, WithAutomaticReconnect does not retry failures from the initial StartAsync operation. Initial connection retries must be implemented separately.

Restoring Application State After Reconnection

Successfully reconnecting to SignalR does not automatically restore every part of the application's previous state.

This is an important consideration for production applications.

For example, consider a notification dashboard that subscribes to a group based on the user's account ID.

When the connection is restored, SignalR establishes a new connection. The new connection is treated as a separate connection on the server, and its connection ID changes.

Therefore, the application should restore any required group memberships.

You can handle this inside the onreconnected callback:

connection.onreconnected(async () => {
    await connection.invoke(
        "JoinUserGroup",
        currentUserId
    );

    await refreshNotifications();
});

The server can define a hub method for joining the required group:

public class NotificationHub : Hub
{
    public async Task JoinUserGroup(string userId)
    {
        await Groups.AddToGroupAsync(
            Context.ConnectionId,
            $"user-{userId}");
    }
}

The application also refreshes notifications after reconnecting.

This is important because messages sent while the client was disconnected may not have been received.

For reliable applications, do not assume that reconnecting means no messages were missed. Use a database-backed message history, event sequence numbers, or another synchronization mechanism to retrieve missing information.

Also, validate the user's identity and authorization on the server. Do not trust a client-provided user ID alone when assigning group membership.

Advantages and Disadvantages of Automatic Reconnection

Advantages

1. Improved user experience: Users do not need to manually refresh the application after every temporary network interruption.
2. Reduced manual implementation: SignalR handles retry scheduling and connection lifecycle transitions.
3. Flexible retry policies: Developers can configure retry delays and maximum retry durations.
4. Better application availability: Temporary network interruptions can be recovered without restarting the entire application.
5. Lifecycle notifications: Applications can update the user interface based on connection status.

Disadvantages

1. No guaranteed message delivery: Messages sent while the client is disconnected may be missed.
2. Initial connection failures require separate handling: Automatic reconnection only handles interruptions after a successful connection.
3. Additional server load: Many clients reconnecting simultaneously can create a temporary increase in server traffic.
4. Application state must be restored: Group memberships and other connection-specific information may need to be established again.
5. Retry limits: The default policy stops after four failed attempts, which may not satisfy every application's requirements.

Best Practices for Handling SignalR Disconnections in Production

Display Connection Status to Users

Always provide clear feedback when a real-time connection is interrupted.

For example, a chat application can display Connecting, Reconnecting, Connected, or Disconnected.

This prevents users from assuming that their messages or actions are being processed.

Use Exponential Backoff

Avoid continuously retrying connection attempts at very short intervals.

Exponential backoff reduces unnecessary traffic and gives the server time to recover.

Add jitter when many clients may reconnect simultaneously.

Restore Group Memberships

If your application uses SignalR groups, rejoin the required groups after reconnection.

Do not assume that the previous connection's group membership automatically transfers to the new connection.

Synchronize Missed Messages

Automatic reconnection does not provide guaranteed delivery of every message sent during a disconnection.

Retrieve missed notifications or messages from a reliable server-side source after reconnecting.

Make Operations Idempotent

A client may not know whether an operation completed before the connection was interrupted.

For important operations, use unique request identifiers or idempotency keys so that retrying does not accidentally create duplicate payments, orders, or transactions.

Monitor Connection Failures

Log connection interruptions, retry attempts, successful reconnections, and permanent disconnections.

These details help identify network problems, server instability, and infrastructure configuration issues.

Common Mistakes and Troubleshooting

Summary

Network interruptions are unavoidable in real-time applications. A SignalR connection can be lost because of internet problems, server restarts, proxy timeouts, or inactive browser tabs.

ASP.NET Core SignalR provides automatic reconnection through WithAutomaticReconnect, allowing applications to recover from temporary connection failures without requiring users to refresh the page.

However, reconnection is only one part of a reliable real-time communication strategy. Applications must also handle initial connection failures, manage connection states, restore group memberships, and synchronize messages that may have been missed.

For production applications, combine automatic reconnection with exponential backoff, proper error handling, persistent message storage, and connection monitoring.

This approach helps build SignalR applications that remain usable even when network conditions are unreliable.