Queue detail and message counters

Updated 20 October 2026 · applies to 1.3.1 · Commercial

Queue detail, opened from a row on the Queues screen, pauses, disables, purges or deletes one queue and shows its configuration and message counters. On an Apache Artemis (formerly ActiveMQ Artemis) queue it lands on Messages, because that is what someone opening a queue came for — that tab has its own page, Message operations. Beside it: Overview, the queue's full configuration; Scheduled and In flight, the two kinds of message a browse cannot show; Groups, the message groups pinned to a consumer; Counters, a chart of the history the broker kept itself; and Metrics, the history BROKA keeps of the queue.

This is the distinction the screen is built around.

	What it does	What arrives while it is on
Pause	Stops handing messages out	Keeps arriving and accumulating
Disable	Stops being a routing target	Nothing. Messages sent to the address reach the other queues bound there — or nowhere

Putting them behind one switch would make the second look like the first, which is how a queue silently stops receiving. So they are two controls — Pause in the header, Disable in the header's ⋯ menu — disabling asks for confirmation, and the confirmation says in as many words that this is not the same as pausing. Pause is not confirmed: Resume on the same button undoes it, and Enable, in the same menu, undoes a disable. The ? beside the queue's name explains the difference too.

A disabled queue also carries a banner on the page for as long as it stays disabled. What it already holds stays either way.

Purge does not dead-letter

Purge discards every message in the queue immediately. They are not sent to the dead-letter address — they are gone. The confirmation names the dead-letter address the queue would otherwise use and says the messages will not reach it, and it counts what will be discarded.

Delete destroys the queue and everything in it, and disconnects its consumers: the broker refuses the delete otherwise, so the console does it rather than presenting a failure.

Purge and Delete are in the header's ⋯ menu, and they ask for a reason. Every one of these is a write, recorded in the audit trail, and they appear only for someone allowed to change this broker — in a read-only environment or on a read-only connection they are not there and the page says why. There is no back button on the page: the breadcrumb above it returns to Queues.

Editing, and the messages the broker holds back

Edit, in the header, changes the queue's settings; the dialog, field by field, is on Editing a queue. The Scheduled, In flight and Groups tabs have a page of their own: Scheduled, in-flight and grouped messages.

Overview: how old the backlog is

The Overview opens with the queue's live counts — messages, consumers, delivering and scheduled — and the Oldest message: how long the message at the head of the queue, the next one it will deliver, has waited, by the broker's own clock. A count says how much is waiting; this says how long, and it is usually the first figure to move when a consumer falls behind. It reads a dash when nothing is waiting, or when the message at the head carries no timestamp, and hovering the dash says which. The same age is available as an alert metric, so a rule can fire on how long messages wait rather than on how many there are — see Alerts.

Overview: four cards, four questions

Delivery — is it delivering, and on what terms. Its state (delivering, paused or disabled), the filter it applies (or a dash meaning it takes everything routed to it), its consumer limit, whether it is exclusive, message-group buckets and key, how many groups are pinned now and whether they rebalance when a consumer attaches, and the consumer count and delay it waits for before dispatching at all.

Retention — what survives. Durable or lost on restart, temporary, auto-created by a client or by an operator, auto-delete, purge-on-no-consumers, last-value key, ring size, whether it is non-destructive — that is, whether consumers read without removing — and whether it is configuration-managed, so that a configuration reload puts it back as the file says.

Throughput — messages routed here, acknowledged, expired, dead-lettered, the bytes held on disk, and how many of what it holds are durable, where that differs from the message count above.

When delivery fails — the dead-letter address, the expiry address, and who declared the queue.

Values that are only meaningful as words are shown as words: -1 max consumers and -1 ring size read Unlimited, -1 group buckets reads off, a negative dispatch delay reads none and a positive one is said as a duration. Anything the broker did not report is a dash.

