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

# The org-scoped status model: one incident feed, three waypoints

> Frame your organization's status model — one public incident feed with three views over it: the org-scoped incident history in Settings → Platform status, the white-label status URL you hand to customers, and the per-channel SLA report those views reconcile against.

# The org-scoped status model: one incident feed, three waypoints

Orbit publishes **one global incident feed** — the declared incidents behind
the public status page — and derives every org-facing status surface from it.
Your organization never ingests separate incident data; the difference
between "what the platform declared" and "what actually affected my channels"
is *which view* of that feed you are reading. This page maps the model: the
three waypoints, the two endpoints behind them, and the role gates, so the
status pages stop being three disconnected features and resolve into one map.

## One feed, three waypoints

The public incident feed is the source of truth. Each declared incident names
an affected component (SMS, WhatsApp, email, voice, video, AI agents, API),
a severity, and a window. Three surfaces read that single feed:

| Waypoint                        | Who reads it                     | What it carries                                                                                                                                                                 |
| ------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Global platform feed**        | Anyone, unauthenticated          | The full public status page — overall indicator, per-component health, active incidents with update timelines, scheduled maintenance                                            |
| **Org-scoped incident history** | Owner/admin of your organization | The **Settings → Platform status** dashboard view: only the windows whose declared component maps to a channel your org actually uses, split into Active now and Recent history |
| **White-label status URL**      | Your customers                   | The *same* global page, resolved under your own host when you run an active custom domain — your brand on Orbit's feed                                                          |

Two consequences follow from a single feed. First, the org-scoped view is a
**projection**: a video-only incident never surfaces for an SMS-and-email
tenant, and a platform-wide window counts against every channel — so the
history you quote is always the subset that could plausibly explain a dip in
your own traffic. Second, nothing is re-authored per surface: the figure you
read in Settings → Platform status and the page your customer opens are
reading the same declarations, so they never disagree.

The org-scoped surface is not the SLA attestation either: the incident
history tells you *which declared windows touched your channels*; the
monthly report and attestation turn those windows into per-channel
availability figures with downtime minutes and delivery rates. Waypoint one
answers the moment question ("is anything affecting me right now?"); the
report answers the month question ("how did the channel measure up?").

## The data flow behind the waypoints

Two org-scoped endpoints carry the whole model:

* **`GET /api/v1/organization/domains`** — the branded status URL. Every
  custom domain your organization has registered and verified (see
  [custom domains and managed SSL](/concepts/custom-domains-and-ssl));
  when a domain is `active`, the public status page resolves under that
  host and the shareable link points at your brand. Until then it falls
  back to the platform host, so the link is always shareable.
* **`GET /api/v1/organizations/sla-report`** — per-channel uptime and the
  incident windows behind it. The same read that powers **Settings →
  Reliability** and anchors the [SLA attestation
  model](/concepts/sla-attestation-model); the current and previous month
  corridors surface in the **Settings → Platform status** dashboard as the
  org-scoped history.

Neither endpoint maintains its own data. Domains arrive as CNAME-verified
registration records; the SLA report derives from the public incident feed
and your own outbound message records — never from tenant-local probes.
Tenant-side delivery failures that are not declared platform events (carrier
rejections, filtered content, insufficient balance) stay out of all three
waypoints by design; the `delivery_health` tier on the SLA report is the
surface that separates those from platform windows.

## Sharing the white-label status URL

The link is the customer-facing waypoint, and it needs no credentials:

1. Open **Settings → Platform status**.
2. Click the **Copy link** action on the white-label block — the copied URL
   already carries your active custom-domain host when one exists, or the
   platform fallback when it does not.
3. Hand it out — a footer link, an in-app status entry, a direct message.
   The page it opens carries no tenant data (no org name, no per-tenant
   figures), which is what makes the link safe to share publicly.

Never splice the URL by hand from an address-bar string; the dashboard copy
action guarantees the bare path with no org-scoped parameters. The full
walk-through, embedding pattern, and the JSON/RSS companions live in the
[platform status guide](/guides/status-page).

## Role model: read-only, org-admin-gated

Both org-facing waypoints are read-only — nothing here declares, edits, or
acknowledges an incident; incident declaration is platform-side, and the
customer page is a published document.

* **Global status page** — no role at all; it is a public document.
* **Org-scoped incident history** (**Settings → Platform status**) — gated
  to the **owner/admin** roles of your organization, because the channel-to-
  component mapping reveals "what actually touched our org." Other roles get
  a `403`; the white-label URL they copy stays publicly readable regardless.
* **SLA report / attestation** — owner/admin for the detail view with
  per-incident rows; the member-readable
  [attestation](/concepts/sla-attestation-model) is the truncated summary of
  the same derivation.

The asymmetry is the point: your customers read the *global* waypoint with no
account, while only your trusted roles see which windows were *yours*.

## Relationship to the rest of the map

* [Platform status guide](/guides/status-page) — the end-user walk-through
  of the global page and the org-scoped dashboard, with the sharing and
  embedding mechanics. This concept page is the *why*; that guide is the
  *how*.
* [Monthly SLA and availability report](/guides/monthly-sla-availability-report)
  — the per-tenant availability attestation over the same feed;
  availability figures, CSV export, and the credit surface.
* [SLA attestation model](/concepts/sla-attestation-model) — the
  single-read-model rule that keeps every SLA surface on the same
  derivation; this status model is where those surfaces source their
  incident windows.
* [Custom domains and managed SSL](/concepts/custom-domains-and-ssl) —
  the registration → CNAME → managed-certificate lifecycle that decides
  whether your white-label link renders under your host.
* [Operator observability map](/concepts/operator-observability-map) —
  the broader map this model slots into: dashboards, logs, webhooks, and
  where the status page sits among them.

## See also

* [Platform status: incident history and your shareable status page](/guides/status-page)
* [Monthly SLA and availability report](/guides/monthly-sla-availability-report)
* [The SLA attestation and report backfill model](/concepts/sla-attestation-model)
* [Custom domains and managed SSL](/concepts/custom-domains-and-ssl)
* [Organization API reference](/api-reference/organization) — the domain
  endpoints behind the branded URL