Skip to content

Subscription Health Dashboard

Delivery-health monitor — instantiates Topic-Brokered Event Distribution

Surfaces per-subscription delivery health — lag, error rate, retries, relevance — so operators can see which subscribers are keeping up and which are silently falling behind.

A Subscription Health Dashboard turns the broker's per-delivery records into a legible picture of how each subscription is faring. Brokered distribution hides its consumers by design — the whole point is that a producer never sees them — which means a subscriber that is quietly falling behind, erroring, or drowning in events it does not want can go unnoticed until its downstream behavior visibly diverges. Its defining move is to reverse that opacity for the operator: it reads the delivery traces and acknowledgements the system already emits and renders, per subscription, whether events are arriving, being processed, and actually mattering. It observes and reports; it takes no action itself.

Example

An e-commerce platform's order.placed topic feeds a warehouse-fulfillment subscription. A routine deploy ships a subtle bug in the fulfillment consumer, and its acknowledgements begin failing — but nothing crashes, and orders keep flowing in. On the dashboard the on-call engineer sees the subscription's lag climbing and its ack rate dropping within minutes of the deploy, correlates the inflection to the release time, and rolls back before the fulfillment backlog grows large enough for customers to notice missing shipments. In the same view, a "relevance" panel flags a different subscription that discards ninety-plus percent of what it receives — a hint that its filter is too broad and its owners are paying to transport events they immediately throw away.

How it works

  • Per-subscription roll-up — delivery traces and acks are aggregated into lag (distance behind the live edge), throughput, error rate, retry count, and dead-letter volume, one row per subscription.
  • Relevance signal — it compares events delivered to events actually acted on, exposing subscribers whose filters are so loose they transport mostly noise.
  • Thresholded alerting — per-subscription targets (a lag budget, a minimum ack rate) fire alerts to the subscription's owner, not a general channel.
  • Read-only by design — it makes divergence visible and hands the response to other mechanisms; it never throttles or reroutes on its own.

Tuning parameters

  • Metric granularity — per subscription, per consumer instance, or per topic; finer granularity localizes faults but multiplies what must be stored and watched.
  • Lag alert threshold — how far behind before an alarm; tight thresholds catch trouble early but risk alert fatigue on bursty topics.
  • Trace retention — how long per-delivery history is kept for forensics, trading investigative depth against storage.
  • Relevance sampling rate — whether relevance is computed on every event or a sample; full coverage is precise but costly at high throughput.
  • Alert routing — to the subscribing team versus a central desk, which determines whether the people who can fix a lagging consumer actually hear about it.

When it helps, and when it misleads

Its strength is making the invisible visible: a silently starving subscriber, a filter that transports garbage, a consumer that regressed on the last deploy — all become observable before they become incidents. Its failure mode is measuring delivery while a subscriber silently fails at processing: a dashboard can glow green because events were handed over, even as the consumer drops them on the floor after receipt[1]. The classic misuse is watching it backwards — reading aggregate health to reassure a stakeholder that "the bus is fine" while a single business-critical subscription starves inside a healthy-looking average. The discipline is to alert on per-subscription objectives rather than fleet aggregates, and to trace processed, not merely delivered, so the green actually means what a reader assumes it means.

How it implements the components

  • delivery_trace_record — it collects, retains, and renders the per-delivery records (attempts, acknowledgements, retries, failures) that constitute a subscription's audit trail.
  • subscriber_relevance_feedback_loop — it closes the loop from what a subscriber received to what it used, surfacing mismatches that tell owners to tighten a filter or split a topic.

It reports but does not act: containing a lagging consumer is Slow Consumer Isolation, parking messages that keep failing is Dead-Letter Queue, and the per-delivery acknowledgements it aggregates are produced upstream by Delivery Acknowledgement, not by the dashboard.

References

[1] Consumer lag — the gap between the latest event published and the latest one a subscriber has processed — is the single most diagnostic health signal for a subscription, but only when measured at processing, not at hand-off. Lag that counts delivered-but-unprocessed events as "done" is the exact blind spot this footnote warns against. ↩