In modern practice, an Incident is an unplanned outage or service degradation that requires urgent attention from your engineering team.
Contrast this with defects or routine bugs, which usually don’t meet this bar. Bugs can be prioritized in backlog grooming or fixed in the next sprint. An Incident, on the other hand, spins up an entire process—people are paged, notifications go out in Slack, and there’s immediate visibility across the organization.
Creating an Incident is a serious step. You should not hesitate to create one when something clearly requires urgent attention—but you should also understand what this sets in motion.
🔄 The Incident Lifecycle
When an Incident is created, it moves through a defined set of Jira statuses. These aren’t just labels—they correspond to real phases of the incident process:
New – the incident has just been created and the on-call is notified.
Assessing – the on-call has acknowledged the incident and is evaluating its scope and impact.
Fixing – the team has verified this is a real incident and is actively working to restore service.
Monitoring – an optional step. The fix has been deployed and the team is watching to confirm the system stays stable.
Resolved – service is back up. The incident now awaits RCA completion.
Canceled – the incident turned out to be a false alarm.
Pending Mitigation – the incident is resolved, but follow-up action items from the RCA are still open.
Closed – all mitigations are done and the incident is fully closed.
In parallel, incidents also require a Postmortem (RCA), which goes through its own statuses:
Data Gathering – evidence, logs, and timelines are collected.
Analysis Meeting – stakeholders meet to review what happened and why.
Under Review – the documented RCA is reviewed and agreed upon by stakeholders.
Finalized – the RCA is complete and shared.
That’s why incidents carry weight—they create urgency in the moment and accountability afterward, ensuring teams don’t just fix symptoms but address the root cause.
📚 Anatomy of an Incident
Every Incident has a few key parts that should be filled out when you create one:
Summary – a concise statement of what is not working as expected.
Description – details about the impact, steps to reproduce, or other context.
Primary Product – the product, service, or platform most affected, which also represents what caused the incident. This determines which team is paged, and you can change it at any time. As you learn more, add every other affected product to the incident's Impacted Products list — on the incident or during the RCA.
Severity – how bad is it? Many companies use a SEV1–SEV5 scale.
Incident Start (Optional) – if you know when the outage actually began.
For step-by-step instructions, see How to Create an Incident
📈 Timing and Metrics
Incidents track several timestamps that feed into metrics like MTTD (mean time to detect), MTTA (mean time to acknowledge) and MTTR (mean time to recover). Here’s what they mean:
Creation Date – when the Incident record was created.
Incident Start – when the outage actually began. If unknown, defaults to Creation.
Acknowledged (status = Assessing) – when someone first took responsibility.
Verified (status = Fixing) – when the team confirmed it was a real incident.
Resolved (status = Resolved) – when service was restored.
Closed (status = Closed) – when all follow-up actions are complete.
From these we measure:
Time to Detect = Start → Creation
Time to Acknowledge = Creation → Acknowledged
Time to Verify = Creation → Verified
Time to Recover = Incident Start → Incident End
These timings are important because they let your team see how quickly you detect, respond to, and fix issues over time.
For the full definition of every metric and the timestamps behind it, see Metrics & Definitions.
🧭 When to Create an Incident
If you’re in Customer Support or another front-line role, don’t hesitate to create an Incident when you see something that clearly needs urgent engineering attention. That’s the right thing to do. Just keep in mind: it sets the whole process in motion.
Add as much useful detail as you can—summary, description, impacted product, severity, and screenshots if available. That context helps engineers resolve the issue faster and makes the follow-up phases more accurate.
Note: Many organizations have a clear defined internal process about who and when to create incidents, so you should follow that. Companies with large customer support organizations may have an internal group of "product experts" that coordinate reports and are the only ones in the CS org that create incidents, whilst other companies allow anyone to create an incident. It all depends on the specifics of your company.