Incident management restores a broken service as quickly as possible. Problem management finds and removes the underlying cause so the same incident doesn't happen again. ITIL defines an incident as an unplanned interruption to an IT service or a reduction in its quality, and a problem as a cause, or potential cause, of one or more incidents. Atlassian gives the clearest example: rolling back a recent deploy may end the incident, but the underlying problem remains.
If you run an online business, a SaaS product or an IT team for clients, you'll have felt this. The site goes down, everyone scrambles, it comes back, and then nobody looks at why until it happens again. That gap is exactly what separates incident management from problem management.
Incident vs problem management at a glance
| Incident management | Problem management | |
|---|---|---|
| Goal | Restore the service to its normal state | Find and eliminate the root cause |
| Starts when | Something is disrupted or degraded | An incident happens, or a risk is spotted before one does |
| Speed | Urgent, often an emergency response | Investigative, can run between incidents |
| Ends when | The affected service works as intended again | The problem is eliminated and can't cause another incident |
| Typical output | A fix or workaround, and a record of what happened | Root cause analysis, a known error record, a permanent fix |
What incident management covers
Atlassian describes incident management as the process development and IT operations teams use to respond to an unplanned event or service interruption and restore the service to its operational state. It says an incident is resolved when the affected service resumes functioning in its intended state, and that the work includes only the tasks needed to limit the impact and restore functionality.
Incidents range widely. Atlassian's examples run from an entire global web service crashing to a small number of users hitting intermittent errors. Its best practice advice is to define your severity and priority levels before an incident happens, so whoever is in charge can judge priority quickly.
What problem management covers
Atlassian calls problem management a practice for analysing incidents, finding root causes and putting long term fixes or workarounds in place. It makes a sharp observation: the immediate cause of an incident is often dry and unhelpful, such as a rewritten config file or a corrupted database entry. The useful questions are about the conditions that let that happen.
Atlassian lists these main steps in a problem management process:
- Problem detection: find problems proactively, so they can be fixed or worked around before future incidents.
- Categorisation and prioritisation: track and assess known problems so the team works on the most valuable ones.
- Investigation and diagnosis: identify the underlying contributing causes and the best course of action to fix them.
- Create a known error record: ITIL defines a known error as a problem with a documented root cause and a workaround, usually kept in a known error database.
- Create a workaround if needed: a temporary solution that reduces the impact of a problem and stops it becoming an incident.
- Resolve and close the problem: a closed problem has been eliminated and can no longer cause another incident.
A simple example
Your booking page stops loading on a Friday afternoon. Incident management kicks in: someone is alerted, the team rolls back that morning's update, and bookings work again within the hour. The incident is resolved. On Monday, problem management asks why the update broke the page, discovers a missing test for one browser, adds the test and records the issue as a known error with its workaround. The next update can't cause the same outage.
Why the two get blurred
Atlassian notes that until ITIL V3 in 2007, incidents and service requests were lumped together as incidents. It also says problem management and incident management practices are becoming increasingly intertwined, and it argues for bringing them closer together. Its warning is worth taking to heart: root causes are often not investigated until long after the incident, and for some teams the problem backlog is where problem issues go to die.
The fix Atlassian suggests is cultural as much as procedural. When problem management runs as a heavy, separate process, the problem team can become a bottleneck or focus on the wrong things. When teams keep investigating and learning from incidents as part of normal work, they ship improvements that stop repeat outages. For a small business, that simply means the people who fixed the incident also own the follow up.
Detection comes first, as our observability versus monitoring guide explains.
How to set this up in a small team
- Agree what counts as an incident and write down two or three severity levels.
- Name who's on call, even if it's a rota of two people.
- After every significant incident, open a problem record before everyone moves on.
- Keep a simple known error list with the workaround for each, so the next person doesn't start from scratch.
- Review open problems regularly, between incidents, when there's time to think.
One tooling change worth knowing: Atlassian says Opsgenie's alerting and on call features are now available in Jira Service Management and Compass, so if you're reading older guides that recommend Opsgenie on its own, check the current setup.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
I've compared the best incident management software for IT teams if you're choosing a tool. For on call alerting specifically, here are some PagerDuty alternatives worth a look.
My verdict
Incident management gets you back online. Problem management keeps you from going down the same way twice. Many small teams are decent at the first and skip the second, which is why the same outage keeps coming back. Make one rule: no significant incident is closed until a problem record exists. It costs an hour and saves you the next Friday afternoon.
The teams involved are described in our help desk versus service desk guide.
Frequently asked questions
What is the difference between incident and problem management?
Incident management restores a service quickly after a disruption. Problem management finds and removes the root cause so the incident doesn't happen again.
How does ITIL define an incident?
ITIL defines an incident as an unplanned interruption to an IT service or a reduction in the quality of an IT service.
How does ITIL define a problem?
ITIL defines a problem as a cause, or potential cause, of one or more incidents.
What is a known error?
In ITIL, a known error is a problem that has a documented root cause and a workaround, usually stored in a known error database.
When is an incident resolved?
Atlassian says an incident is resolved when the affected service resumes functioning in its intended state.
