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.
- 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 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 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.
Verify it worked
Open the public status page. The System Health section lists components with a status indicator next to each name. If your tenant already has multiple backend-preserved groups, those groups may appear as separate sections. 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: 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.