Warren is not a replacement for the RabbitMQ management UI. It does not declare queues, edit policies or manage users on the broker. The two overlap in exactly one place: looking at the messages in a queue and doing something with them. This page is about that overlap, honestly, because the management UI is free, already installed, and for a lot of situations enough.
The management plugin ships with RabbitMQ. It configures the broker: exchanges, queues, bindings, policies, vhosts, users, permissions, cluster status, and it shows rates and counts for all of it. Every RabbitMQ operator has it open. For configuration it is the right tool and Warren does not touch that.
It also has a small message-handling corner on each queue page: Get messages, Publish message, Purge, and, with the shovel plugins enabled, Move messages. That corner is where dead-letter work happens, and it was built for a quick look, not for an incident.
| Management UI | Warren | |
|---|---|---|
| Configure the broker (queues, policies, users) | yes | no, by design |
| See which queues are dead-letter queues | no; you know by name | detected by DLX binding or name pattern, sorted to the top |
| Look at messages | Get messages: one page of up to a few dozen, raw payload, headers as nested tables | peek without consuming, pretty-printed JSON, large payloads loaded on demand, base64 blobs collapsed |
| Why a message died | read x-death yourself | timeline per message: which queue, why, how often, when; grouped by cause across the queue; framework headers (x-exception-*, MT-Fault-*) recognised |
| Search inside a queue | no | yes, over payload and headers of the loaded messages |
| Move messages | Move messages: the whole queue to one target queue, via a temporary shovel | selected messages or the first N; to the original exchange and routing key from x-death, to a queue, or to an exchange |
Strip x-death and retry headers before replay | no | yes, so the message gets a fresh retry budget |
| Throttle a replay | no | N messages per second, runs in the background, can be stopped |
| Edit a message before replay | copy the payload into Publish message by hand | edit payload, content type or headers, with JSON validation; the republished message is marked as edited |
| Discard some messages, keep the rest | no; Purge removes everything | discard selected messages with a reason; purge with a reason |
| Export and import messages | no | NDJSON export of selected messages, import into any target |
| Who did what, when | nothing is recorded | audit log per replay, discard, purge and publish, with the per-message outcome and the message as it sat in the queue |
| Queue history | rates for the last hour at useful resolution | sampled every 30 seconds, kept for 7 days, 15 minutes to 7 days per queue |
| Alerting | none; you need Prometheus or a script | rules by regex: messages above threshold, no consumers while messages wait, growth, inflow rate; to Slack, Teams, webhook (Team and Pro) |
| Roles | broker users and tags | viewer, operator, admin; local users or OIDC (Pro) |
| Keyboard | mouse | everything reachable without a mouse; ? lists the shortcuts |
| Price | included with RabbitMQ | Community free for one cluster; Team and Pro paid, one-time |
That covers a lot of days. Do not install another tool for those.
x-death.x-death, so a consumer that gives up after three attempts rejects them on arrival. Warren strips the death bookkeeping.Declare or delete queues and exchanges, edit bindings or policies, manage broker users and permissions, show cluster or node health, or run shovels and federation. For all of that you keep the management UI. Warren reads through the management API and replays over AMQP with a least-privilege user, and it never changes broker configuration.
Warren also does not fix the reason messages die. Idempotent consumers, a retry topology with a wait queue and a parking lot, and alerts that fire early remove most manual replays. Warren is for the ones that remain.
Most teams keep the management UI for configuration and open Warren when a dead-letter queue has something in it. The two share the broker credentials model: Warren's RabbitMQ user needs the management tag plus read and write on the vhost, nothing more. One container, embedded database, and the demo below starts a broker with real dead letters next to it so you can compare on your own machine.