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 Health” 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 Admin permissions.
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.
- Group — a string that lets you cluster related components on the public page. Defaults to “Core Services”. Use the same group string for components that belong together (e.g., “Customer-facing” for the dashboard and API, “Internal” for admin tooling).
- Status — initial status. Defaults to Operational for a new component, which is almost always what you want.
- Description (optional) — a short caption shown under the component name on the public page. Use it to clarify what a component covers (“Reply send and receive across all channels”).
3. Save
Click Create. 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 something like:
- API (group: Core Services) — REST endpoints and webhooks
- Web app / Dashboard (group: Core Services) — the in-browser tenant UI
- Email sending (group: Communications) — outbound email delivery
- Voice (group: Communications) — inbound and outbound phone calls
- Search & retrieval (group: AI) — KB search, embedding-based retrieval
- Reporting (group: Reporting) — Analytics and exports
Group naming is free-form; pick what makes sense for your customers.
5. Update component status as conditions change
Click the status badge next to any component to change it. The five statuses are documented in Component statuses reference.
Component statuses are sticky — Atender does not auto-reset them. When an incident is resolved, walk through the components and flip anything you set to a non-operational status back to Operational.
Reordering and grouping
Components appear on the public page grouped by their Group field, then alphabetically within each group. There’s no manual drag-to-reorder today; rename the group or the components if you want a different order on the page.
Verify it worked
Open the public status page. The System Health section shows each component grouped under its group heading with a status indicator next to its name. Click around — there’s nothing interactive at the component level, but each one should show the status you configured.
In the Incidents Dashboard (Incidents → main view), the System Health card shows each component’s current state, so you can see operational health without leaving the app.
Editing and deleting
Each component row in Settings → Incidents Settings → Components has an Edit and a Delete button:
- Edit opens the dialog with the component’s current values; change anything and save.
- Delete removes the component. Past incidents that linked to it keep their record of the link, but the component itself stops appearing on the page.
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: A component shows in the wrong group. Fix: The group field is just a string. Misspelled “Core services” vs. “Core Services” creates two groups. Edit each component and use exactly the same group string.
- Symptom: I can’t find a way to set ordering inside a group. Fix: Within a group, components are sorted alphabetically by name. Prefix names with a sort key if you need explicit ordering (“1. API”, “2. Dashboard”) — though most teams find alphabetical fine in practice.