You can create Incidents either directly in Jira or from Slack. We encourage you and your team to use whichever method is most convenient. However, best practices suggest your teams should put as much information as possible in Incidents to help the engineering team resolve the issue as fast as possible.
Typically, this means you need to:
Have a clear summary about what is not working as expected
To the best of your ability select the Primary Product being affected. You can add any other affected products later.
Add a clear description of how to replicate the issue you found.
Add screenshots if applicable.
If your organization uses multiple Severity levels, use your best effort to choose the correct level.
📝 Create an Incident in Jira
To create an incident in Jira, simply click the Create button in Jira as you would for any work item:
Select the Incident project your company uses: typically this will be Incidents or Phoenix Incidents.
Enter in as many details as you can in Summary and Description. Add screenshots.
Primary Product, select the single product most impacted by this incident — this also represents what caused it. Pick one; if several products are affected you can either choose a broad product like "Platform" (we recommend every company have one for wide-ranging incidents) or just pick the most affected and add the others later. This determines which team gets paged in your paging system, and you can change it at any time.
Severity. If your company has set up multiple Severity levels, use your best effort to select the correct Severity level.
Optional: If you know when the outage actually began, you can select the Incident Start date and time. If you don't the current time will be automatically set for you.
Press Create.
💬 Incident Creation from Slack
To create an Incident from Slack, in any channel, simply type the slash command:
/phoenix create
This will bring up a modal for you to enter:
Primary Product. Select the single product most affected — this also represents what caused the incident, and determines which team gets paged. Pick one; if several products are affected, choose a broad product like "Platform" or just the most affected one and add the rest later. You can change it at any time.
Incident Severity. If your company uses multiple Severity levels, you will need to select the Severity of this incident.
Summary. Enter a summary of the issue - it is recommended to be as clear as possible.
Description. Enter a clear description of what the incident is and how to reproduce it.
At creation you pick a single primary impacted product, which determines who gets paged. If more products turn out to be affected, you can add them to the incident later, and they are captured in the RCA.
🎯 Recommendation
Since there are limited options in Slack, we recommend you goto Jira afterwards and add in screenshots and more details into the newly created Incident to help the engineering.
💬 Other Slack commands
Once an incident is running, two more commands help you keep everyone informed from its Slack channel:
/phoenix update– post a status update to the incident's channel./phoenix recap– get an AI-generated recap of what has happened in the incident so far, which is handy when someone new joins.
📆 How We Handle Dates
Incident Start. If you know when the incident/outage actually started from you can select the correct date/time when you create the incident in Jira. If you don't the system automatically sets the current time for you.
Incident End. If you use the Monitoring phase, Phoenix sets this automatically when the incident moves to Monitoring. If you don't, you set it when you resolve the incident, and in Slack it defaults to the current time. You can change it later, just like Incident Start.
Both Incident Start and Incident End dates can be modified during the RCA, once you have collected more information. It is important to be as accurate as possible with both, as these times are used to generate several metrics for the Incident and RCA.