What does queue depth with no consumer mean?

Messages are present but no active consumer is currently attached or making progress. The cause can be application state, connection or channel failure, listener configuration, authentication, selector mismatch, repeated rollback, or another dependency.

Should I restart the T24 consumer immediately?

First capture queue and application evidence and assess whether previous deliveries had an uncertain outcome. Restart only through the approved procedure after redelivery and duplicate risk are understood.

Messaging production support

T24 Messaging Queue Has Messages But No Consumer

Queue depth proves messages are present. It does not prove the expected T24 consumer is configured, connected, healthy, authorised, or safe to restart.

By T24Guru Editorial·Published 8 July 2026

Integration Production support

Browse more Integration articles →

Separate queue state from consumer state

Queue state: current depth, enqueue rate, dequeue rate, delivering count, and oldest-message age.
Consumer state: consumer count, connection, channel, listener, thread, acknowledgement, and transaction progress.

A queue can have messages and a non-zero consumer count while processing is still stalled. Conversely, zero consumers may be expected during a controlled hold. Build a timestamped picture before changing anything.

Ordered diagnostic sequence

Confirm the queue manager or broker and exact queue or address being observed.
Capture queue depth, input/output rates, delivering count, oldest age, and trend.
Confirm whether the expected consumer connection and channel or listener exist.
Check the application service, deployment, thread, authentication, and dependency state.
Look for rollback, redelivery, selector, transaction, and dead-letter evidence.
Assess ownership and duplicate risk before recovery or replay.

Common failure patterns

No consumer connection

Check whether the application service started, the listener was deployed, connection settings resolve correctly, and credentials or certificates are valid.

Connection exists but no progress

Check delivering counts, uncommitted transactions, downstream waits, thread pools, database locks, and repeated rollback. A connected consumer is not necessarily healthy.

Messages routed elsewhere

Review selectors, subscriptions, routing keys, expiry addresses, dead-letter queues, backout handling, and environment-specific queue mappings.

Evidence before restart

Queue and consumer snapshots at multiple timestamps
Connection, channel, listener, and application-service state
First relevant broker and application error
Recent deployment, certificate, credential, routing, or network changes
Message age, retry or backout count, and any delivery in progress
Whether the last attempted business operation committed or remains uncertain

Do not clear the queue, move messages, reset backout counts, or replay work as a first response. Use the local runbook and preserve original identifiers for reconciliation.

Recovery and closeout

When the cause is understood, recover the service through the approved procedure and observe consumer count, dequeue rate, acknowledgements, application results, and downstream confirmations. Confirm that backlog reduction does not create duplicates or overwhelm a dependent system.

For wider message-flow concepts, read how T24 talks to other systems. For escalation evidence, use the incident checklist.