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 (manual)
- 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.
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.
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.