An operations dashboard should show work, not vanity

What the public implementation shows

The dashboard operations endpoint reports subscription and delivery counts, outbox states, accepted, rejected and reversed payments, rejection reasons, and recent bill totals.

The view aggregates durable gateway state rather than reconstructing truth from log messages. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleAn operational dashboard earns its place by pointing to queues and decisions someone owns.

The decision behind the mechanism

The selected measures pair business outcomes with recovery workload so operators can see both transaction health and notification debt.

A dashboard limited to payment volume can look successful while rejected transactions and dead-letter callbacks grow. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Build counts from authoritative persisted states.
• Show accepted and exception outcomes together.
• Expose top rejection reasons with drill-through.
• Keep time windows and freshness visible.

How the control should be operated

Every card should link to a filtered operational list, define its time window, and state which team acts when the value is abnormal.

The dashboard becomes a work surface rather than an executive decoration. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.