Publish incidents from Slack
If your team already lives in Slack during an outage, you don’t need to switch tabs to keep the status page current. Designate one channel as your incidents channel, and posting there kicks off a guided flow to publish an incident — with severity, status, and affected components — directly from the message. Reply in the thread afterward and each reply opens the same kind of prompt to post a timestamped update on that incident.
Prerequisites
- Your workspace must already be connected to Slack.
- You need the permission that gates channel settings (
SETTINGS_CHANNELS) to designate or change the incidents channel. Without it, the Slack tab under Incidents Settings won’t appear. - Check Settings → Incidents Settings → General → New incident starts as so your team knows what visibility Slack-created incidents use by default. Slack does not include a visibility picker in the publish prompt: if this setting is Public or Internal, that default is honored; if it is No pre-selection, Slack opens the incident as Internal so a teammate can review it and flip it public later from Atender.
Designate an incidents channel
- Go to Settings → Incidents Settings and open the Slack tab.
- Pick a channel from the list of channels your Slack bot belongs to.
- That’s it — the channel is now the tenant’s incidents channel.
A few things to know about this step:
- Only one incidents channel per tenant is allowed. If you pick a different channel later, the previous one is automatically demoted — you don’t need to unset it first.
- If the bot was removed from the currently-designated channel, it still shows up in the picker, labeled “(bot removed)”, so you can see what’s configured and re-invite the bot or pick a replacement.
- The incidents channel is entirely separate from any support channels you’ve connected — support channel configuration (Agent Stack binding, DM surface, etc.) doesn’t apply here, and the incidents channel doesn’t show a Stack selector.
Publish an incident by posting a message
Once a channel is designated, post a normal message in it describing what’s going on — for example, “API returning 500s for a subset of customers since ~14:10 UTC.”
Atender responds with an interactive publish prompt attached to your message, prefilled with AI-suggested values based on what you wrote:
- Status — the opening status for a brand-new incident. Since an incident can’t open already resolved, Resolved isn’t offered here; choose from the earlier lifecycle statuses (see Incident statuses).
- Severity — Minor, Major, or Critical.
- Affected components — with 10 or fewer components, one row per component with a Not affected / Degraded / Unavailable impact select; above 10, a single multi-select of your configured components. Either layout lists them in their configured display order. If your tenant has a very large component list, the select is capped at Slack’s 100-option limit and long component names are trimmed to fit Slack’s label limit — the full name is unaffected anywhere else in the product.
Slack does not ask you to choose whether the incident is Public or Internal. It follows Settings → Incidents Settings → General → New incident starts as instead: Public starts public, Internal starts internal, and No pre-selection starts internal so someone can review and make it public later from the web Incidents module.
You can also publish planned maintenance from Slack. The publish prompt always includes optional Start time and End time datetime pickers; setting a start time is what turns the publish into planned maintenance rather than a live incident. Slack can publish the planned maintenance announcement before the window opens, then add notes in the thread when the maintenance starts or if it overruns.
Review the AI-prefilled suggestion, adjust anything that’s off, and choose:
- Publish incident — creates the incident using the same incident-creation logic as the web Incidents module. Its starting visibility comes from New incident starts as: Public and Internal defaults are honored, while No pre-selection opens the incident as Internal for a teammate to review and flip public later.
- Cancel — discards the draft. Nothing is published.
Publish and Cancel are mutually exclusive: if you (or a teammate) tap Publish, a later Cancel on the same message can no longer undo it, and vice versa — whichever action lands first wins.
If Atender fails to post the publish prompt back to Slack in the first place, the underlying draft is removed rather than left in a stuck state, so re-posting or Slack’s own retry will start a clean flow instead of silently doing nothing.
Turn thread replies into updates
Once an incident is published, keep the conversation going in the same Slack thread. Each reply you post there becomes a gated update on that incident — appended to its timeline the same way an update posted from the web Incidents module would be.
- Update statuses include Resolved, unlike the initial publish step — this is how you close out the incident from Slack.
- The incident’s overall status is mirrored from whatever status your update carries, so posting a “Resolved” update in the thread also resolves the incident record.
Unpublished drafts expire automatically
If a publish prompt is posted but nobody taps Publish or Cancel, the draft doesn’t stick around forever — a background cleanup process removes abandoned drafts after 24 hours. You’ll need to post a new message in the incidents channel to start over.
Limits worth knowing
- One incidents channel per tenant — the server enforces this even if two admins try to set different channels at the same time.
- Affected-components selects show at most 100 components, and individual component labels are truncated to fit Slack’s 75-character option-label limit.
- Long incident descriptions are trimmed to fit under Slack’s block text limits in the prompt itself; the full text is still stored on the incident and shown in full on the status page.