Dead Letter Queue

The Dead Letter Queue (DLQ) explorer is one of CritterWatch's most powerful operational tools. It provides a unified view of failed messages across all services and their durability databases, with the ability to replay, discard, or edit-and-replay individual messages or batches.

Querying Dead Letters

The DLQ page opens with a query form that filters dead-lettered envelopes:

Filter	Description
Service	Scope to a specific monitored service
Tenant	Scope to a specific tenant (for multi-tenant services)
Message Type	Filter by the .NET type name of the message
Exception Type	Filter by the exception class that caused the failure
Time Range	From/to timestamps for when messages were dead-lettered
Max Results	Limit the number of results returned

Click Query to execute the search. Results appear in a table with pagination.

Result Table

Each row in the results shows:

Column	Description
Message Type	The .NET type name of the failed message
Exception Type	The exception class that caused failure
Attempts	How many times Wolverine attempted processing
Dead-Lettered At	Timestamp when the message was moved to DLQ
Message ID	The Wolverine envelope GUID

Click any row to open the Message Detail panel.

Message Detail

The detail panel shows the full envelope:

• Message body — formatted JSON of the message payload
• Exception message — the last exception thrown by handlers
• Full stack trace — expandable view of the exception stack
• Envelope headers — correlation ID, causation ID, source address, scheduled time
• Processing history — timeline of each delivery attempt

Actions

From the detail panel, you can:

Replay — send the message back through the original processing pipeline without modification. The message is removed from the DLQ and re-enqueued for delivery.

Edit and Replay — opens a JSON editor pre-populated with the message body. Modify the payload (correcting data errors, fixing missing fields, etc.) and click Replay to send the modified version. The original dead-lettered message is discarded.

Discard — permanently delete the message from the DLQ. This is irreversible and requires confirmation.

Edit and Replay Use Cases

Edit-and-replay is most useful when a message failed due to data issues rather than code bugs:

• A required field was null that has since been populated
• A numeric value exceeded a validation range that has been corrected
• An external ID changed between when the message was sent and when it was processed

Batch Operations

The toolbar above the results table provides batch operations applied to all messages matching the current filter:

Replay All — replay every message in the current result set. A progress indicator shows completion. Requires confirmation when the result count is large.

Discard All — permanently delete all messages in the result set. Requires explicit typed confirmation (type "DISCARD" to confirm) to prevent accidental data loss.

Exception Grouping

The Group by Exception toggle collapses results into a summary by exception type, showing:

• Exception class name
• Count of messages with this exception
• Most recent occurrence
• Replay All for this exception button

This makes it easy to identify whether a spike in DLQ messages stems from a single root cause (e.g., a downstream service outage or a schema migration issue).

Export

Click Export to download the current result set as:

• CSV — exception type, message type, envelope ID, dead-lettered timestamp
• JSON — full envelope data for each message

Multi-Tenant DLQ

For multi-tenant services, the Tenant filter scopes the query to a specific tenant's message store. Each tenant has an independent DLQ; messages from one tenant do not appear in another tenant's results.

Replay and discard operations target the specific tenant's database, ensuring data isolation between tenants.