Queue and revenue totals

How many applications sit in each status. A record rather than a list, and sparse: a status nobody is in is absent rather than zero. Read a missing key as zero.

Latest unpaid payment attempts at least 30 minutes old; used for the checkout recovery work badge.

Paid applications we have not finished reviewing, oldest hold first, capped at eight. The counts elsewhere say how much is held and how many applications that is. This says **who** — money held on our clock, a customer waiting, and the only queue here with nobody else in it. `under_review` is included because an application somebody opened and did not finish is more stuck than one nobody has touched.

The two queues behind the scenes, each with a depth **and an age**. Depth alone cannot answer "is the worker alive": a queue reads `queued: 1` whether the sweep is mid-run or the process has not started for a week, and those want opposite responses. The age is the half that tells them apart.

Reported rather than hardcoded in the dashboard, so the banner cannot lie.

Messages we owe that did not land. `failed` retries itself; `abandoned` and `skipped` never will, which is why they are counted apart rather than summed.

The five authorisations held longest, oldest first. A total says how much is exposed; this says what to act on next, which is why it carries the reference.

How many authorisations are inside the monitor’s warning window. Counted here rather than derived by the dashboard, so it cannot disagree with the alerts.