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.