Skip to main content

​
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: 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); 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; 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.

​
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 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 — 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 — the per-tenant availability attestation over the same feed; availability figures, CSV export, and the credit surface.
  • 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 — the registration → CNAME → managed-certificate lifecycle that decides whether your white-label link renders under your host.
  • Operator observability map — the broader map this model slots into: dashboards, logs, webhooks, and where the status page sits among them.

​
See also