An incident is an unplanned interruption to a service, or a reduction in its quality. A problem is a cause, or a potential cause, of one or more incidents. A change request is a proposal to add, modify, or remove something that could affect a service. A service request asks for a service action already agreed as normal, and nothing has to have failed.
Four records for one bad afternoon
At fictional Lantern Works, checkout starts returning errors at 14:10. Priya opens one ticket at 14:12 and types "incident / problem / change" in the summary. Buyers can pay again at 14:26. She marks the ticket resolved at 14:40. Finance, who were never down, cannot see the tax report, and someone files that as the same kind of ticket. Collapsing the records makes the dashboard say the cause is fixed because the service came back.
Restore the service
Restoring the service is why an incident is handled, and that can finish before the cause is understood. The service failed at 14:10, the ticket opened at 14:12, the service met its success criterion again at 14:26, and the record was marked resolved at 14:40. Those instants differ. The incident can close while the cause is still in the software.
An incident is a kind of support ticket. The ticket is the tracked request for attention. The incident is the kind of ticket where something failed for the people using the service.
An incident workaround reduces or avoids the impact of this incident without removing the cause. It may restore the service for now. Turning the new tax rule off at 14:22 did that. It can be found before any problem has been analysed. It is not the root cause, and it is not a permanent removal of the cause.
Explain the cause
In this invented case the new tax rule retries the vendor until the vendor refuses everyone. Restoring checkout belongs to the incident. Understanding the retry loop belongs to the problem, which can stay open after 14:26.
When that problem has been analysed and is not yet resolved, it is a known error. Analysis is what distinguishes it. A documented workaround is not what makes it one, and a workaround can be recorded earlier. The known error is the same cause, not a completed fix. It is not the Information Technology Infrastructure Library (ITIL) word "error", which names a flaw or vulnerability that may cause incidents. The root cause is the cause the investigation has settled on, when it has one, and on a known error it can still be only partly identified.
A problem workaround reduces or eliminates the impact when a full resolution is not yet available. "Keep the new tax rule off" can be written on the problem before the problem is a known error. It is not the root cause. A runbook may quote it. The workaround is not the runbook. What is a runbook? keeps those steps apart from the workaround, the known error, and the postmortem.
Propose a modification
"Remove the retry loop in the tax rule" is the change request. The proposal is recorded so the risk can be judged before the change is made. It is not itself the cause, so it is not the problem. Accepting the proposal is not the same as closing the problem.
An emergency change is often how a service is restored. The request is still not the incident. In this invented afternoon the workaround had already restored checkout, so the proposal is the later removal of the loop. If checkout were still down, carrying out that proposal could be what restores it. The proposal and the interruption stay different records.
The change request type is how the change is authorized. A standard change is low-risk, pre-authorized, and fully documented, so it needs no further authorization. A normal change is assessed and authorized before it goes ahead. An emergency change must be introduced as soon as possible, often to restore a service. The words belong to the practice. The type is not the risk grade and not the deployment that carries the change out.
The change request is also not a release and not a deployment. A deployment puts a build into an environment, which is one way a change is carried out, later. Release vs deployment follows that step. The proposal and the act stay separate, because a change can be rejected and a deployment can fail.
Ask for something the service already offers
Finance's contractor needs access to the tax report. That service request starts a service action already agreed as a normal part of delivery. Nothing has to have failed, so this is not an incident. Filing it as one inflates outage counts and pages the wrong people. A standard change, pre-authorized for that kind of request, may be how the request is fulfilled. The request and the change record stay different facts.
| Record | Lantern's invented example | The question it answers |
|---|---|---|
| Incident | Checkout errors, failed at 14:10, restored at 14:26 | How do we restore the service? |
| Incident workaround | Turn the new tax rule off at 14:22 | What avoids the impact before the cause is gone? |
| Problem | The tax rule retries until the vendor refuses everyone | What is causing the incidents? |
| Known error | That problem, once analysed and still unresolved | What have we already analysed? |
| Problem workaround | Keep the new tax rule off | What reduces the impact while resolution waits? |
| Change request | Remove the retry loop | What modification should we approve? |
| Service request | Grant access to the tax report | What ordinary service was asked for? |
What to stop combining
Count incidents for the interruption. Restored, on the service, can differ from resolved, on the record. Count problems for causes, including a known error. A workaround may have been written before that status. Count change requests for proposals. An emergency change can restore a service, and the request is still the proposal. Leave service requests out of the outage list.
Severity vs priority splits impairment, impact, urgency, and the order of work. Bug vs defect vs incident separates a software flaw from harm a running service already suffered. Level 1 (L1), level 2 (L2), and level 3 (L3) support is who holds the ticket while those records are open.
