Skip to main content

​
Read the consolidated deliverability dashboard

Insights → Deliverability is the one screen that answers “is outbound traffic landing?” across every channel you send on. It opens with a cross-channel reputation health card, then one tab per channel with the same KPI row, volume chart, and failure breakdowns — so a degradation has exactly one place to show up first, and every tab reads the same way once you learn one. The concept pages define the vocabulary — Delivery lifecycle for the canonical states, The DLR model: two planes for how receipts cross back. The per-channel guides cover single surfaces in depth. This page is the consolidated overview: what it aggregates, and how to leave it with a remediation in hand. Everything the page renders is read-only and scoped to your workspace. The API behind it enforces the read role (owner/admin/developer/viewer) server-side, so no seat can see another tenant’s numbers.

​
1. What the overview aggregates

The page has two layers with deliberately different scopes. The Reputation Health Center (top of the page, above the tabs) is cross-channel: one composite 0–100 score across five channels — SMS route quality, email domain/IP authentication, WhatsApp quality rating, RCS sender status, and voice call quality — with a per-channel bar grid and a ranked “Root causes to fix” list. It uses a fixed 7-day reporting window regardless of the window control. Read it as the triage view: one glance tells you which channel is the problem before you open a single tab. The channel tabs (SMS, WhatsApp, RCS, Email, Voice, Instagram, Messenger, Viber) are per-channel: each tab aggregates that channel’s outbound traffic for your selected window — totals for messages sent, accepted, delivered, read, failed, bounced, complained, and unsubscribed, plus delivery/read/failure rates, a timed volume chart, and failure diagnostic charts. Tabs mount on demand, so only the tab you’re viewing queries the API. Three cards are account-wide rather than per-tab, and their numbers intentionally won’t match the tab KPIs:
  • Account messaging health (anchored to the SMS tab, badged “All channels”) — one benchmarked 0–100 score over delivery, compliance, fraud, latency, and engagement across every messaging channel. Because it rolls up all channels, its delivery rate won’t match the SMS tab’s Delivery Rate card; the “All channels” badge is the signpost that these are different scopes, not a data conflict.
  • The delivery-truth breakdowns (SMS and Voice tabs, with a By MNO / By route / By queue switch) — per destination operator (silent-drop inference: an operator that claims delivered but handsets stay quiet), per carrier connector path, and per queue stage. This is where “the rate dropped” turns into “this route, to this operator, is where it dropped.”
  • Messaging Insights (SMS, WhatsApp, RCS, Viber tabs) — per-carrier, per-country, and per-error-code histograms for separating carrier filtering from content issues. Owner/admin seats only; other seats never fetch it.
Meta DM channels (Instagram, Messenger) display a banner because Meta’s Send API emits no wire-level delivery receipts — those tabs aggregate acceptance and engagement, not carrier-verified delivery, so their delivery rate reads differently than SMS.

​
2. The time-window control

The segmented control at the top-right offers 24h, 7d (the default), and 30d. It applies to whichever tab is active — KPI cards, the volume chart, and every breakdown re-aggregate for that window. The slices answer different questions:
  • 24h — incident view. Use it when you just changed something (a new route, a template edit, a list import) or when an alert fired. Buckets are hourly, so a same-day quality drop shows up as its own bar instead of being averaged into a week.
  • 7d — the operational default. Long enough for one full weekly volume cycle, short enough that a degradation starting two days ago still moves the headline rate.
  • 30d — trend view. Use it for month-over-month comparisons, for slow reputation decay on email domains, and for checking whether a fix you shipped actually held.
The KPI cards carry a “vs previous” trend badge computed by splitting the window in half — on 24h that compares the last 12 hours against the previous 12, on 30d the last 15 days against the first 15. Two scope exceptions: the Reputation Health Center always reports a 7-day window, and the per-bucket figures and charts are computed in your workspace’s billing timezone, so daily labels don’t shift with the viewer’s clock.

​
3. Reading the metrics

