Analytics, Scoped to Exactly What You’re Debugging

One Dashboard, Every Source and Destination Blended Together

The analytics dashboard has been able to answer a lot of questions for a while: success rate over a time range, p50/p95/p99 latency, error breakdowns, retry activity, payload sizes, live delivery volume over SSE, drill into any period for the raw deliveries behind it, export the whole thing as CSV or an HTML report. All of it real, all of it useful — as long as the question was about your whole organization.

The moment the question got specific — "is it just this one Stripe destination that's slow, or everything?" — the dashboard stopped being able to answer it directly. You'd stare at the org-wide latency chart, which blends every source and every destination into one line, and try to guess whether a bump was your flaky destination or unrelated noise from somewhere else in the pipeline. The only way to actually isolate it was to go read raw deliveries filtered by destination ID and do the aggregation in your head.

Analytics can now be scoped to a single source or a single destination, and it's the same dashboard — not a cut-down summary view built separately and left to drift.

What's New

• An Analytics tab on every source and every destination — click the new bar-chart icon on any row in Sources or Destinations to get that entity's dashboard
• Same component, real scoping — the scoped view is the exact same dashboard component the org-wide page renders, just given a scope; nothing was reimplemented
• Filtering pushed into the query layer — the underlying analytics queries now accept a source or destination filter and apply it at the database, not by fetching everything and slicing it client-side
• Consistent entry points — the same icon and route pattern on both the Sources and Destinations list pages, so it's discoverable the same way regardless of which side of the pipeline you're debugging

Same Component, Not a Second One

The org-wide dashboard already had a shape worth reusing: a single consolidated call backing the overview cards, timeline, latency, errors, and retries in one request, plus a handful of separate analytics queries for geography, providers, event types, and signatures. Building a scoped version the naive way would have meant a second, smaller dashboard component that starts in sync with the first and drifts the moment either one changes.

Instead, the dashboard component was pulled out and given an optional scope (source, destination, or entity name). The org-wide analytics page renders it with no scope. New per-source and per-destination analytics pages render the identical component with a scope filled in and a "Back to organization analytics" link at the top. Every query the dashboard makes — the consolidated dashboard call, drill-down detail, CSV/report export — now threads that scope straight through, and the backend analytics functions filter on it directly.

One dashboard. Whether it's scoped is just a prop.

What Doesn't Scope, and Why

Not every panel on the dashboard could be filtered the same way, and rather than fake it, the scoped view just doesn't show the panels that would lie:

• Geography, providers, event types, and signatures are hidden on destination-scoped pages. These come from data written at ingest time — before routing decides which destinations an event fans out to — so they only ever carry a source dimension. There's no destination to filter them by, so on a destination's analytics page those queries simply don't run rather than firing with a parameter the backend would silently ignore.
• Live mode is org-only. The real-time stream that powers "Live" updates has no per-entity filter, so the toggle only appears on the unscoped dashboard.
• The raw throughput chart is hidden on any scoped page. It's a known, pre-existing data-model issue: the query behind it mixes three unrelated row schemas with no row-type discriminator between them, which means it can't be safely scoped without risking numbers that don't actually add up. It stays visible org-wide, where the mixing was already the accepted tradeoff, and stays off scoped pages rather than exporting that problem somewhere new.

None of these are new bugs introduced by scoping — they're existing shape-of-the-data constraints that scoping made newly visible, and the honest fix was to hide what can't be trusted rather than show it anyway.

Try It

Open Inbound → Sources or Inbound → Destinations, and click the bar-chart icon on any row. You'll land on that entity's dashboard — same date range picker, same latency and error breakdowns, same drill-down and export — filtered to just that source or destination. From there, "Back to organization analytics" gets you back to the full picture.