Configure status-page components
Components are the parts of your system that customers see on the public status page. Without components, the status page can still show incidents, but the “System Components” section is empty. A well-modeled component list lets visitors see at a glance which parts are affected — and lets you write tighter incidents that link to exactly the right pieces.
Before you start
- Decide on the component breakdown you want. Most teams use 4–10 components. Too few and customers can’t tell what’s affected; too many and the page becomes a wall of green ticks.
- A user role with the Incidents module permission.
Steps
1. Open the Components tab
Go to Settings → Incidents Settings → Components. You see a list of existing components (empty on a fresh tenant).
2. Add a component
Click Add Component in the top-right. The dialog has these fields:
- Component Name — the visible name. Use plain customer-facing language: “API”, “Dashboard”, “Email delivery”, not internal codenames.
- Status — initial status. Defaults to Operational for a new component, which is almost always what you want.
- Description (optional) — a short caption shown in the Description column of the components list in Settings; the public status page does not render it. Use it to clarify what a component covers (“Reply send and receive across all channels”).
- System link (optional) — links the component to an Atender-managed system dependency. Choosing Email opts that component into automatic dependency incident handling: if Atender detects a shared email dependency outage affecting your tenant, the linked component can be marked degraded and included in an incident automatically.
3. Save
Click Add Component at the bottom of the dialog. (The same button reads Save Changes when you reopen the dialog to edit an existing component.) The component appears in the list and on the public status page.
4. Repeat for each component you want
Add as many as your system warrants. A typical SaaS tenant ends up with components like:
- API — REST endpoints and webhooks
- Web app / Dashboard — the in-browser tenant UI
- Email sending — outbound email delivery
- Voice — inbound and outbound phone calls
- Search & retrieval — KB search, embedding-based retrieval
- Reporting — Analytics and exports
5. Update component status as conditions change
Click the edit (pencil) icon next to any component and change Status in the dialog. The five statuses are documented in Component statuses reference.
Component statuses you change directly in Settings are sticky: Atender does not auto-reset those manual edits. When conditions return to normal, walk through the components and flip anything you manually set to a non-operational status back to Operational.
Incident-managed impact behaves differently for Public live incidents. When you list a component as affected by a Public live incident, Atender marks it degraded on its own, and when that incident is resolved (or deleted) it puts the component back to Operational — unless another still-open Public incident also lists it (on the delete path the check is wider: any still-open incident, Internal ones included, holds the component down). Internal incidents can still list affected components for team context, but they never degrade a component or drive the overall status, and they do not keep a component degraded when another Public incident resolves. Resolving or deleting an Internal incident does, however, release the components it lists back to Operational. Note that this restore does not check how the component reached its current status: if you manually set an affected component to Major Outage while the Public incident was open, resolving the incident flips it to Operational anyway. After resolving, check the public status page and the System Health card to confirm each component reads the way you intend.
Verify it worked
Open the public status page. The System Components section lists components with a status badge next to each name. If your tenant already has multiple backend-preserved groups, those groups may appear as separate sections. Nothing in that section is interactive — each row is static text plus a badge — but each one should show the status you configured.
Inside the app, the System Health card shows each component’s current state. It lives on the Incidents analytics view (Analytics → Incidents), not on the Incidents page itself.
Editing and deleting
Each component row in Settings → Incidents Settings → Components has an edit (pencil) and a delete (bin) icon button in its Actions column. Components linked to an Atender-managed system dependency also show a badge such as Linked: Email on the row.
- Edit opens the dialog with the component’s current values; change anything and save.
- Delete removes the component. The affected-component links cascade with it, so incidents that listed it lose that link, and the component stops appearing on the page.
Careful: the delete icon has no confirmation step. Clicking it deletes the component immediately.
Don’t delete a component just because it’s currently in major_outage — set its status back to operational instead, so historical incidents that reference it still have a valid target.
Troubleshooting
- Symptom: Components don’t show on the public status page. Fix: Components show even when all are operational. Hard-refresh the public page. If they still don’t show, check that you’re on the right tenant slug.
- Symptom: I can’t find a way to set ordering inside a group. Fix: Within a group, components are sorted by display order and then by name; the component dialog doesn’t expose display order, so components you add there all share the default and fall back to name order. Prefix names with a sort key if you need explicit ordering (“1. API”, “2. Dashboard”) — though most teams find alphabetical fine in practice.