Every tab renders the same KPI row. The denominators are the difference between reading the numbers and misreading them: Because Delivery Rate divides by terminal and not sent, rows awaiting a receipt don’t depress it — an SMS-heavy window full of in-flight sends won’t look broken. The trade: a channel with a large Pending count and a good Delivery Rate is telling you “the verdicts haven’t arrived yet,” not “everything is fine.” The anomaly card above the KPI row is computed per tab: it compares the most recent 40% of buckets against a baseline built from the first 60%, at 2σ (warning) and 3σ (critical). It links straight into the logs viewer filtered to that channel — the first drill-down hop. Below the KPIs, three charts split the diagnosis: Volume & Outcomes (sent/delivered/read/failed over time — distinguishes “nothing sent” from “sent and failed”), Failure Reasons (top provider-reported error codes — the “why”), and Top Failing Countries (SMS and Voice — the “where”).

​
4. Drill-down mapping

The overview is the triage layer; each signal hands off to a deeper surface:
  • A single campaign dragging the rate → the campaign’s own Deliverability Lab report — predicted per-carrier delivery and content filtering-risk lint, which you can also re-run pre-flight from the campaign composer before the next launch.
  • A specific message or error code → DLR outcomes monitoring to classify the no-receipt WARN (designed-benign vs actionable), then the Delivery Log for individual message rows.
  • Contacts churning on a channel → Contact deliverability health for per-contact suppression and engagement state.
  • A degraded SMS or Voice route → the By MNO / By route tabs inside the panel, then Test a route — the probe card sends a live one-off down a specific country/carrier route and reads back the delivery receipt, whether your sender ID survived rewriting, and whether the body arrived intact. The anomaly card links into the logs viewer for the same channel.
  • Email bounce/complaint climb → Email DNS drift, because domain-authentication drift is the most common root cause, then email bounces & complaints.
  • WhatsApp quality-rating drop (visible in the Health Center channel grid) → fix the template quality before the rating gates throughput; the outbound templates guide covers template health.
  • A terminal-status mystery (“the chart says failed but which state is that?”) → Message undelivered/failed for the state-by-state split.
You can also export the visible tab as a formatted workbook from the Export button in the header — it downloads the exact numbers on screen, so attach it when escalating a route issue to your account team.

​
5. Acting on a degraded channel

Each channel’s remediation is tenant-owned: you fix list quality, content, DNS, templates, or which route you prefer — the platform surfaces the signal and the probe tools. Worked example — degraded SMS. Your workspace sends SMS traffic, and the dashboard sequence goes:
  1. Triage from the Health Center. The composite score drops and the SMS bar goes red with “Root causes to fix” naming SMS route quality. That tells you the problem is route-level, not engagement-level.
  2. Confirm on the SMS tab. Switch the window to 24h: the Delivery Rate card is down vs previous, the anomaly card fires, and the Failure Reasons chart concentrates on one provider error code.
  3. Localize. Open the By route breakdown — one connector path holds most of the failures while your other routes stay healthy; the By MNO view shows the failures concentrate in one destination operator, with silent_drop_suspected flagged (the operator claims delivered but inbound replies stopped).
  4. Probe. Click Test a route on the degraded route — the live test comes back delivered, but with your sender ID rewritten. That’s the answer: the route delivers, but the rewritten sender ID breaks recognition and replies, which is why handsets went quiet.
  5. Fix (your side). Move the affected traffic to the healthy route in your messaging settings, and re-run the Deliverability Lab pre-flight on the next campaign to confirm predicted delivery for that operator recovers.
  6. Verify. Re-check the SMS tab on 24h the next day — Pending drains, Failure Rate returns to baseline, and the anomaly card clears. Set the DLR outcomes monitoring WARN counters on the sms_no_receipt lane to page if it recurs.
The same five moves — triage, confirm, localize, probe, fix-and-verify — apply per channel: email sends you to Email DNS drift and list hygiene; WhatsApp sends you to template quality and the Meta quality rating; voice sends you to the per-country and per-route charts plus caller ID coverage when unanswered calls concentrate in specific destinations.

​
Compliance

All of this page documents tenant-owned controls: which window you read, which remediation you take, which routes you prefer, and what you do with an export. The dashboard itself is read-only — it sends nothing, and outbound termination stays within the Devotel softswitch contract described in DLR and MO gateway pipeline. Webhook events you subscribe to (message.delivered, message.failed, message.read) fire from the same terminal transitions the dashboard aggregates.