Component statuses reference
Each component on your status page has its own status — independent of any active incident. The status shows on the public page and in the dashboard’s “System Health” panel.
The five values
- Operational — Green — Working normally. The expected state for almost every component, almost all the time.
- Degraded — Yellow — Functional, but slower or less reliable than normal. Customers may notice, but the feature still works.
- Partial outage — Orange — 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 — Red — Down or broken for most users. The component is effectively unusable.
- Maintenance — Blue — Intentionally offline for planned work. Distinct from an unplanned outage — customers see this as scheduled, not as a failure.
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 — Free-form — set by an admin at any time
- Driven by — The composer when you post an update — Settings → Incidents Settings → Components, or the component impact/status choices shown while publishing an incident
- 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 independently — you can update a component to degraded without an incident, and you can have a resolved incident while some components are still in maintenance.
Settings remains the place to manage component statuses directly. Incident creation surfaces can also set component impact or status during publish, so the first public incident update can change the snapshot customers see on the status page.
When to change a component status
Update a component’s status when its actual state changes:
- 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
- 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, and some incident creation flows also let you set the affected components’ impact or status as you publish the incident.
In Slack incident creation, each component can be marked as Not affected, Degraded, or Unavailable. Those choices help set the component impact/status for the incident, but they do not make component status temporary.
Component status is sticky
Atender does not automatically reset components to operational when an incident is resolved. If you set a component to major_outage when creating an incident, you must manually flip it back to operational when the incident is resolved. Two reasons:
- The component might still be degraded even after the immediate incident is closed.
- Atender has no opinion about which incident’s resolution should reset which component.
A practical pattern: when you post the “Resolved” update on an incident, walk through Settings → Incidents Settings → Components and flip everything you previously set to a non-operational status back to operational.