Platform status: incident history and your shareable status page
Settings → Platform status is the trust surface for your organization. It
answers two questions in one place: has a platform incident actually affected
my channels recently, and what link do I give my customers so they can see
the same for themselves — under your own branding when you run a white-label
domain.
The page is split into the org-scoped incident history for you, and the
white-label status URL you share outward. Both are read models over the
same public incident feed Orbit publishes, so the figure you quote to a
customer and the page that customer opens always agree.
Org-scoped incident history vs the share URL
These are two different views of the same incident feed:
- Org-scoped incident history (your dashboard view). The headline
indicator plus the incident windows that affected your organization’s
channels across the current and previous month, split into Active now
(windows still open) and Recent history (resolved windows). A
component-scoped incident maps to the channels you actually use; a
platform-wide window counts against every channel. Incidents whose declared
component never touched your channel universe don’t surface here at all —
you only see the windows that could plausibly explain a dip in your own
traffic.
- White-label status URL (your customers’ view). The public status page —
overall indicator, per-component health, active incidents with their
update timeline, recent resolved history, and scheduled maintenance,
readable without an account. Resolve it under your own host when you have
an active white-label custom domain so customers see your brand, not
Orbit’s.
Read Active now first — it’s the difference between “a degraded number on
your dashboard” (see below) and “a declared platform event.” Then recent
history when you need the exact window to quote back to a customer or attach
to an internal review.
What the shared page tells customers — and what it leaves out
The page your link opens tells the customer four things: the overall
indicator (Operational, Minor, Major, Critical, or Maintenance), per-
component health (SMS, WhatsApp, email, voice, video, AI agents, API —
grouped), the active incidents with a timestamped update timeline, and
the recently resolved history over the last fortnight. Scheduled
maintenance windows are upcoming too.
What it deliberately leaves out: your organization name, any other tenant,
per-tenant data, and anything about your specific traffic. The page is a
platform-level trust document — customers read it to time their own retries
and acknowledge planned impact, not to get a peek at your account. That’s
what makes the link safe to share.
Sharing the link safely
The link needs no credentials, and the page is safe to hand to anyone.
Get the copy-safe shape straight from the dashboard so the host and locale
are baked in:
- Open Settings → Platform status (owner or admin role — the dashboard
gates it to the roles trusted to share org-scoped history).
- Click Copy link in the white-label block. A toast confirms the copy;
if the clipboard write fails, the card shows the URL in a pre-format
block you can select manually.
- Hand the URL out — paste it into an internal wiki, your status footer, or
a direct message. Anyone who opens it reads the current platform status
without logging in.
If a white-label custom domain is blocked out, the share URL still falls back
to the platform host (orbit.devotel.io/{locale}/status) so the link is
always shareable. Register and activate a custom domain under Settings →
Branding, and the same page resolves under your own host via Orbit’s
edge-resolution — then the copied URL points at your brand.
Don’t build the URL by hand-splicing a string you lifted from the browser
address bar — the dashboard copy action guarantees it’s either your
active white-label host or the platform fallback, never an org-scoped
token or a ?tenant= parameter dangling in the copy. If you see any
unexpected query parameters in the URL, go back and copy it again — the
toast or manual-select path only carries the bare path.
Where the data comes from
The incident feed behind both views is status-as-code: operators publish
an incident, advance its timeline (Investigating → Identified → Monitoring →
Resolved), or announce a maintenance window by editing a versioned registry
and shipping a deploy — there is no separate incident database for you to
manage, and no tenant or organization data ever rides on the public page.
The org-scoped dashboard read is layered on top of that same registry and
resolves each declared component to channels against your own organization
through the SLA report pipeline — so “affected your channels” is a precise
statement, not a platform-wide broadcast synthesized client-side. On the
shared page, per-component health rolls up through the same worst-first
derivation everywhere it appears — the public page, the JSON summary, and
the RSS feed — so the figure you quote and the page your customer opens
always agree.
Subscribing to alerts
The page you share carries zero-storage subscription channels out of the
box: a machine-readable JSON summary at /api/status and an RSS
feed, both readable without an account. Point your uptime monitor, Slack
bot, or status badge at the JSON summary; hand RSS to anyone who wants
updates in a feed reader. In the dashboard, the owner/admin view on
Settings → Platform status keeps the live indicator in front of the roles
who act on incidents — no configuration needed beyond the role gate. A
persisted push-notification channel (email/SMS/WhatsApp subscribers)
captures subscriber data of your customers and so stays an opt-in surface:
if you want it, raise it with your contact at Devotel rather than assuming
it’s already part of your plan.
Maintenance-window etiquette
Scheduled windows are announced ahead of time on the shared page, and they
surface there whether or not they touched a channel you use — read them as
capacity planning, not as incidents. A window moves to In progress
inside its declared times and closes as Completed when the end time
passes; don’t treat an in-progress window as an outage and don’t open a
support ticket for impact inside the declared window. When the window
upgrades a component you run, hold your retry storms until it completes —
the per-component health line tells you the moment the component leaves
under_maintenance.
During a partial outage
When the indicator reads Minor, Major, or Critical, work the affected
component first and hold everything else steady:
- Confirm scope on the shared page — a partial outage on one component
(say, SMS delivery) doesn’t imply your other channels are affected; the
per-component line tells you which plane is safe to keep using.
- Route around the affected component where your traffic allows it —
Orbit’s fallback planes (org capability chain, per-request DLR fallback,
message-level cascade policy, notify waterfall bounds, campaign
channels[] ladder) advance a send to the next channel when one plane
is down. Pick the right plane and set it up before you need it:
The five fallback planes.
- Don’t hammer retries against the degraded component — a retry storm
lengthens the window for everyone, and the timeline tells you when
it’s draining.
- After resolution, reconcile against your own analytics — the window
you quote back to customers is the exact window in Recent history,
and tenant-level failures outside platform events (a rejected sender,
an exhausted wallet) never ride on the page.
What surfaces, and what doesn’t
Incidents that surface: platform-declared incidents whose declared
component could have affected your channels, plus every platform-wide
window. Scheduled maintenance also surfaces on the shared page, and it
shows on that page regardless of whether it affected any channel.
What doesn’t surface: tenant-level delivery failures that aren’t declared
platform events — carrier rejections, unregistered senders, filtered content,
insufficient wallet balance, malformed recipients. Those lower your channel’s
delivery success without ever appearing in the incident history, and your
customers won’t see them on the shared page either. Cross-check them against
your own analytics and the delivery_health tier on the SLA report
(see Monthly SLA and availability report).
Also excluded from the org-scoped view: incident windows whose affected
component never mapped to a channel you use (a video-only incident won’t
shadow a tenant that only runs SMS and email).
Embedding the link
Embed the copied URL as a plain redirect or link — it’s a full public page,
not an iframe snippet, so a target="_blank" anchor is the standard pattern:
Typical spots: your account portal footer, an in-app **?” menu, or your own
status route that proxies to the link. When the customer hits the page the
overall indicator plus per-component health answers the question “is Orbit
down?” without a support ticket. For programmatic checks — uptime monitors,
Slack bots, status badges — the page also exposes a JSON summary at
/api/status and an RSS feed the customer can subscribe to with no account
(see the Status Page API reference).
The indicator derivation there mirrors the dashboard pill, so what your
customers read and what you see never disagree.
See also
