Transactions stuck in `status='Pending'` past their rail's configured `max_pending_age` cap. Each Rail in the L2 instance with an aging watch contributes its own threshold; the underlying view inlines these caps at schema-emit time. KPI shows total stuck count; the aging bar chart breaks the population into 5 buckets (0–6h, 6–24h, 1–3d, 3–7d, >7d) so operators can see whether they're fighting one big spike or a slow drift. Right-click any row → View Transactions to see every leg of that transfer.
Stuck Pending
Count of Pending transactions whose live age has exceeded their rail's `max_pending_age` cap. Healthy = 0.
Stuck Pending by Age Bucket
Distribution of stuck-Pending transactions across 5 age bands, stacked by rail. Right-skewed (>3d, >7d) ⇒ slow drift; spike at 0-6h ⇒ a recent batch failed to post. Color bands surface per-variant rollup for XOR-grouped multi-mode templates.
Stuck Pending Detail
Every stuck-Pending leg with rail / amount / posting / live age. `max_pending_age_seconds` is the rail's cap (inlined at view-emit time from L2). Right-click any row → View Transactions to see every leg of that transfer.
**Per-rail pending aging**
> For every Rail with `max_pending_age` set, every Transaction on that rail SHOULD transition `Pending → Posted` before `posting + max_pending_age`.
Transactions stuck in `status='Pending'` past their rail's configured cap. Caps come from the per-Rail `max_pending_age` field and are inlined as CASE branches keyed on `rail_name`. Rails without an aging watch contribute no branch and are excluded.
**Action.** Either re-poke the source-system integration to transition the transaction, or raise the rail's `max_pending_age` if the cap is too aggressive for normal volume. Escalate to ops when `age_seconds` is in days rather than hours.