An incident in Phoenix Incidents follows a clear path from the moment it's raised to the moment it's closed. Along the way, Phoenix keeps Jira, your chat tool, and your paging provider in sync so everyone is working from the same picture. This article walks through that journey end to end.
🆕 It starts with creation
Anyone can raise an incident from Jira or from Slack with /phoenix create. You give it a summary, an impacted product, and a severity, and Phoenix takes care of the rest. For the step-by-step, see How to Create an Incident.
📟 The right people are paged
Phoenix looks up the impacted product's paging target and pages the on-call through your configured provider: PagerDuty, Opsgenie, VictorOps (Splunk On-Call), or Phoenix Alerts. The connection is two-way, so when someone acknowledges or resolves the page, that status flows back into the incident. See Configure Paging.
💬 A dedicated channel opens
Phoenix creates a dedicated Slack channel for the incident and posts a link in your main incident channel, so responders have one place to coordinate. Two commands help you keep everyone informed:
/phoenix update – post a status update to the incident channel.
/phoenix recap – get an AI-generated recap of what's happened so far, which is handy when someone new joins the response.
Phoenix also posts the incident's status to the channel with buttons to move it forward, so responders can acknowledge, start fixing, resolve, cancel, reopen, or close the incident right from Slack. And to capture a key moment on the record, react to any Slack message with the :watch: emoji and it is added to the incident timeline.
🔄 Status moves through the lifecycle
As the team works the incident, its status moves from New to Assessing, Fixing, optionally Monitoring, and then Resolved. A false alarm can be Canceled. Your severity SLAs drive reminders along the way, so nothing stalls. For what each status means, see Incident Life cycle.
📝 Resolution kicks off the RCA
When the incident moves to Fixing or Resolved, Phoenix automatically creates a linked RCA as a subtask. This is where the team captures the timeline, the root cause, and the action items that prevent a repeat. See Root Cause Analysis / Postmortem.
As you investigate, you can link the changes or deployments that may have contributed under Related Changes/Deployments on the incident, which gives the RCA a head start.
✅ Closing out
An incident isn't fully closed until its action items are complete. Until then it sits in Pending Mitigation. Once everything is addressed, the incident moves to Closed, and its dedicated channel is archived automatically a few days later to keep your workspace tidy.