Create an incident
The moment you create an active incident from the web UI, two things happen at once: the public status page updates, and Sidekick starts checking inbound conversations against the new incident for matches. Speed matters; do this as soon as you confirm an issue is real.
Before you start
- You need a user role that can create incidents (typically Owner, Team Lead, or a custom role holding the Incidents module permission).
- If you’ll link the incident to specific system pieces, those pieces need to exist as components. Components can be created first or added later.
- Incidents created through the API update the public status page and AI awareness, but they do not send subscriber notifications automatically. If your API caller needs notification behavior, handle that separately — posting an update from the web UI is what fans out to subscribers.
Steps
1. Open the new-incident pane
Go to Incidents in the sidebar. Click New incident in the top-right. A slide-in pane opens from the right.
2. Write a clear, concise title
The title is what subscribers see in the subject line of their notification email when you post an update, and what visitors read first on the public page. Aim for a short factual headline:
- ✅ “API response times degraded”
- ✅ “Outbound email delivery delayed”
- ✅ “Scheduled maintenance — Authentication service”
- ❌ “Things are broken” (too vague)
- ❌ “We’re investigating reports of some kind of issue with the platform” (too long)
The title is required.
3. Pick a severity (optional)
Toggle severity on if you want it set, then pick Minor, Major, or Critical. Severity is optional — leave it off if your team doesn’t standardize around it. When set, the severity appears as a colored badge next to the incident title on the public page.
Rule of thumb:
- Minor — small issue, limited impact, some users may notice
- Major — significant issue, broad impact, core functionality impaired
- Critical — full outage or data-affecting issue
4. Pick the initial status
Choose between:
- Investigating (default) — you’re aware of the problem; cause is unknown
- Identified — you already know the cause when you create the incident
- Monitoring — a fix is already deployed and you’re just communicating that to customers
You can’t create an incident in the Resolved state — incidents must be created active.
If this is planned maintenance instead of an active incident, choose Schedule for later and set the maintenance start time. You can also add an optional end time. Scheduled maintenance does not mark affected components as under maintenance until the scheduled window starts or you start it manually. After you create it, use the planned-window panel to start it early, reschedule it, or cancel it.
5. Pick affected components
Open the Affected components picker and check every component impacted by this incident. You can pick zero, one, or many. Picking components on an active incident automatically moves any of them that are currently Operational to Degraded — you can change a component’s status afterwards from the incident’s Affected components rail or in Settings → Incidents Settings → Components.
If you’re creating the incident from Slack, up to 10 components appear as impact rows where you choose Not affected, Degraded, or Unavailable. Components that AI suspects are affected are prefilled as Degraded. Use the Set all components… select to choose Mark all degraded, Mark all unavailable, or Mark all not affected. Choosing one sets every visible component row exactly to that value, overriding any AI-prefilled values. If you edit an individual row afterward, that row keeps your individual choice. If there are more than 10 components, Slack still falls back to a multi-select layout.
If you haven’t configured components yet, skip this step. The incident will still be created and visible.
6. Pick tags (optional)
Use the tags picker if you want to describe what else the incident affects beyond component health, such as a device, market, app, or region. Tags are optional and come from your tenant’s existing tag hierarchy.
Admins can choose how this picker appears — either as search or as a tag cloud — in Settings → Incidents Settings → General.
7. Write the first update
The textarea at the bottom is the initial update message. Creating an active incident does not email it to subscribers — the first update you post afterwards is what notifies them. It is also what visitors see at the top of the incident timeline.
A good first update names the symptom, what you know so far, and what you’re doing. Examples:
“We’ve identified elevated error rates on the payment processing service. Engineering is investigating. We’ll post the next update within 30 minutes.”
“We’re aware that the API is returning intermittent 502 errors for some customers. Investigating root cause now.”
The first-update message can be empty if you really want a content-free announcement, but most teams say at least one sentence.
8. Create the incident
Click Publish incident (or press ⌘↵). The incident is created and you’re navigated to its workspace. The public status page, the dashboard, and any in-flight AI agent matching pick it up within seconds.
Verify it worked
Open the public status page (https://v3.atender.com/incidents/<your-tenant-slug> or your custom domain). The new incident should appear at the top of the Active Incidents section with the title, severity color, status badge, and the first update.
Creating an active incident does not email subscribers; if you have subscribers, they receive their notification email within a minute or so of the first update you post afterwards. API-created incidents still appear on the public status page and become visible to AI matching, but neither creating an incident nor posting an update through the API sends subscriber notifications.
In the dashboard’s Active Incidents card, the count goes up by one.
Troubleshooting
- Symptom: I clicked Publish incident but nothing happened. Fix: Check the title field — title is required. The form shows a red message if it’s missing.
- Symptom: The incident is created but doesn’t appear on the public page. Fix: Hard-refresh the public page; it’s served with light caching. If the issue persists after a minute, check that you’re on the right tenant slug.
- Symptom: I want to attach a screenshot or log to the incident. Fix: Atender doesn’t support attachments on incidents today. Use plain text in the update body — you can paste URLs to external evidence (e.g., a Sentry trace); they render as clickable links in the incident timeline inside Atender, but as plain text on the public status page.