Component statuses reference

Each component on your status page has its own status — independent of any active incident. The status shows on the public status page, in the System Status block of your help-centre portal, and in the System Health panel of Analytics → Incidents.

The five values

A component’s status is always exactly one of these five stored values. There are no others.

• operational — Working normally. The default for a new component, and the expected state for almost every component, almost all the time.
• degraded — Functional, but slower or less reliable than normal. Customers may notice, but the feature still works.
• partial_outage — Working for some users or in some regions, but not all. Or: a sub-feature is down while the main feature is up.
• major_outage — Down or broken for most users. The component is effectively unusable.
• maintenance — Intentionally offline for planned work. Distinct from an unplanned outage — customers see this as scheduled, not as a failure.

How each value is labelled

The displayed label is not the same on every surface. major_outage in particular reads as Unavailable everywhere the incident workflow touches it, and as Major Outage on the customer-facing page.

• operational — Operational — Operational — Operational
• degraded — Degraded Performance — Degraded — Degraded
• partial_outage — Partial Outage — Partial Outage — Partial outage
• major_outage — Major Outage — Major Outage — Unavailable
• maintenance — Under Maintenance — Maintenance — Maintenance

Colour and icon on the public status page

• operational — Green — Check in a circle
• degraded — Yellow — Triangle warning
• partial_outage — Orange — Exclamation in a circle
• major_outage — Red — Cross in a circle
• maintenance — Blue — Wrench

The same five colours are used for the component dots in the help-centre portal’s System Status block. The Components tab in Settings uses a shorter palette: degraded and partial_outage share the same amber badge there, so the two are told apart by their labels rather than by colour.

Which surfaces offer which values

Not every surface lets you pick all five:

• Settings → Incidents Settings → Components — all five, from the Status field on the component’s add/edit form.
• The incident workspace rail — three only: Operational, Degraded, Unavailable (major_outage). partial_outage and maintenance are displayed if a component already holds them, but cannot be picked here.
• Slack incident creation — each component row offers Not affected, Degraded, Unavailable. If a component already sits in partial_outage or maintenance, that value is appended as an extra option on its row so leaving the row untouched does not clobber it. This per-component row layout only appears when the workspace has 10 or fewer components; above that the prompt falls back to a single multi-select of affected components with no per-component impact.
• Slack incident updates — the same, plus Operational.
• The public API — PATCH /api/v1/incidents/components/{id} accepts all five in its status field (scope status:write).

How component statuses roll up to overall status

The banner at the top of the public status page shows one overall status, computed from every component and every live incident. The order is strict — the first match wins:

1. major_outage — any component in major_outage, or any live incident with severity critical.
2. partial_outage — any component in partial_outage, or any live incident with severity major.
3. degraded — any component in degraded, or any live incident with severity minor.
4. maintenance — any component in maintenance.
5. operational — none of the above.

Two consequences worth knowing:

• maintenance sits below the three outage states. A component in maintenance never masks another component that is degraded or worse.
• A planned maintenance window that has not opened yet (status scheduled) is announced, not happening — it does not colour the overall status, and it applies no component impact until the window starts.

When overall status is operational the banner reads All Systems Operational; otherwise it reads that status’s public label from the table above.

How component status differs from incident status

These are two separate concepts:

• Applies to — The incident as a whole — One named piece of your system
• Lifecycle — Investigating → Identified → Monitoring → Resolved — No lifecycle — any of the five values, in any order
• Driven by — The composer when you post an update — Settings → Incidents Settings → Components, the affected-component controls on an incident, the public API, or Atender’s own automatic changes (below)
• Public-page role — Shows where in the response you are — Shows whether each system piece is up

An incident is the narrative. Component statuses are the current snapshot. The two move mostly independently — you can set a component to degraded in Settings without any incident at all, and a resolved incident can sit alongside components that are still in maintenance for other reasons.

Settings remains the place to manage component statuses directly. Incident surfaces also set component status while you publish or update an incident, so the first public incident update can change the snapshot customers see on the status page.

When component status changes automatically

Atender changes component status on its own in four situations. Outside these, a status you set stays until someone changes it.

1. Creating an incident with affected components. From the web, every affected component that is still operational is moved to degraded — a component on an active incident should not read as “operational”. Components already in a worse state are left alone. From Slack, each component is set to the impact you picked on its row instead.
2. Starting a planned maintenance window. Every affected component that is still operational moves to maintenance. Components already in a worse state are left alone, so maintenance never masks a live outage.
3. Resolving an incident. Every component linked to that incident goes back to operational — unless it is still linked to another incident that is live. This is the part that surprises people: the restore does not care how the component reached its current status. If you set a component to major_outage by hand in Settings and that component is also linked to an incident you then resolve, it will be reset to operational along with the rest.
4. Deleting an incident. The same restore runs: any component whose only remaining live incident was the deleted one goes back to operational.

The restore only ever writes operational. It never restores a component to some earlier non-operational value, so a component you deliberately wanted left in maintenance after an incident closes has to be set again.

Components with a System link ride the same machinery. Email is the only system key available, and at most one component per workspace may carry it. When Atender’s dependency watcher detects an email-provider outage it opens an Atender-owned incident on your status page and sets the linked component to degraded; when the watcher sees real evidence of recovery it resolves that incident, and the ordinary resolve-time restore returns the component to operational.

When to change a component status yourself

Update a component’s status directly when its actual state changes and no incident is doing it for you:

• Operational → Degraded — performance is measurably worse, but the feature still works
• Operational → Major outage — the feature is unusable
• Operational → Maintenance — you’re starting planned work that will take the component offline outside a scheduled maintenance window
• Anything → Operational — the component is back to normal

Most teams change component status at the same moments they post incident updates — they’re two sides of the same operational beat. You can do that directly in Settings → Incidents Settings → Components, or on the incident itself while you publish or update it.

A practical pattern: when you post the “Resolved” update on an incident, check the components afterwards. The ones linked to that incident have already gone back to operational; what needs a Settings pass is anything you changed by hand that was never linked to the incident, anything still held down by another live incident, and anything that should deliberately stay non-operational.

See also

• The Incidents module
• Configure status-page components
• Link a status page component to a system
• Incident statuses reference