Skip to main content
An incident is an unplanned interruption or degradation of a service — something is broken for users right now, and the goal is to restore service fast. A problem is the underlying cause (or potential cause) of one or more incidents — the goal is to diagnose it and prevent recurrence. In ITIL terms, incident management optimizes for speed of restoration; problem management optimizes for permanent elimination. One incident can surface a problem, and one problem can spawn many incidents.

​
Comparison at a glance

​
What is incident management?

Incident management is the reactive discipline: detect the disruption, mobilize responders, mitigate impact, and restore normal service. Speed dominates every decision — a restart that buys stability is a perfectly good incident resolution even if nobody yet knows why the service crashed. Incidents are closed when users are no longer affected, not when the cause is understood.

​
What is problem management?

Problem management is the investigative discipline that picks up where incidents leave off. It asks why the disruption happened and what will stop it happening again. Its outputs are root cause analyses, permanent fixes, and known error records — documented causes with proven workarounds that make the next incident faster to resolve even before the permanent fix ships. Problem management can also be proactive: analyzing incident trends or vendor advisories to remove causes before they ever produce an incident.

​
Can an incident exist without a problem?

Yes. A one-off disruption with a fully understood, already-remediated cause — say, a bad config push that was rolled back and now has a validation check preventing recurrence — needs no separate problem record. Problems earn their overhead when the cause is unknown, the fix is nontrivial, or the incident keeps coming back. Likewise, a problem can exist without any incident: if a vendor discloses a defect in a library you run, you can open a problem and fix it proactively before it bites.

​
Worked example

Over three weeks, a team logs four incidents: the checkout service runs out of memory and restarts, each time causing 5–10 minutes of failed payments. Each incident is resolved the same way — the on-call engineer restarts the pods and confirms recovery. MTTR is good; users barely notice. But the fourth recurrence makes the pattern undeniable, so the team opens a problem record. The problem investigation takes eight days: a heap analysis reveals a slow memory leak in a session-caching library introduced in a March upgrade. The team documents the known error (“leak in cache library ≥ v4.2; workaround: rolling restart”) so any future incident resolves in two minutes instead of ten, then ships the permanent fix — pinning the patched library version and adding a memory-growth alert. The four incidents were each resolved in minutes; the problem took over a week — and eliminated the entire incident class.

​
Why keep them as separate processes?

Because their incentives conflict. Incident response rewards the fastest path to restoration, which is usually a workaround; root-causing during an outage prolongs user pain. Problem investigation rewards depth and patience, which you can’t have at 3 a.m. with revenue burning. Merging them either slows your incident response (“don’t close it until we know the root cause”) or guts your investigations (“it’s back up, move on”). Link them instead: incidents reference the problems they revealed, and problems track the incidents they caused.

​
How this works in Rootly

Rootly tracks each incident as a structured record with a timeline, severity, and linked follow-up actions, so recurring incidents and their underlying causes stay connected. See Incident Management.