Status page and incidents

For whoever is running the desk.

Components with a state, incidents with a timeline, subscribers who are emailed, and a feed anybody can render. The desk does not host a status page; it hosts the data, plus a drop-in embed you put on your own site.

Components

Per brand: the things you report on, a region, the panel, the API, mail. Each carries a status: operational, degraded, partial outage, major outage, or maintenance.

Component statuses are usually set by incidents rather than by hand: an incident names the components it affects, sets them, and restores them when it resolves, unless another open incident still touches them.

A component can be shown on several brands, with the same status everywhere.

Incidents

An incident has a number (INC-2026-0001, the prefix is yours), a kind (incident, or planned maintenance with a window), an impact (none, minor, major, critical), the components it affects, and a timeline of updates.

Each update moves the status along: investigating → identified → monitoring → resolved (maintenance: scheduled → in progress → completed). Every update can, independently:

• Email the incident’s mailing list: a mass-mail list, sent through the throttled campaign pipeline.
• Email confirmed status subscribers.
• Refresh the incident’s announcement bar on your sites, the ticket area and the chat widget.

And the AI assistant and reply drafts are given a “current incidents” block, so they stop telling people everything is fine.

Administrators are notified in-app when an incident opens. Everything is audited.

Across brands

An incident belongs to the brand that opened it (numbering, audit, edit and delete) but can be published to other brands, each with its own mailing list, its own banner and its own feed entry. A non-owning brand’s Status tab lists it marked “from brand”, and its admins can post updates.

The public feed

Per brand, at a random key you can regenerate:

GET /status/{key}.json            components, active incidents, maintenance, last 7 days, overall
GET /status/{key}/feed.atom       the same as an Atom feed
GET /status/{key}/incidents/{number}.json
POST /status/{key}/subscribe      an email address

Read-only, no cookies, cached for a minute, and shared with every origin, so a static site, a monitoring tool or somebody else’s dashboard can read it. The same data is available through the site snippet and through the signed integration API, for platforms that render their own page.

The embed

For putting a real status page on your own website, with no work:

<script async src="https://desk.example.com/s/YOUR-EMBED-KEY.js"></script>
<div data-desk-status></div>

That draws the overall status, the components, active incidents with their timelines, planned maintenance, the past seven days and a subscribe form, in your brand colour, light and dark aware, refreshed every minute, with stable class names if you want to restyle it. data-desk-status="compact" draws a small “All systems operational” pill instead.

The embed has its own key and its own list of allowed sites, shared with nothing else.

Who may read the feed

Three settings: public (any site, the default), sites (the sharing header only for your own sites, browsers elsewhere are refused, though server-side readers still work, because a public feed cannot really be private), or off (404).

Subscribers

Anybody can subscribe an address, confirm it by email, and unsubscribe from a link on every update. Subscribers are their own records and are never matched to a client account by address. The list can be exported.

Switching it off

Incidents are optional per brand. Off means the public feed 404s, the platform API and the snippet report enabled: false (with your external status page address, if you have one), no banner is drawn, and the assistant gets no incident context. Recorded incidents are kept.

That last detail is how you point the desk at an external status page (Statuspage, Instatus, whatever) while still using it for everything else.

Advice

• Write the first update before you know the cause. “Investigating reports of slow API responses” at five past beats a perfect explanation at six.
• Keep components few. One per thing a client would recognise.
• Use maintenance windows. A planned window that appears on the calendar and in the bar prevents most of the tickets a maintenance generates.