Incident vs Problem Management
Incident management restores service as fast as possible, accepting a workaround. Problem management investigates why the incident happened and removes the underlying cause, on a longer timescale. They have different clocks, different success criteria, and should be different records, because the work that ends an outage is rarely the work that prevents it.
The two clocks
An incident is a clock. Something is broken, users are affected, and every minute costs something. The correct behaviour is to restore service by whatever legitimate means is fastest: fail over, roll back, reroute, restart, disable the feature flag. Understanding the failure is not the objective, and insisting on understanding it first is how a twenty minute outage becomes a three hour one.
A problem is a hypothesis. Something in the system permits a class of failure, and the work is to find it, confirm it, and remove it. That work does not fit in an outage window. It needs the logs preserved, the timeline reconstructed, someone who can read the relevant code or configuration, and usually a change that has to be planned and tested.
The practical consequence: a rollback that restores service resolves the incident and tells you almost nothing about the problem. A configuration that was wrong for six weeks and only failed under load is not explained by the deploy that exposed it. Closing the incident as resolved by rollback, with no problem record, guarantees the same failure returns.
Why the same queue does not work
Both kinds of work compete for the same engineers. If they share a queue and an urgency model, incidents win every time, because an incident has users waiting and a problem has only a future cost. This is not a discipline failure, it is what happens when you rank a certain cost now against an uncertain cost later. The separation exists so problem work can be scheduled and defended rather than perpetually preempted.
How they connect in practice
Workaround closes one and opens the other. When an incident is resolved by a workaround rather than a fix, that is the signal to open or update a problem record. Making this explicit in the tool matters: if the only available close reason is resolved, the distinction disappears into the data.
Many incidents, one problem. The value of a problem record comes from what links to it. Five incidents against one problem is a concrete argument for engineering time, in a currency the business already understands, because each linked incident carries its own duration and impact. One incident and a strong suspicion is not.
Root cause codes feed the pipeline. Requiring a cause code when a ticket closes turns a pile of prose into a countable distribution. The categories that keep appearing are your problem candidates, and you get them without anyone running an analysis.
Known errors close the loop backwards. Once a problem is understood but not yet fixed, the documented symptom and workaround should be reachable from the next matching incident, so the second responder does not rediscover it at 3am.
Severity is not the same as priority. A severe one-off can be a lower problem priority than a moderate failure that fires weekly. Frequency times impact, not impact alone.
What to check in your own process
Can you count repeat incidents? If you cannot answer how many of last quarter's incidents shared a cause, you do not have problem management, you have postmortems. The link between incident and problem records is what makes the question answerable.
Does a workaround look different from a fix in your data? If not, the recurring failures are invisible and the team will keep being surprised by them.
Is problem work scheduled? Named owner, explicit slot, reviewed. Anything else is a wish list, and it will lose to the next incident.
Is there an exit other than fixed? Some problems are correctly accepted: the cost of removing the cause exceeds the cost of the failures, or the component is being retired. Accepted with rationale and a review date is a legitimate outcome, and an honest one. Without that option, records rot open and the backlog stops being believable.
Are you conflating problem management with the postmortem? A postmortem is a meeting and a document about one incident. Problem management is the ongoing tracking of causes across many. The postmortem is an input.
| Dimension | Incident management | Problem management |
|---|---|---|
| Objective | Restore service now | Remove the cause permanently |
| Clock | Minutes to hours, against an SLA | Days to quarters, against a backlog |
| Acceptable outcome | A workaround that restores service | A change that removes the failure mode |
| Trigger | Service is degraded or down | A pattern across incidents, or one severe incident |
| Success metric | Time to detect and time to restore | Recurrence rate and incidents avoided |
| Who leads | Incident commander on shift | An owning engineer or team, scheduled |
| Typical failure | Slow escalation and unclear ownership | Never prioritised against feature work |
| Record ends when | Service is confirmed restored | The cause is removed or accepted with rationale |
Frequently asked questions
- What is the difference between an incident and a problem?
- An incident is an unplanned interruption or degradation of service, and the goal is restoring service quickly. A problem is the underlying cause that allows incidents to happen, and the goal is removing it. One is measured in time to restore, the other in whether the failure stops recurring.
- Can an incident be closed without finding the root cause?
- Yes, and usually it should be. Restoring service by rollback, failover, or a workaround is the correct incident outcome. What should not happen is closing it with no problem record, because that discards the only signal that the failure mode is still present and will return.
- Should incidents and problems be tracked in the same tool?
- In the same tool, as different record types, linked to each other. Shared tooling keeps the link cheap to maintain. Shared urgency does not work: if problems sit in the incident queue, they are preempted indefinitely, because there are always users waiting on something.
- How do you prioritise problem records?
- By frequency multiplied by impact, not impact alone. A moderate failure occurring weekly usually costs more than a severe one that happened once. The count of linked incidents, each carrying its own duration, is the most defensible input you have when arguing for engineering time.