An address is not a queue, and the numbers only read together.
Broker and acceptors
Connect each broker per environment. Its identity, version and uptime; address memory and disk store shown against the limits that make it block producers; and the acceptors it is listening on, with start, stop and reload.
Addresses and queues
Artemis routes to an address and queues bind under it — anycast shares each message between them, multicast gives every one a copy. Depth, consumers, delivering and scheduled per queue, plus the filter it applies — and a queue edited in place, with the scheduled messages a browse never shows listed and delivered now when they should not wait.
Unrouted messages
The count of messages the broker accepted and then routed nowhere, because they matched no binding. The producer saw no error and the message is in no queue — and this is the only place that number appears.
Producers, consumers, sessions
Who is attached, over which connection and session — and why a queue with a consumer is not moving: a registration whose session has gone, or a selector that matches almost nothing.
Durable subscriptions
On Artemis a subscription is a multicast queue, so a subscriber that has gone away is a queue with no consumer — and what has accumulated for it is that queue’s depth.
Dead-letter and expiry
Where redelivery gives up and after how many attempts, and a dead-letter queue counted by the address each message originally failed on — carried on the message itself, so it can be retried back to it. Expiry is a separate address and stays separate.
Messages are sent to an address. The routing type decides what happens next.
An anycast address shares each message between the queues bound under it, so they compete and one consumer gets it. A multicast address gives every bound queue its own copy — and a durable subscription is one of those queues, which keeps accumulating while its subscriber is away. The console draws both, because the operational questions they raise are different.
The subscriber that left still costs you.
A durable subscription keeps accumulating while its subscriber is disconnected — which is exactly what it is for, and exactly how a store quietly fills. On Artemis it is a queue, so the question has a plain answer: which subscription queues have no consumer, and how deep have they got.
| Subscription | Address | Consumers | Messages held |
|---|---|---|---|
| pricing-eu | pricing.updates | 1 | 0 |
| pricing-us | pricing.updates | 1 | 3 |
| pricing-apac | pricing.updates | 0 | 412,880 |
Deleting a subscription queue whose consumer never came back frees the store by throwing away everything held for it. The confirmation names the queue and counts the messages it will lose, it requires operate rights, and it is refused in a read-only environment.




The console reports what your connected Artemis broker actually exposes, rather than assuming a capability is present because the protocol allows it.
Browsing is a read. Everything else is not.
Browsing a queue, reading an address and listing subscriptions are reads — and on Artemis a browse genuinely is one, so they stay available even where an environment is locked down. Purging a queue, disabling it, removing a subscription and retrying from the dead-letter address change state, and each is checked against the environment policy first.
- 01The broker’s own security settings — roles on an address match — still apply underneath the scoped role
- 02Purging a queue names its dead-letter address, says the messages will not reach it, and counts them
- 03Disabling a queue is asked separately from pausing it, because only one of them stops it receiving
- 04Retrying a dead-lettered message sends it back to the address it originally failed on
- 05A queue edit that can drop messages — a new filter, a ring size, purge on no consumers — asks for a reason
- 06In Commercial, the fields a data masking rule covers are masked in every message the console reads, and every unmasked read is recorded
actor deniz@northwind-bank.example
env staging
broker artemis broker: amq-core-01
resource queue orders.inbound.DLQ
action browse-messages inspected: 27
outcome accepted read-only inspectionReads are recorded too, at the read-audit tier — which is what makes “who looked at the dead-letter queue” an answerable question.
Audit and accountability →
