Escalation in ITSM isn't "let the team know an incident has been open a while". It's a predefined, programmed sequence of actions that GLPI executes automatically when an incident isn't progressing against its SLA. Without escalation rules an SLA is just a date in the database. With them, the SLA is a process that keeps working when the technician is at lunch, in a meeting, or on holiday.
What actually escalates in GLPI
GLPI ships two mechanisms:
- SLA actions (Setup → Service levels → SLA → Action). When you create an SLA, you define actions that fire at a moment relative to the deadline: X minutes before, at the moment of breach, X minutes after. Actions can be: change priority, change urgency/impact, add an observer, change the assigned group, send an email notification.
- OLA actions (Operational Level Agreement) — same mechanism but for internal hand-off targets between teams (e.g. L1 ↔ L2 hand-off in 30 min), not for customer-facing SLAs.
Both SLA and OLA come in two flavours: Time to own (TTO — how fast someone must take ownership) and Time to resolve (TTR — how fast it must be resolved).
A practical escalation matrix
An example for a mid-sized company running 24/7 support for critical systems:
Priority 1 (P1) — critical (ERP, email, finance system down)
TTO: 15 min | TTR: 4 hours
-10 min: notify L1 technician (email + SMS)
-5 min: notify L1 team lead
T0: reassign to L2 group (escalation team)
+15 min: notify IT manager
+30 min: notify CIO
+1 hour: notify CEO (if ERP is down)
Priority 2 (P2) — high (partial outage, one team blocked)
TTO: 1 hour | TTR: 8 hours
-30 min: notify L1 technician
T0: notify team lead
+1 hour: reassign to L2 + notify IT manager
Priority 3 (P3) — normal (single user, workaround exists)
TTO: 4 hours | TTR: 2 days
T0: notify L1 technician
+4 hours: notify team lead (if no progress)
Priority 4 (P4) — low (cosmetic, nice-to-have)
TTO: 8 hours | TTR: 5 days
T0: notify technician (no escalation)
The matrix is configured once in Setup → Service levels, attached to the SLA via a business rule (category + entity = which SLA applies), and from then on GLPI escalates automatically.
UI configuration
- In Setup → Service levels → SLA create an SLA "P1 — critical (4h TTR)".
- On the SLA detail page, the SLA actions tab, click + Add.
- Pick the action type (for example "Add a recipient" for a notification, or "Modify ticket properties" to change a group).
- Set the time offset (relative to the deadline: before, during, after).
- Repeat for each step in the matrix.
To assign the SLA automatically, use a business rule under Administration → Rules → Rules for ticket assignment: IF urgency = Very high AND impact = Major → SET SLA_TTR = "P1 — critical".
Notification escalation
Notifications are configured in Setup → Notifications → Notifications → Add. For each level of the matrix, create a separate notification with the precise recipient group and a specific template — a generic "escalation notice" email is worse than no email, because the manager will tune it out.
Practical tips:
- Send P1 notifications via SMS or Slack/Teams in addition to email — nobody reads email at 3am. Notification integrations via webhook to a #incidents channel in Teams is by far the most effective channel.
- Escalate the recipient set, don't just swap levels — at each escalation add another person, don't drop the previous one. That way the technician knows the manager has been pulled in, and the manager sees the whole chain.
- Define working hours in a calendar (Setup → Dropdowns → Calendars). A "4 hours" SLA at night with 24/7 cover means something very different from a 4-hour SLA in working hours.
Reporting on escalations
The GLPI dashboard or the built-in report builder can surface: percentage of tickets escalated, average time to first escalation, most-escalated categories, and technicians with the highest escalation ratio. The IT manager should read this report weekly — if a category has an 80% escalation rate, either its SLA is wrong or there's not enough capacity.
The escalation system in GLPI is not a "nice to have" feature — it's the backbone of a working service desk. Without it the SLA is marketing copy. With it, the SLA becomes something measurable and enforceable.