CritterWatch 1.1 groups dead letters by failure cause and acts on each group at once
CritterWatch 1.1 groups dead letters by the failure that produced them, merging matches across every monitored service and database into one row. An operator can replay, archive, restore or discard a whole group as a single tracked operation with a required reason. The release also exposes the same loop through MCP, so teams running Wolverine can handle incidents faster and check whether replayed messages failed again.
Key points
- Grouping relies on Wolverine 6.54+ fingerprints; older clients are grouped by exception type only
- Replay, archive, restore and discard each require a reason that is stored in the audit log
- Only one operation can run against a failure group at a time
- Archive removes messages from queue counts and DLQ alert rates without deleting them
- Over MCP, discard returns a preview and a single-use confirmation token valid for five minutes
- New RBAC permissions: dlq.archive and dlq.note
JasperFx has shipped CritterWatch 1.1, which reorganizes dead letter handling around the cause of a failure instead of its exception type. Wolverine 6.54 fingerprints each dead letter by exception and throw location, and CritterWatch merges those fingerprints across services and tenant databases. A failure that spans several services and many databases therefore appears as a single row rather than a scatter of entries.
From that view, an operator can replay, archive, restore or discard an entire group as one tracked operation, and each action needs a reason that lands in the audit trail. Progress is reported per database, and a Check re-failures figure reveals whether replayed messages failed again. Archiving keeps messages recoverable while removing them from queues, counts and alerts. The same workflow is available to AI agents over MCP, with discards requiring a preview and confirmation token first.
Real-world use
- Replaying the failed messages from several services in one operation after a payment gateway outage
- Tracking a bug in a shared NuGet handler that appears across many tenant databases as one incident
- Archiving messages during a known partner problem and restoring them once the partner recovers
Why it matters
Managing dead letters by cause reduces the risk of replaying the wrong messages or deleting ones that could have succeeded. The audit reason and the re-failure count let you confirm whether an incident is actually over.