Queues & workers
Overview
Much of what you trigger in the system does not happen in the same instant: sending mail, building PDFs, delivering webhooks, updating the search index. Work like that goes into a queue and is processed by a worker in the background. That is why saving a document returns immediately instead of hanging for twenty seconds.
This page shows how that machinery is doing right now. It is a read-only view — there is nothing here to click that intervenes in the processing.
The one question it answers: is background work keeping up, or is something piling up?
Core tasks
Read the overall state. Three figures sit at the top: overall state, waiting messages and permanently failed. Healthy means nothing has permanently failed and no backlog exceeds the threshold. Needs attention means at least one of the two applies.
Check the individual queues. The table lists every configured queue with its technical name and the number of waiting messages:
| Queue | What sits in it |
|---|---|
| Background work | general processing — mail, documents, index maintenance |
| Outbound webhooks | notifications to connected third-party systems |
| Outbox | messages that must go out reliably exactly once |
| Failed | whatever did not get through even after all retries |
Read the per-row assessment.
| Assessment | Meaning |
|---|---|
| Keeping up | The backlog is below the threshold. Normal, even with a number above zero. |
| Backlog | More waiting messages than the threshold allows — the worker is falling behind. |
| Failed | The failure queue holds messages. Every one of them is lost work until it is dealt with. |
| Empty | Nothing pending. |
| Not countable | This queue cannot technically report its size. Not an error — just no answer. |
Watch the timestamp. The bottom line states when the snapshot was taken; the page refreshes itself every 30 seconds. Refresh fetches immediately.
Fields in detail
This page has no input mask — it shows background processing. Actions exist only on individual jobs.
| Element | From | What it means |
|---|---|---|
| Queue | processing queues | What kind of work is pending — mail dispatch, documents, import, reporting. |
| Waiting | number of open jobs | How much is left to do. A permanently growing number means processing is not running or cannot keep up. |
| In progress | running jobs | What is being processed right now. |
| Failed | jobs after the last attempt | What did not get through. This number is the most important on the page: a failed job means something did not happen — a mail not sent, a document not produced. |
| Error message | the last attempt | Why it failed. |
| Attempts | counter | How often it was tried. The system retries with growing intervals before giving up. |
| Retry | button | Puts the job back in the queue. Sensible once the cause is fixed — before that it fails again. |
| Discard | button | Removes the job for good. What it was meant to do then does not happen — so look first at what is lost. |
Settings & permissions
- Permission
platform.ops.monitor. Without it neither the menu entry nor the page appears. It
is deliberately separate from the settings permissions: seeing operational figures should be possible for people who may not configure anything.
- Read-only. The page changes nothing — no retry, no delete, no pause. Intervening in the
processing runs through the server command line and belongs in the hands of whoever operates the system.
- The threshold comes from the server. What counts as a backlog is decided by the system, not by
the interface. The value in force is shown as a hint on the Waiting messages figure.
- Not brand-scoped. Queues are infrastructure of the whole system; switching brands does not
change this page.
FAQ & troubleshooting
Every figure says "Not countable". Then the queues are configured in a way that cannot report their size — normal for in-memory transports. The page says so deliberately rather than showing an invented zero.
**The number under Background work keeps growing and never falls.** That is the typical picture of a stopped worker. The messages are not lost, they are waiting — but nothing happens until the worker runs again. Talk to whoever operates the system.
**There is a number greater than zero under Failed.** The system has permanently given up on those messages. They do not disappear on their own and they do not retry on their own. Until someone looks at them, the work behind them is missing — an undelivered mail, for instance.
**The page says Needs attention, but every row looks unremarkable.** Look at the failure queue: a single message there is enough for Needs attention, no matter how quiet the other queues are.
I cannot find the menu entry. Then you lack platform.ops.monitor. The entry sits in the Platform area, below the Audit log.