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 /incidents/<your-slug> on your Atender app’s own address (or your own custom domain) where customers can check service health and read incident updates.
• Email subscribers — customers can subscribe to get notified each time you post an update on an incident.
• A components model — split your system into named pieces (“API”, “Dashboard”, “Email delivery”) so customers see exactly which parts are affected.
• A structured lifecycle — unplanned incidents move through investigating → identified → monitoring → resolved, with a posted update at each step; planned maintenance windows go Planned → In progress → Completed instead.
• Post-mortem reports — after an incident is resolved, your team can draft a private post-mortem, publish it to the status page, optionally email subscribers, edit it later, or remove it if it should no longer be public.
• AI awareness — Sidekick checks each conversation for a matching incident, and your Agent Stacks can look up active incidents through the built-in Check System Status tool, 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, turned on per incident with the Use severity level toggle
• 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

Unplanned incidents move through four statuses:

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.

Planned maintenance windows have a lifecycle of their own — Planned → In progress → Completed — see Schedule planned maintenance.

Writing a post-mortem after resolution is separate from the incident lifecycle. Drafting, publishing, editing, or removing a post-mortem does not reopen the incident or change when it was resolved.

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, either to all status updates or to a single incident; subscribers get an email for every update you post on an incident. Creating an ordinary incident does not send an email on its own — the first update you post does. Planned maintenance is the exception: subscribers are emailed as soon as you publish the window. 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 severity badge next to the incident title 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 reach incidents through the built-in Check System Status tool, which you enable and assign to an agent like any other tool. When a customer reports a problem, the agent calls it and gets back the matching incidents, their latest update, the affected components, and a link to the status page to use in its reply.
• 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.

Sidekick’s 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. (Automation rules can react to incidents through the Incident Created, Incident Updated and Incident Resolved triggers, but there is no incident webhook.)
• One post-mortem per incident. A resolved incident can have a post-mortem report, but not multiple separate reports.

Post-mortems for resolved incidents

Resolved incidents can have a post-mortem in Atender (planned maintenance windows can’t). Operators can start or continue one from the card on the incident detail page, or from the resolved incident list link. The list link changes based on state: Write post-mortem, Finish post-mortem, or Post-mortem.

If a post-mortem is not useful for a particular incident, your team can mark it as not needed. Draft post-mortems are private while unpublished and are not shown on the public status page. When the report is ready, you can publish it to the status page and choose whether to email subscribers. Published post-mortems can be edited later, and Remove post-mortem takes a published report off the status page and deletes it. If the incident is reopened, the report becomes read-only until the incident is resolved again.

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