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 (Acknowledged) – the on-call sees the incident and takes responsibility.
Assessing (Verified) – the team confirms this is a real incident and begins diagnosis.
Fixing → Resolved (Resolution) – engineers actively work to restore service (Fixing) and mark it as Resolved once the system is back up.
Pending Mitigation – after resolution, follow-up items from the RCA are tracked here until they’re completed.
Closed – once mitigations are done, 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.
Finalized – the RCA is documented, agreed upon, 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.
Impacted Product – the primary product, service, or platform most affected.
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 resolve). 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 Resolve = Creation → Resolved
These timings are important because they let your team see how quickly you detect, respond to, and fix issues over time.
🧭 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.