L1 stands for level 1. Level 1 takes the report, applies a known fix or a runbook, and passes on what it cannot close. L2 stands for level 2. Level 2 investigates further. L3 stands for level 3. Level 3 is specialist depth: a change to the software, a vendor, or the team that builds it. An escalation moves a ticket to a deeper tier, another team, or a manager. An on-call rotation says who answers, not which tier owns the ticket.
Priya is on call. That does not make her level 3.
Saturday night at fictional Lantern Works. An alert fires. Priya is the person holding the pager. The ticket is still with level 1, who follow a runbook, apply a workaround, and pass it on. A manager is told. On Monday the people who change the software pick it up. After checkout is healthy again, someone writes down what happened. A single field called "owner" will remember one of those facts.
The tier is how deep the response goes
A support tier is that depth of response. Level 2 is often the people who operate the application. Organizations draw those boundaries differently, and some add another tier, so the three levels are the usual case rather than a closed list.
The support tier name is the name this organization uses, such as Level 1, L2, or a vendor's own name. The name is not a priority. A tier is not an on-call rotation, which says who is reachable now. It is not a priority, which says how soon a ticket should be worked. Severity vs priority is that queue, and it is separate from impact and urgency as well. The ticket's tier is the tier currently responsible. Moving the ticket does not change how severe the incident is.
The thing being moved is a support ticket. An incident and a service request are kinds of ticket. A problem is not one: it follows a cause across incidents rather than one report. Incident vs problem vs change is which record level 1 should open before anyone argues about the tier.
Escalation hands the ticket on
An escalation can share awareness of a support ticket, or transfer its ownership. It happens at a time. It is not an event in this graph. An event here is an occurrence or a gathering at a time and place. An escalation is not a change of priority and not a change request. Moving from level 1 to level 2 is an escalation, and so is moving to level 3. The from-tier and the to-tier name the support tiers, not priorities. A notice to a manager may name a person instead of a tier. That person is not a support tier.
The runbook, the known error, and the alert
A runbook is a document of steps for operating a service or for handling a known situation, written so a responder can follow it under pressure. Level 1's invented runbook says: if checkout errors mention the tax vendor, keep the new tax rule off, and escalate if errors continue. The runbook may tell the reader to apply a workaround. It is not the workaround, and it is not the known error. A known error is a problem that has been analysed and has not been resolved. A workaround is often recorded with it and is not required for that status. The runbook is the steps a tired person follows. What is a runbook? keeps those steps apart from the known error and from the postmortem. A postmortem is a different document, written after the fact.
An alert is an observation that a stated condition was met and that a person may need to act. It does not by itself establish the cause, the severity, or that an incident has occurred. Several alerts can be one incident, and an alert can be a false signal. An alert is not a log entry. A log entry is a line the software wrote. An alert may be raised because of log entries. Alert raised at is the instant the alert was raised. Mean time to acknowledge runs from that instant until a person acknowledges the alert. Raising the alert is not restoration of the service. DevOps Research and Assessment (DORA) metrics and mean time to restore (MTTR) keeps that acknowledgement mean apart from restore time.
On-call is a rota
An on-call rotation is the schedule of people responsible for answering alerts outside ordinary staffing. Priya's turn is a fact about the rota. Any support tier can be on call, so the rotation is not a tier. It is not an alert and not an incident. It says who responds, not what failed. Not every member of the team is on the rotation.
The postmortem comes after
A postmortem is a document written after an incident, once the service is restored, recording what happened, how the service was restored, what contributed, and what will change. It is not the incident record, not the problem record, and not the runbook. Writing it does not reopen the incident. A meeting about how a sprint went is a different practice and is not this document.
| Question | Record | Invented Saturday |
|---|---|---|
| How deep is the response? | Support tier, under its own name | L1 applies the runbook, L2 investigates, L3 can change the software |
| Who holds the ticket now? | The ticket's tier | It moves by escalation, which is not an event |
| Who is reachable tonight? | On-call rotation | Priya, whatever tier she sits in |
| What should the responder do? | Runbook | Keep the tax rule off, then escalate |
| What already failed? | Incident, maybe preceded by an alert | Checkout errors. The alert's raised time is not the restore |
| What do we write afterwards? | Postmortem | After the service is restored |
Draw the tiers the way the organization actually draws them, and leave room for a vendor's own name and for another level. Store the rota separately, so "Priya is on call" never overwrites "level 3 owns the fix". The names and the Saturday are made up. The split is the part worth keeping.
