> ## 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.

# Settings Status: read incident timelines and SLA attestation

> Use Settings → Status to see incidents mapped to your organization's channels, understand severity rollups, and confirm what the SLA attestation shows before investigating a degraded channel.

# Settings Status: read incident timelines and SLA attestation

Open **Settings → Status** (`/settings/status`) when you need to answer a
short-term operational question for your organization: **is a declared platform
incident affecting one of our channels, and what does the incident timeline say
right now?** The page is an organization-scoped read of the declared incident
feed. It is separate from the monthly uptime rollup in
[Settings → Reliability](/guides/settings-reliability-reading).

Owners and admins can read the organization-scoped detail. Viewers can open the
Status surface in read-only mode; the page never lets a tenant declare, edit, or
acknowledge a platform incident.

## 1. What the Status surface publishes

The Status surface publishes three related views:

* **Per-channel availability.** Each channel your organization uses is mapped
  against declared platform incidents. A channel with no traffic and no declared
  incident is not presented as verified uptime; it is not measured.
* **Incident timeline.** Active and recently resolved incidents show their
  severity, affected component, current state, and timestamped updates. Read the
  timeline to distinguish an incident that is still being investigated from one
  that is being monitored or resolved.
* **The verify pipeline.** The page verifies the published incident record, maps
  its declared component to your organization's channel set, and then derives
  the organization view from that result. This keeps an unrelated component out
  of your history while retaining platform-wide incidents. It is a read-time
  projection of the published feed, not a tenant-local health probe.

The page's incident states follow the published progression: **Investigating**,
**Identified**, **Monitoring**, and **Resolved**. A maintenance notice or
informational notice can appear in the feed, but scheduled maintenance and
informational notices do not count as downtime in availability calculations.

## 2. Map a marked incident to your tenant's view

Start with the incident's affected component and severity, then check whether
that component maps to a channel your organization uses:

1. Open **Active now** and select the incident that overlaps the time your
   channel changed.
2. Compare the affected component with the channel list shown for your
   organization. A video-only incident, for example, does not appear in the
   organization history for a tenant that uses only SMS and email.
3. Read the incident updates and the impact badge together. The timeline tells
   you what the platform has confirmed; the badge tells you the incident's
   severity class.

Severity rolls up worst-first. A channel touched by a critical incident is
reported as critical even if another overlapping record is minor. Major and
minor incidents likewise roll up above normal operation, while informational
notices do not reduce availability. Overlapping windows count once in the
availability calculation, so the same minutes are not deducted twice.

A platform-wide incident maps to every channel. A component-scoped incident
maps only to the channels represented by that component. If an incident does
not map to any channel in your organization, it does not explain a tenant-level
change and will not appear in the org-scoped history.

## 3. Status or Reliability?

Use the surface that matches the question:

| Question | Surface |
| - | - |
| Is a declared incident affecting us now? | **Status** (`/settings/status`) |
| What did the incident timeline report, and when? | **Status** |
| What was this month's per-channel uptime? | **Reliability** (`/settings/reliability`) |
| How many minutes did each incident contribute, and what is the credit assessment? | **Reliability** |
| Why are messages failing when no platform incident is declared? | Your delivery log and channel configuration |

Reliability is the monthly uptime rollup. It combines declared incident
windows with your organization's outbound message outcomes, exposes the
per-channel availability and delivery-health rows, and can export the completed
period as CSV. Read [Settings Reliability: the monthly uptime
rollup](/guides/settings-reliability-reading) for the drill-down and response
steps.

## 4. SLA attestation: does it exist, and what does it show?

Yes. The SLA attestation is the organization-level monthly statement behind
the same availability derivation. It is available to authenticated members
through `GET /api/v1/reports/sla-attestation`; choose a calendar month with the
`month=YYYY-MM` parameter, or omit it to use the most recent complete month.

The attestation shows:

* the attested month and its exact UTC window;
* overall platform uptime and de-duplicated downtime minutes;
* delivery rate for each channel, using terminal outbound messages as the
  denominator; and
* the `support_sla` block, which reports first-response and resolution SLA
  attainment for digital conversations.

A `null` channel delivery rate means there was no terminal traffic, not zero
percent delivery. Likewise, a month with no measured channel is not silently
turned into 100% uptime. The attestation and Reliability report use the same
read model, so a month selected in either surface should produce the same
availability and delivery figures. For formulas, CSV export, and claim
handling, see [Monthly SLA and availability report](/guides/monthly-sla-availability-report)
and [the SLA attestation model](/concepts/sla-attestation-model).

## 5. If a channel is degraded, check Status first

When a channel suddenly behaves differently, first open **Settings → Status**
and look for an active incident that maps to that channel. Read the newest
update and its affected-component scope before changing routing or retrying
traffic. A declared incident gives you a platform explanation and a timeline
for the next update.

If Status has no matching incident, do not treat the absence as proof that the
channel is healthy. Check **Reliability** for the channel's delivery-health
row, then open the delivery log and inspect recipient, sender, provider, and
wallet failures. Delivery success is your traffic's outcome; it can degrade
while platform availability remains 100% because of invalid recipients,
unregistered senders, filtered content, carrier rejection, or insufficient
balance.

## See also

* [Settings Reliability: the monthly uptime rollup](/guides/settings-reliability-reading)
* [Monthly SLA and availability report](/guides/monthly-sla-availability-report)
* [Platform status: incident history and your shareable status page](/guides/status-page)
* [The org-scoped status model](/concepts/org-scoped-status-model)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.