Incident escalation in GLPI: time-based rules and automatic forwarding

Incident escalation in GLPI: time-based rules and automatic forwarding

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

  1. In Setup → Service levels → SLA create an SLA "P1 — critical (4h TTR)".
  2. On the SLA detail page, the SLA actions tab, click + Add.
  3. Pick the action type (for example "Add a recipient" for a notification, or "Modify ticket properties" to change a group).
  4. Set the time offset (relative to the deadline: before, during, after).
  5. 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.

Need help with this topic?

Get in touch