> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Read the consolidated deliverability dashboard > How to read Insights > Deliverability as a single roll-up of every outbound channel — what the eight channel tabs aggregate, what the 24h/7d/30d window changes, how to spot a degraded channel from the KPI row, and where to drill from the overview into campaign-level and message-level remediation. # 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](#the-reputation-health-center), 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](/concepts/delivery-lifecycle) for the canonical states, [The DLR model: two planes](/concepts/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: | KPI | Definition | Good | Degraded | | ----------------- | ----------------------------------------------------------------------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Delivery Rate** | delivered ÷ terminal (messages that reached a final state) — *not* ÷ sent | Channel-typical baseline for your traffic | A sustained drop across buckets — the page fires an anomaly card when the per-bucket rate falls \~2σ below its own baseline | | **Read Rate** | read ÷ delivered | Engagement-typical for the channel | Falling read with stable delivery signals content fatigue, not a carrier problem | | **Failure Rate** | failed ÷ terminal | Near zero | Rising — and the Failure Reasons chart names which provider error codes drive it | | **Pending** | accepted but still awaiting a final outcome — a snapshot count, not a running total | Near zero once traffic has resolved | Climbing means receipts are late or absent — see [DLR outcomes monitoring](/guides/dlr-outcomes-monitoring) | | **Bounced** | bounce counter (email-weighted) | Low and flat | A spike on email means list hygiene or domain authentication — see [email bounces & complaints](/troubleshooting/email-bounces-complaints) | | **Complaints** | spam-complaint counter | Near zero | Any sustained non-zero is a sender-reputation threat — act before carriers throttle you | 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](/guides/insights-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](/guides/campaign-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](/guides/dlr-outcomes-monitoring) to classify the no-receipt WARN (designed-benign vs actionable), then the [Delivery Log](/guides/delivery-log) for individual message rows. * **Contacts churning on a channel** → [Contact deliverability health](/guides/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](/guides/insights-logs-viewer) for the same channel. * **Email bounce/complaint climb** → [Email DNS drift](/troubleshooting/email-dns-drift), because domain-authentication drift is the most common root cause, then [email bounces & complaints](/troubleshooting/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](/guides/outbound-templates) covers template health. * **A terminal-status mystery** ("the chart says failed but which state is that?") → [Message undelivered/failed](/troubleshooting/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](/guides/campaign-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](/guides/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](/troubleshooting/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](/guides/caller-id-coverage-validation) 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](/concepts/dlr-and-mo-pipeline). Webhook events you subscribe to (`message.delivered`, `message.failed`, `message.read`) fire from the same terminal transitions the dashboard aggregates. ## Related * [Delivery lifecycle](/concepts/delivery-lifecycle) — the canonical states behind every rate on this page. * [The DLR model: two planes](/concepts/dlr-model-two-planes) — why some channels' receipts arrive differently than others. * [DLR outcomes monitoring](/guides/dlr-outcomes-monitoring) — classify the no-receipt WARN stream the Pending card summarizes. * [Delivery Log](/guides/delivery-log) — message-level drill-down behind any aggregate here. * [Campaign deliverability lab](/guides/campaign-deliverability-lab) — pre-flight carrier filtering-risk and per-carrier delivery prediction. * [Contact deliverability health](/guides/contact-deliverability-health) — per-contact suppression and engagement state. * [Email DNS drift](/troubleshooting/email-dns-drift) — the first remediation when email bounces climb. * [Message undelivered/failed](/troubleshooting/message-undelivered-failed) — the terminal-state split when a rate drops.