The Incidents module

When something goes wrong with your service — an API outage, degraded performance, a planned maintenance window — you need a single place to tell customers what’s happening, update them as the situation evolves, and keep your own team on the same page. That’s what the Incidents module is.

What you get

• A public status page at https://<your-tenant>.atender.dev/incidents/<your-slug> (or your own custom domain) where customers can check service health and read incident updates.
• Email subscribers — customers can subscribe to get notified when incidents are created and updated.
• A components model — split your system into named pieces (“API”, “Dashboard”, “Email delivery”) so customers see exactly which parts are affected.
• A structured lifecycle — every incident moves through investigating → identified → monitoring → resolved, with a posted update at each step.
• AI awareness — your Agent Stacks and Sidekick check for matching incidents on every conversation, so customers asking “is the site down?” get an immediate, accurate answer.
• An embeddable widget — drop a status indicator onto your own site or product so the current health is visible without a click-through.

What an incident is

An incident is a record of a service disruption with these properties:

• Title — Short headline shown to customers (“API response times degraded”)
• Status — Where in the lifecycle the incident is (investigating, identified, monitoring, resolved)
• Severity — Minor, Major, or Critical — optional, can be turned off per tenant
• Affected components — Which named system pieces this incident touches
• Updates — A chronological list of timestamped posts, each tied to a status

Incidents and conversations are separate entities. A conversation is a single interaction with one customer; an incident is a publicly-visible event that may correlate to many conversations. They link through Atender’s incident-detection logic (see “AI awareness” below).

The lifecycle

Incidents follow a fixed sequence:

1. Investigating — you’re aware of a problem and looking into it.
2. Identified — root cause confirmed.
3. Monitoring — fix deployed; watching for stability.
4. Resolved — the incident is closed.

The composer suggests the next logical status whenever you post an update, so the typical flow is a click and a paragraph. See Incident statuses for the full reference.

The public status page

The status page lives at a public URL — no login required — and shows:

• All active incidents at the top, with severity and status badges
• A timeline of updates for each incident
• Affected components
• System health summary (each named component shown with its current status)
• Historical (resolved) incidents below

Customers can subscribe by email; subscribers get an email when an incident is created and on every subsequent update. See Let customers subscribe.

Severity is optional

Incident severity (Minor / Major / Critical) is not required. When creating an incident, you can leave it off entirely — useful for tenants whose users don’t need the severity signal, or whose ops culture handles severity outside Atender. Severity, when set, drives a colored bar on the public page so visitors can scan urgency at a glance.

Components: what they are

A component is a named system piece — “API”, “Dashboard”, “Email delivery”, “Storage” — with its own current status. Components serve two purposes:

• Communication — when you create an incident, you can link it to one or more affected components, so customers immediately see which parts of the service are involved.
• Health summary — the status page shows each component’s status independently of any active incident. A green “Operational” indicator on every component is the strongest signal that everything’s fine.

Component statuses are separate from incident statuses. A component can be in degraded, partial_outage, major_outage, maintenance, or operational state. See Component statuses.

AI awareness — incidents and the rest of Atender

The Incidents module is wired into both the AI inference layer and the agent assistance layer:

• Agent Stacks — your AI specialist agents check for matching incidents on every conversation. If a customer’s question is similar to an ongoing incident, the AI references it in its reply and offers a link to the status page. This handles the “is the site down?” surge automatically.
• Sidekick — for conversations handled by human agents, Sidekick surfaces “Possible Incident Match” suggestions with a confidence score and offers to link the conversation to the incident. See Link a conversation to an incident.

Matching is semantic — it works on the meaning of the customer’s message, not just keywords — so a customer who says “your login keeps timing out” gets matched to an incident titled “Authentication latency degraded.”

What is NOT in Incidents today

A few things that exist in similar tools and don’t (yet) ship in Atender:

• No RSS feed. Subscribers receive updates by email only.
• No SMS notifications. Email-only.
• No webhooks for incident events in the dedicated incidents API. (You can build similar behaviour with an automation rule on a related conversation, but there’s no first-class “incident created” webhook.)
• No post-mortem editor. The incident timeline is the record. Write your post-mortem wherever you normally write them and link it from the resolved incident’s final update.

Where to start

If you’re setting up Incidents for the first time, this is the order:

1. Configure your components — name the parts of your system you want to show.
2. Create a test incident and walk it through to resolved so you’ve seen the full flow.
3. Let customers subscribe — your incident notifications won’t reach anyone until at least one subscriber exists.
4. (Optional) Embed the status widget on your main website.
5. (Optional) Connect a custom domain so the page lives at status.yourcompany.com.

See also

• Incident statuses reference
• Component statuses reference
• Create an incident
• Link a conversation to an incident