Incident or Problem? An ITIL Decision Tool
Answer five quick questions about what's in front of you and get an ITIL-aligned verdict — Incident, Problem, or both — with the reasoning, so you can defend the call in the stand-up.
- Instant verdict
- ITIL-aligned
- Private by design
An Incident is an unplanned interruption or reduction in quality of a service: the goal is to restore service fast. A Problem is the cause, or potential cause, of one or more Incidents: the goal is to remove the root cause. If tills are down across your Dubai stores, log an Incident and restore first, then raise a linked Problem if the cause is unknown or it has happened before.
Describe what's in front of you
Five quick questions. The verdict updates as you answer — nothing is saved or sent anywhere.
Answer the questions above — the verdict updates as you go.
Why this matters
- Wrong call, wrong queue. Logging a Problem while service is still down slows the fix — restore first, investigate after.
- Right call, fewer repeats. Closing Incidents without a linked Problem is how the same outage comes back every quarter.
- Use it in triage. Run a live Major Incident through this alongside the downtime cost calculator to justify a Major Problem Review on the spot.
- It's a starting point, not a ruling. Use judgement — a low-impact one-off can still be worth a Problem record if it touches a fragile system.
Method & ownership
A short decision tree over ITIL's core distinction: an Incident restores service, a Problem removes the cause. It weighs whether service is disrupted now, whether the fault is recurring, whether root cause is known, what the immediate goal is, and business impact.
The formulas used here are standard, published methods. The implementation, interface, wording, findings logic and benchmark figures are original work by ITSM Compass. Results are estimates, not professional advice. See the terms of use.
© 2026 ITSM Compass. All rights reserved.
Questions
What's the ITIL difference between an Incident and a Problem?
An Incident is an unplanned interruption or reduction in quality of a service — the goal is to restore service fast. A Problem is the cause (or potential cause) of one or more Incidents — the goal is to find and remove the root cause, or reduce its impact if it can't be removed.
Do I always need a Problem record when I don't know the root cause?
Not always. A genuine one-off with low business impact is often fine to monitor. Raise a Problem record when the same fault could recur, when a workaround is standing in for a fix, or when the business impact is high enough that not knowing is itself a risk.
What's the difference between a Reactive and a Proactive Problem?
A Reactive Problem starts from Incidents that have already happened — you're investigating a fault after it recurred. A Proactive Problem starts from analysis — spotting a trend, a risk or a near-miss before it becomes a pattern of Incidents.
Can a Major Incident skip straight to a Problem review?
Yes. High-impact Incidents often justify a Major Problem Review even after a single occurrence, rather than waiting for a repeat — the cost of a second failure is too high to accept.
Need Problem Management embedded properly?
Advisory sessions that set up recurring-incident triage, Major Problem Review and the metrics that keep it running.