Problem identification criteria
Clear criteria stop teams debating whether something is “still an incident” or already a problem. Use them so investigation effort goes where it reduces future disruption, not into every ticket that feels hard.
Incident first, problem when the cause matters
An incident is about restoring service. A problem is the cause, or potential cause, of one or more incidents. Keep restoring users while the incident is open. Raise a problem when you need structured work on the underlying cause — including when you only suspect one and need to investigate further.
Do not wait for a perfect root cause before logging a problem. A problem record can start with symptoms, linked incidents, and a hypothesis. Root cause and workaround develop as investigation progresses. A known error is a later state: documented cause plus a workaround others can use.
When to raise a problem record
Organisations should agree these triggers in advance so the handoff from incident or trend review is consistent. Raise a problem when one or more of the following apply.
Recurring incidents
The same or clearly related incidents keep returning after restoration. Volume, frequency, or pattern (same CI, same failure mode, same time window) shows restoration alone is not enough. Link the incidents to the problem so analysis has evidence, not anecdotes.
Significant single incident
One incident caused major business, regulatory, or reputational harm — or nearly did. Even if it has not recurred, the organisation needs to understand why it happened and what would prevent a repeat. Major incidents almost always warrant a problem or a linked investigation track once service is restored.
Suspected underlying cause
Responders restored service with a workaround, reboot, failover, or temporary config, but believe a deeper defect, capacity limit, or design issue remains. Logging a problem makes that suspicion visible and owned, instead of leaving it in an incident note that nobody picks up.
Known error candidate
You already understand enough to document a reliable workaround, or you expect the fix to take time (vendor patch, design change, capacity project). Capture symptoms, cause (or best current understanding), and workaround so the service desk and support teams can resolve faster while a lasting fix is planned through change.
Proactive from trends
Monitoring, capacity reports, post-incident reviews, or incident trend analysis show rising risk before users feel a major outage — error rates climbing, pool saturation warnings, repeat alerts on the same component. Problem management can start from those signals, not only from a pile of closed tickets.
When to keep work inside the incident
Stay on the incident when:
- service is still impaired and the immediate job is restoration or communication
- the cause is already clear, the fix is simple, and recurrence risk is negligible
- you are still gathering facts for triage and do not yet have a pattern, significance, or suspected underlying cause worth tracking separately
- the item is a service request or how-to enquiry, not an unplanned interruption or quality reduction
If in doubt after a significant or repeat event, raise the problem and refine it. An empty investigation queue helps nobody; a backlog of vague problems with no owner helps nobody either. Prefer fewer, well-owned problems with linked evidence over a problem raised for every priority 1.
What good looks like
- incident and problem records stay distinct: restore on the incident; investigate cause on the problem
- linked incidents and evidence are attached early so analysis is not restarted from scratch
- each problem has a named owner and a next review date, even while cause is unknown
- workarounds are written for operators, not only engineers, and become known errors when cause and workaround are solid enough to share
- lasting fixes go through change enablement; the problem tracks whether the change actually removed the cause