Skip to main content

​
Read the Reliability page

Settings → Reliability is the monthly SLA and availability console in the dashboard: one page-per-month view of per-channel uptime, the declared incident windows that cost any of it, and your delivery success rates. This guide walks the page tile by tile and turns it into an operator runbook — what to check, where a divergence comes from, and the escalation paths to follow when something looks systemic. Owner and admin roles only — the page reads the same org-level SLA report the Monthly SLA and availability report guide pulls from the API, so it inherits that report’s role gate.

​
1. Open the page

In the dashboard, open Settings → Reliability (/settings/reliability). The header shows the period picker and a CSV export button; the page defaults to the previous complete month, so the first view is a finished attestation rather than the still-accruing current month. Pick any of the last 12 months from the picker — the current month is labelled Month to date in the list. The CSV button downloads the same report with an appended metric-definitions block, so you can attach it to an SLA claim and the reviewer can validate every figure without dashboard access.

​
2. Read the per-channel table

Below the period-provenance strip (start/end, last refresh, timezone — UTC) and any warning banners, three summary cards headline the month: Overall availability, Delivery success, and Incidents this period. The main table then has one row per channel and seven columns: Availability and delivery success measure different things. Availability is derived only from declared platform incidents (the public status feed); delivery success is the end-to-end outcome of your own outbound traffic. Expect them to diverge when your failures are recipient- or sender-side — invalid recipients, an unregistered sender, filtered content, carrier rejection, insufficient balance — and reconcile the divergence with the delivery log, not with the incident feed. The full formulas, boundary rules, and health-tier thresholds are in the Monthly SLA and availability report deep-dive. Below the table, the Service credit card composes the same availability figure against the published uptime commitment and shows SLA met or SLA breached, the credit percentage owed per the SLA schedule, and a memo-ready summary — a read of an already-computed entitlement; nothing is posted to your wallet. On the current month it is marked Provisional until the month closes.

​
3. Drill into incident windows

The Incident windows list under the table holds every declared incident that overlapped the month, with its impact badge (minor/major/critical; none for informational), the channels it affected (or all channels for a platform-wide incident), an ongoing badge if it is still open, and the minutes of it that fell inside the selected month — the pro-rated overlap, so a month-boundary incident deducts from both months only the minutes each contains. Use this list to answer why an availability figure moved: a WhatsApp row reading 99.9% while every other channel reads 100% lines up with exactly one window here, and that window is what you quote back on an SLA claim. When the list is empty while delivery health is degraded, the page says so explicitly — zero declared incidents and a delivery collapse are not a contradiction, because a delivery collapse is channel health, not a platform incident. The same incident windows are what the public status page publishes; the Reliability page is the per-month aggregation of that feed layered with your own traffic outcomes.

​
4. Operator runbook — from page read to action

Spot the degradation. Start with the two warning surfaces at the top, not the table: the critically low delivery banner fires when the overall rate falls under 90% on meaningful volume, and the channel health banner lists every channel the API tiered Degraded or Critical with its delivered rate. The health banner is keyed per channel so a collapsing low-volume channel is not masked by a healthy high-volume one. Read those two banners first, then let the summary cards and table confirm scope. Pivot into the delivery log. From the channel-health banner, the Failed messages link jumps straight to the message log filtered to failed for that channel, and Sender & provider setup opens channel configuration. For the systematic drill-down — filter by channel, status, and time window, then read the failure classification — use the Delivery log guide. A delivery drop with availability at 100% is almost always recipient- or sender-side, and the log tells you which. Respond while a degradation is live. When the reliability view shows delivery degrading right now (current month, month-to-date), the Route quality circuit breaker runbook is the traffic-shaping response — how the breaker opens, and how to fail traffic over to the next route or isolate a failing route until delivery recovers. Engage it rather than waiting for the month to close. Escalate to on-call when the chain looks systemic. If multiple channels degrade together, or a single-channel failure resists the log drill-down and routing fixes, treat it as systemic and page the rotation per On-call alerting. The channel-health banner gives you the channel, rate, and volume figures to quote in the page, and the incident-window list tells you whether there is a declared-platform incident to correlate with — or explicitly that there is not. Close an SLA claim. For a completed month the Service credit card states whether the commitment was met and exports as part of the CSV. The claim itself follows the Monthly SLA and availability report playbook — incident window plus credit entitlement plus the CSV export.

​
5. Reading the page vs receiving a scheduled report

This page is the on-demand lens: open it, pick a month, export the CSV. It is distinct from a scheduled delivery of SLA figures — the Scheduled reports guide emails a metrics digest on a daily/weekly/monthly cadence so stakeholders get the figure without an owner/admin signing in. Use the console when you are investigating (changing the period, following a banner into the delivery log); use a scheduled report when the answer is a standing monthly attestation shared with people who never open the dashboard. Both read the same report endpoint, so the figures always agree.

​
See also