Two clocks run on every GLPI ticket that has an SLA attached. Most administrators configure only one of them, leaving the other at defaults -- and then wonder why their SLA reports look wrong. Understanding the difference between TTO and TTR, and configuring both correctly, is the foundation of meaningful SLA management in GLPI.
TTO and TTR: two separate clocks
GLPI tracks two SLA metrics per ticket:
- TTO (Time to Own) -- the clock starts when the ticket is created and stops when a technician takes ownership (status changes from "New" to "Processing (assigned)"). This measures response time
- TTR (Time to Resolve) -- the clock starts when the ticket is created and stops when the ticket is solved or closed. This measures total resolution time
Both clocks are configured independently. A P1 incident might have a TTO of 15 minutes (someone must acknowledge it within 15 minutes) and a TTR of 4 hours (it must be resolved within 4 hours).
Configuring SLA levels
Navigate to Setup > SLAs in GLPI. Create SLA levels that match your service commitments. A typical structure:
- P1 (Critical): TTO = 15 min, TTR = 4 hours
- P2 (High): TTO = 30 min, TTR = 8 hours
- P3 (Medium): TTO = 2 hours, TTR = 24 hours
- P4 (Low): TTO = 4 hours, TTR = 72 hours
Each SLA is then linked to tickets via business rules. The most common approach: a rule that matches on priority and assigns the corresponding SLA automatically.
Business hour calendars
SLA clocks should only tick during working hours. GLPI supports calendar definitions under Setup > Calendars. Define your work schedule (e.g., Monday-Friday, 08:00-17:00) and add public holidays. Assign the calendar to each SLA.
Without a calendar, SLA clocks run 24/7. A ticket opened Friday at 16:30 with a 4-hour TTR would breach at 20:30 Friday night -- even though nobody is working. With a business hours calendar, the 4 hours resume Monday at 08:00.
For organizations operating across time zones, create separate calendars per region and assign them via entity-level SLA configuration.
Escalation rules
Escalation happens when an SLA clock approaches or exceeds its target. GLPI allows multiple escalation actions per SLA level:
- At 75% of TTO: send a notification to the assigned group
- At 100% of TTO: reassign to a senior technician and notify the service manager
- At 50% of TTR: add a watcher (the team lead)
- At 100% of TTR: escalate priority and notify the IT director
Escalation levels are defined as percentages or fixed time intervals before or after the SLA target. Stack multiple levels to create a graduated response.
SLA pause states
When a ticket is waiting for user input (status: "Pending"), the SLA clock should stop. GLPI handles this natively -- pending status pauses both TTO and TTR clocks. The clock resumes when the user responds and the ticket returns to processing status. Make sure your team uses the correct status transitions; a ticket left in "Processing" while actually waiting for a user reply burns SLA time unnecessarily.
The one-SLA-for-everything mistake
The most common SLA configuration error: creating a single SLA and applying it to all tickets regardless of priority or category. This makes SLA reporting meaningless because a password reset and a server outage get measured against the same target. Differentiate SLAs by priority at minimum. For mature organizations, consider category-specific SLAs (network issues might have tighter targets than software requests) using business rules that match on both priority and category.