What an incident is
A record of something going wrong, posted by your team and updated as it progresses. Each incident has a severity, a status that moves through a defined lifecycle, the components it’s affecting, and a timeline of updates that anyone can follow.
1Severity
— how loud should this be?
●
Minor
Limited impact — some users may notice slowness or small glitches
●
Major
Broad impact — many users affected, core functionality impaired
●
Critical
Full outage or data–affecting issue — service is down or data is at risk
Whatever the severity, every incident moves through the same lifecycle ↓
2Status lifecycle
— the four states an incident moves through
?
Investigating
You’re aware of the issue and looking into it.
!
Identified
You’ve found the root cause.
◎
Monitoring
A fix has been deployed, watching for stability.
✓
Resolved
Confirmed fixed. The incident closes.
Smooth transitions. When you post an update, the composer suggests the logical next status. Investigating → Identified → Monitoring → Resolved — one click and you’re moving the incident forward. The lifecycle is a path, not a form to fill in.
And here’s how an incident is built ↓
3How you build one
— a four-step setup, in order
Step 1
Title the incident clearly
Write a short, specific headline — “API response times degraded,” not “Issue with system.” This is the one line that customers, AI, and Sidekick will all see, so the wording is what makes incident matching work. Vague titles match nothing; specific titles match the right conversations.
Step 2
Set severity and pick affected components
Choose Minor, Major, or Critical — or leave severity off entirely if the incident shouldn’t carry one. Then check off which components are affected (Web App, API, Payments, etc.). Components are the blocks customers see on the public page; tagging them here flips them out of “operational” for the duration of the incident.
Step 3
Post the first update
The first update typically lands the incident in Investigating. Each update is timestamped, and can change the status, the severity, or both. A status–only or severity–only update is a valid signal — you don’t need a paragraph just to move from Investigating to Identified.
Step 4
Keep posting until resolved
Updates accumulate as a chronological timeline anyone can follow. Edits leave an audit trail in incident_update_revisions, so the public history stays trustworthy. Posting an update with status Resolved closes the incident and stamps resolvedAt — subscribers get one final notification.
The public status page
Every tenant gets a hosted status page customers can visit, link to, and subscribe to. Three things live on it: a header showing each component’s current state, a stack of active incidents with their full update timeline, and a history of recent past incidents.
1What customers see
— three parts, one page
Components
Per–service health
Each component shows a state: operational, degraded, partial outage, major outage, or maintenance. Grouped (e.g. Core Services, APIs) and ordered however you configure them.
Active incidents
Live timeline per incident
Each incident shows its title, severity tag, current status, and a chronological list of every update you’ve posted — so anyone arriving mid–outage can read the whole story.
Recent history
Past incidents, transparently
Resolved incidents stay visible for the retention period you set. Customers (and prospects) can scroll back and see the cadence and quality of your responses.
And one button matters more than the rest ↓
2Subscribers
— where the support–volume win starts
Subscribe
Customers opt in by email
Anyone visiting the status page can drop their email and subscribe to all updates, or to a specific incident. Each subscriber gets a verification link, and every email carries a one–click unsubscribe token. When you post an update, the platform fans out a notification to every subscriber who opted in — sent through your configured email channel, or the platform default if you haven’t connected one.
Subscriber emails replace inbound conversations. If 200 customers would have written in to ask “is the site down?”, a subscriber email tells them — before they even open a support channel. The cheapest support ticket is the one that never opens.
And the page itself is yours to brand ↓
3Branding & distribution
— make it look like yours
Logo, favicon, primary color
Drop in your logo and favicon, set a primary color, and the page reflects your brand. Set a custom title and description for the heading.
Custom domains
Host the status page on your own domain (e.g. status.yourcompany.com) instead of the Atender–hosted URL. You can attach more than one custom domain to the same page.
How the rest of Atender stays incident–aware
This is what separates Atender’s incidents from a standalone status page. Every conversation — whether handled by an AI agent stack or a human agent in Sidekick — is checked against your active incidents in real time. When the customer’s problem matches, the system already knows. The agent just confirms.
1Inside Agent Stacks
— AI conversations get incident–aware automatically
status_check
native tool
Every AI agent can check the status page
When a customer says something like “I can’t log in,” “the app isn’t working,” or “my payment failed,” the specialist calls status_check with keywords from the message. The tool returns matching active incidents, the affected components, and a relevance score — and the agent works that context straight into its reply.
status_subscribe
native tool
Customers can subscribe mid–conversation
After acknowledging the incident, the agent offers updates. If the customer agrees — in any language — an LLM–based confirmation analyzer parses the reply, distinguishes a real “yes” from a generic “ok thanks,” and the agent calls status_subscribe to enrol that email. They get notified the moment it’s resolved.
This is where Atender saves you the most work. During a major outage you might receive hundreds of conversations all asking the same thing. Because the agent stack already knows about the incident, it answers every one of them — consistently, with the right status, and with a one–tap subscribe. Your human team stays free for the conversations that aren’t about the outage.
And for human–handled conversations, Sidekick mirrors the same awareness ↓
2Inside Sidekick
— the same awareness, surfaced for human agents
Possible Incident Match
Sidekick card
A card appears in the agent’s side panel
For every incoming message, Sidekick compares what the customer wrote against every active incident. When the wording lines up well enough, a card surfaces in the side panel showing the incident title, severity, current status, and a confidence score. The agent never has to remember an outage is happening — if the message looks like it’s about the outage, the card is right there.
3What the agent does from the card
— two one–click actions
Link & subscribe
Links the conversation to the incident (so it shows up in incident–related reporting) and subscribes the customer’s email to incident updates. When you post the resolution update, the customer is notified automatically — the agent doesn’t need to remember to follow up.
Insert reply
Drops a templated, language–localised acknowledgement straight into the reply editor — references the incident, sets expectations, offers updates. The agent reviews and sends. No copy–paste, no incident pasted into the wrong conversation.
One incident. Two channels. Same awareness. The same record drives the AI agent stacks calling status_check, the Sidekick card popping up beside human agents, the email blast to subscribers, and the public status page customers visit on their own. You post the incident once — the system fans it out everywhere it’s useful.