The Overview tab of orders.equity.processing, ANYCAST under orders.equity, durable: five counts above — 520K messages, 0 consumers, 0 delivering, 0 scheduled and an oldest message of 36 min — then four cards: Delivery, delivering with no filter, Unlimited max consumers, message groups off and a dispatch delay of none; Retention, durable, with an Unlimited ring size; Throughput, 520K routed here, 0 acknowledged, expired and dead-lettered, and 436 MB held on disk; and When delivery fails, with DLQ as the dead-letter address and ExpiryQueue as the expiry address. — Values that only mean something as words are shown as words — an unlimited consumer count, an unlimited ring size, a dispatch delay of none.

Values that only mean something as words are shown as words — an unlimited consumer count, an unlimited ring size, a dispatch delay of none.

Counters: a chart of what the broker recorded, not of what the page watched

Artemis samples every queue on its own period and keeps a day-by-day record of what arrived. Of the platforms in this console it is the only one that does this, and Counters draws that record as the broker kept it. The Metrics tab beside it is BROKA's own metric history of the queue — its messages, consumers and messages in delivery by default, and any figure an alert rule watches — from the readings BROKA takes once a minute, whichever tab is open.

The chart shows messages added per hour across the broker's whole retained history. Above it, when counters are on: total added, added in the last sample, depth at the last sample, and the change in depth.

Underneath, what the broker says about its own sampling: whether counters are on and on what period (On, every 10 s), when it last sampled, when a message was last added and last acknowledged — written in the console's own date format and time zone, not the broker's — and how many days of history it retains. So "the last sample" is a length of time rather than an unknown.

Two of those figures are easy to misread, and the ? beside the chart's title says so:

Added is cumulative since the counter started, not since the broker did — it goes back to zero when somebody resets the counters.
Depth at last sample is what the queue held when the broker last looked, which is not the live depth on the Overview tab.

The Counters tab of orders.equity.new, ANYCAST under orders.equity, durable: four tiles — 49K added, the messages added in the last sample, 48K deep at the last sample and the change in depth since the sample before; a Messages added per hour bar chart with its ?, one bar of about 49K at 14:00; and the What the broker says card — sampling On, every 10 s, last sampled, last message added and last message acknowledged all at 20 Oct 2026, 14:14:26, and 1 day retained. — **What the broker says** names the sampling period itself — On, every 10 s — along with when it last sampled and how many days of history it keeps.

**What the broker says** names the sampling period itself — On, every 10 s — along with when it last sampled and how many days of history it keeps.

The Metrics tab of orders.equity.processing, beside Counters, on 1h: Queue message count climbing from about 170K to about 520K a few minutes after 11:15 and then, after a short gap, level there to the end of the hour; Queue consumers at 0 throughout; and Delivering at 0 throughout. — Counters is the broker's own record; Metrics is what BROKA read once a minute — the same queue, kept by two different hands.

Counters is the broker's own record; Metrics is what BROKA read once a minute — the same queue, kept by two different hands.

An unmeasured hour and a measured zero are drawn differently. Artemis writes -1 for an hour it has no figure for — every hour before sampling began, and every hour that has not happened yet — and 0 for a measured hour in which nothing arrived. An unmeasured hour draws nothing. A measured zero draws a two-pixel mark: enough to see that it was measured, too little to read as a quantity.

Unmeasured hours at each end of the history are trimmed, so a broker whose counters were switched on this morning does not draw one hour of data in the last fraction of a ten-day axis. Nothing measured is ever dropped, including a measured zero.

When counters are switched off, nothing is drawn

With sampling disabled the broker still answers — reporting 0 added and 0 deep for a queue holding sixty messages. Those zeros are indistinguishable from real ones.

So the tab does not read them and guess. It asks the broker whether counters are enabled, and if they are not the tab is one empty state — Message counters are off on this broker — with Turn counters on, which opens Broker ▸ Maintenance, where they are switched on for the whole broker. No chart and no figures are drawn while they are off. Sampling starts from the moment they are turned on; it does not fill in the time they were off.