Incidents Across Multiple Components
Last updated: 2026-09-14
An incident can now be linked to more than one affected component — for example, a shared database outage that degrades both your API and Dashboard components at once. Previously, an incident could only reference one component (or none, for a page-wide incident), so a single root cause affecting several components had to be reported as separate incidents, or as one incident that only visibly touched one of them.
Selecting Multiple Components
When you create a new incident, the Affected Component field lets you check as many components as actually apply:
- Leave everything unchecked for a page-wide incident affecting the whole status page.
- Check one component for a standard single-component incident — this behaves exactly as before.
- Check several components to report one incident that spans all of them.
The order you select components in matters: the first component you check becomes the primary component — it’s the one shown in places that only have room for one (the incident list, search results, older integrations). You can still see and remove any selected component before publishing.
Severity stays a single, incident-wide value. You don’t set severity per component — one severity applies to the whole incident and every component it affects.
Monitor targeting and multiple components
If a component aggregates more than one monitor, you can optionally pin the incident to the specific monitor that’s actually affected. This only applies when exactly one component is selected — as soon as you check a second component, monitor targeting is cleared and hidden, since “which one monitor” no longer makes sense once several components are involved. Publishing with more than one component and a monitor still attached is rejected.
Editing Affected Components After Publishing
Unlike the title, initial message, and notification choice — which are locked once an incident is published — the affected components can still be changed afterward, for incidents that are manual (not auto-created from a monitor failure) and not yet Resolved or archived.
Open the incident and use the Affected Components card on its edit page:
- Add a component — check it and save. It’s added to the end of the affected list; the existing primary component doesn’t change.
- Remove a component — uncheck it and save.
- Removing a component other than the primary leaves the primary unchanged.
- Removing the primary component promotes the next-earliest-added surviving component to primary automatically — you don’t choose a replacement yourself.
- Reduce to zero components (make it page-wide) is only available to status page owners and team owners/admins. If you manage components through a scoped team role, ask an owner or admin to make an incident page-wide.
Every change is recorded as a normal timeline entry (e.g. “Affected components updated: added Database; removed CDN”) — it doesn’t move the incident’s status forward or backward.
If the incident is linked to a monitor
An incident created with a specific monitor pinned keeps that link until you explicitly remove it. If you try to add a second component to such an incident, you’ll be asked to confirm unlinking the monitor first — this never happens silently. Once confirmed, the monitor association is cleared and the component is added in the same save.
Who can add or remove which components
If you manage a shared status page through Teams, the same component group permissions that govern incident creation apply here too — you can only add or remove components you have manage access to, whether or not the incident already includes components outside your scope.
How This Shows Up
- Public status page: the incident detail page, status page timeline, and incident banners list every affected component, in the order they were selected — not just one. A long list is shortened in page titles and social preview cards (e.g. “API, CDN and 2 more”) but always shown in full on the page itself.
- Notifications: per-component subscriber targeting and component-group override modes are resolved across every linked component, so subscribers following any of them are notified — not only whoever follows the primary.
- Authenticated API:
GET/POSTincident endpoints return an additivecomponent_idsarray alongside the existingcomponent_idfield, so integrations built against the single-component field keep working unchanged.
Why This Matters
Many real outages aren’t neatly scoped to one component: a shared database, a CDN, or an auth service going down degrades everything that depends on it. Reporting one incident that accurately reflects every component it actually affects means:
- Each affected component’s timeline and uptime accounting reflects the same incident window
- Notifications reach subscribers of any of the affected components, not just one
- Visitors see the true scope of the outage at a glance, instead of one arbitrarily-chosen component