> ## 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 Reliability page > Open Settings → Reliability and read the per-channel uptime, incident windows, and delivery success table — how availability differs from delivery success, how to drill into incident windows, and when the page routes you into the delivery log, on-call alerting, or the route-quality circuit breaker runbook. # 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](/guides/monthly-sla-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: | Column | Reading it | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Channel** | The channel name. The report always lists the core channels (SMS, voice, WhatsApp, RCS, email) plus any other channel with traffic or a declared incident in the period. | | **Availability** | A colour-banded percentage, or **Not measured**. Green ≥ 99.9%, neutral ≥ 99%, amber below 95%, red below that. `Not measured` means the channel had no delivery traffic **and** no declared incident all month — there is no evidence to attest it was up, so the page does not render it as 100%. | | **Downtime (min)** | Minutes of the month a declared incident covered the channel. Overlapping incidents count once. | | **Incidents** | Declared incidents attributed to the channel; the drill-down is the Incident windows list below the table. | | **Delivered / Terminal** | Your outbound messages that reached a final state (delivered, failed, undelivered, rejected), and how many of those were delivered. In-flight messages are excluded from the denominator. | | **Success rate** | Delivered ÷ terminal, or a dash when there is no terminal traffic. Below 90% on at least 10 terminal messages, the figure prints in red with a warning icon. | | **Delivery health** | the API's tier for the channel: **Healthy** (≥ 90%), **Degraded** (\< 90%), or **Critical** (\< 50%). A dash means insufficient volume (\< 10 terminal messages) or no traffic — the page deliberately refuses to grade a handful of sends. | 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](/guides/monthly-sla-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](/guides/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](/guides/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](/guides/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](/guides/oncall-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](/guides/monthly-sla-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](/guides/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 * [Monthly SLA and availability report](/guides/monthly-sla-availability-report) — the full deep-dive: derivation formulas, boundary conditions, the credit endpoint, and the claim playbook * [Delivery log](/guides/delivery-log) — the failure-classification drill-down for low delivery-success figures * [Status page](/guides/status-page) — the public incident feed the availability column aggregates * [On-call alerting](/guides/oncall-alerting) — page a rotation when the degradation chain looks systemic * [Route quality circuit breaker runbook](/guides/route-quality-circuit-breaker-runbook) — traffic-shaping response while a route-level delivery degradation is live * [Scheduled reports](/guides/scheduled-reports) — receive the SLA digest on cadence instead of pulling it from this page