Configure error handling

Component: NServiceBus
NuGet Package NServiceBus (7-pre)
This page targets a pre-release version and is subject to change prior to the final release.

Configure the error queue address

When an endpoint fails to process a message successfully, NServiceBus automatically retries the message for the configured number of times. If the message could not be processed successfully even after the retried attempts, then NServiceBus forwards that message to the designated error queue.

When running with transport transactions disabled NServiceBus will perform a best-effort error message forwarding, i.e. if moving to the error queue fails, the message will be lost.
When running with transport transactions disabled. Both Immediate Retries and Delayed Retries will be automatically disabled when transactions are turned off.

The default error queue name is error but some transports reqire it to be explicitly be configured.

This can be done in several ways:

Using Code

Configuring this feature via app.config, IConfigurationProvider, or IProvideConfiguration is not recommended in Version 6, use the code configuration API instead. The configuration sections will be removed in Version 7.

Error message header customizations

Before a message is moved to the error queue it is possible to inspect and modify its headers including error forwarding headers.

The following snippet shows how to configure header customizations and perform header value modification.

var recoverability = endpointConfiguration.Recoverability();
    failed =>
        failed.HeaderCustomization(headers =>
            if (headers.ContainsKey("NServiceBus.ExceptionInfo.Message"))
                headers["NServiceBus.ExceptionInfo.Message"] = "message override";

Error queue monitoring

Administrators should monitor the error queue in order to detect when problems occur. The message in the error queue contains relevant information such as the endpoint that originally processed the message, exception details, etc. With that information an administrator can investigate the problem and solve it, e.g. bring up a database that went down.

Monitoring and handling of failed messages with ServicePulse provides access to full exception details (including stack-trace). ServiceInsight offers advanced debugging capability providing additional information like exception details as well as visualizing the flow of messages. Both ServiceInsight and ServicePulse provide a retry functionality that sends the failed message from the error queue back to the endpoint for re-processing. For more details on how to retry a message using ServicePulse, see Introduction to Failed Messages Monitoring in ServicePulse. To retry a message using ServiceInsight, see Managing Errors and Retries in ServiceInsight.

If either ServicePulse or ServiceInsight are not available in the environment, the retry operation can be performed using the native management tools appropriate for the selected transport:


The MSMQ command line tool ReturnToSourceQueue has been deprecated and moved to ParticularLabs/MsmqReturnToSourceQueue.


Last modified