Setting up SLAs and OLAs in GLPI for measurable service desk targets
An SLA in GLPI sets the response and resolution targets you promise customers, and an OLA sets the internal targets a team or group commits to in order to meet them. Teams need both when service targets exist in a document but tickets are not timed the same way across entities, categories or support groups, so nobody can tell whether a breach happened or who caused it. Without a configured SLA or OLA, GLPI cannot show whether a ticket met its targets, so the first job is to decide which commitments need to be measured inside the tool rather than in a spreadsheet.
A customer-facing SLA is the commitment a requester or business unit sees, usually tied to a category, priority or contract. An OLA is internal: it describes how long a first-line group, a second-line team or a supplier has to hand work on, and it is the place to show where time was lost. Your planning should list each target, its owner, the working hours that apply to it and the ticket status that legitimately pauses the clock. Confirm with your own service owners whether a single SLA can carry both the time to first response (TTO) and the time to resolution (TTR), or whether you need separate definitions for each, and check that the calendars you plan to use match your support hours in the GLPI version you run.
Before you rely on the figures, run a test set of tickets through each target and read the results in ticket statistics. Check that a ticket set to pending stops the clock as you expect and that a ticket in the wrong entity does not pick up the wrong target. A partner can help define the target model and test cases, but the threshold values and the reporting rules are business decisions your leadership must approve in writing before go-live.
Which SLA and OLA configuration fits which service desk
This table compares the main ways to model SLA and OLA targets in GLPI, from a single priority-based SLA to separate TTO and TTR targets, calendar-based clocks and internal OLAs for groups. Read each row for when the option fits and how much configuration effort it adds, then confirm entity and group behavior in your own GLPI version before you commit.
| Option | When it fits | Configuration effort | What to confirm first |
|---|---|---|---|
| One SLA per priority, TTR only | Small service desk with one customer group and a simple response expectation for each priority level | Low: one SLA definition per priority, one assignment rule to attach it to tickets | How your version applies the SLA when a ticket has no matching priority or category |
| Separate TTO and TTR targets | Teams that must acknowledge tickets quickly but allow longer time to resolve, such as a 24x7 intake with business-hours fixes | Medium: two targets per SLA, plus tests to confirm both clocks start and stop at the right statuses | Which ticket status starts and stops each target in your version |
| Calendar-based targets | Services with defined working hours, regional holidays or support windows that differ by site | Medium to high: calendars need to be built, assigned to entities and checked against holiday and exception dates | Whether the calendar attaches at SLA or entity level, and how overlapping calendars are resolved |
| 24x7 targets | Critical services, infrastructure incidents or customers who expect continuous coverage | Low to medium: fewer calendar rules, but staffing and escalation design carry more of the workload | That the targets reflect the staffing you actually run, not only the contractual wording |
| Pending status pauses the clock | Tickets that regularly wait on a customer reply, a third-party vendor or a change window | Medium: the pending workflow must be agreed with users and reflected in status discipline | Which statuses pause the clock in your version and whether pause time appears in statistics |
| OLAs for internal groups | Multi-team handoffs where first-line, second-line or specialist groups carry internal response targets | High: each group needs its own OLA, calendar and assignment logic, and reporting must be tested per group | How group-managed OLAs behave in your version and whether they are reported separately from the customer SLA |
| Single SLA for the customer, separate OLAs per team | Organizations that need customer-facing commitments to stay stable while internal handoffs are measured | High: two levels of targets to design, maintain and report on as the service model changes | How multiple OLAs on one ticket are presented and reported in your version |
Configuring SLA and OLA objects step by step
This sequence takes a GLPI service desk from empty calendars to tested SLA and OLA objects, so every new ticket receives correct response and resolution deadlines before it reaches a technician.
Define business hours and holidays
Start by creating the calendars your service levels depend on, including working hours for each support team and the public holidays that should pause the clock. Your service owner or operations lead should confirm the hours with the teams that will be measured, since every later target inherits them. Check that each calendar saves with the days and hours you expect, and that the holiday list covers the dates you agreed. Confirm the exact menu location in your GLPI version, because labels change between releases.
Create the SLA objects for customers
Create one SLA object for each customer-facing commitment, and attach the calendar you defined in the previous step. Keep the names tied to the service promise so reports stay readable for auditors and managers. Save each SLA without targets first, then confirm it appears in the list of available SLAs. This step produces the customer commitments that OLAs will later support.
Create the OLA objects for internal teams
Create OLA objects for each internal group that contributes to a ticket, such as first line, second line or a third-party provider. Assign the calendar that matches the group's real working pattern, which may differ from the customer calendar. Review the list afterward and confirm each OLA is linked to the correct group and calendar. Internal targets are easier to get wrong than customer targets, so check them against the team's rota before continuing.
Set TTO and TTR targets per priority
Within each SLA and OLA, set time to own (TTO) and time to resolve (TTR) targets for every priority level your service desk uses. Only use priorities that appear in your priority matrix, and leave unused levels out so they cannot be selected by mistake. Record the agreed values in a sheet beside the configuration so you can compare them with what GLPI calculates. Once saved, open one object and confirm each priority shows the target you agreed.
Attach SLAs and OLAs through rules or templates
Decide how each ticket receives its objects. Business rules can assign an SLA based on category, entity or requester, while ticket templates can preset the SLA fields for a request type. Keep the logic in one place where possible, and confirm the rule order so a broader rule does not overwrite a more specific one. Verify the assignment by creating a ticket that should match each rule and checking that the correct SLA and OLA appear on it.
Test with sample tickets
Create sample tickets at each priority, in each category and entity that uses an SLA, and record the start time, expected TTO and TTR deadlines. Confirm that each ticket shows the deadline you calculated by hand. Then put one ticket into pending status and confirm the deadline stops moving until the status changes back. Use test tickets clearly labeled as tests, and delete them or close them once the results are recorded.
Check compliance in ticket statistics
Close a few test tickets, some within target and one deliberately late, then open the ticket statistics to confirm they are counted as expected. Check that the pending time and the holiday adjustment appear in the figures. Document the results and the configuration version so a later change can be compared against a known baseline. The step is complete when the statistics match your recorded expectations for every test case.
Where SLA clocks go wrong with pending and reopened tickets
Most SLA reporting problems in GLPI do not come from the engine itself. They come from status choices, calendars, OLA lengths and manual edits that quietly change when the clock starts, pauses or resets. Each risk below shows the symptom to look for in ticket statistics and the configuration check that prevents it.
Pending status without a policy
Agents set tickets to pending to wait on a customer, a vendor or an internal team, and the time spent there can stop the clock. If nobody has defined when pending is allowed and who may use it, targets look met while tickets sit idle. Check who can set pending, require a reason in the follow-up, and review pending durations each week in the ticket statistics before trusting any compliance figure.
Calendars that miss staffed hours
An SLA measured against a calendar that does not match the team's staffed hours counts time nobody was working, or skips time the team was on call. Symptoms include breaches clustered at the start of shifts or on public holidays. Confirm the calendar's working hours, holidays and time zone against the rota, then test a ticket opened at the edge of each shift to see when its target date is calculated.
OLAs longer than the customer SLA
An OLA that allows more time than the customer SLA it supports means the customer target can be breached before the internal team is even late. This is easy to miss because each OLA looks reasonable on its own. Compare every OLA's time to take into account and time to resolve against the SLA it feeds, and make the internal target shorter by a margin you can justify to the service owner.
Reopened tickets restarting targets
When a solved ticket is reopened, its SLA can start again from zero, which makes a repeat failure look like a new incident and hides real resolution delays. Decide whether a reopen should restart the clock, keep the original start, or open a new ticket, and document that choice. Test a reopen in a staging entity and confirm the resulting dates before the rule goes live.
Manual priority overrides
When an agent edits urgency or impact by hand after the SLA is attached, the priority can change the target that applies, sometimes without a visible record of the reason. The result is SLAs that look compliant because the priority was lowered late in the ticket life. Restrict who can override priority, keep a ticket template or business rule as the default source, and audit tickets where priority changed after creation.
Checking SLA compliance in ticket statistics
Ticket statistics are the place to confirm that your SLAs and OLAs are being met, not just configured. Once targets are calculated on tickets, the statistics view lets you break compliance down by entity, group and priority, so you can see whether a breach is a one-off or a pattern. Start by filtering to a closed period and grouping by the entity that owns the SLA, then by the assigned group. A cluster of late resolutions under one group usually points to an OLA that was set too tightly or a calendar that does not match the team's working hours, while breaches concentrated in one priority often mean the priority matrix is assigning levels in a way the business did not intend. Confirm which statistics widgets and filters your GLPI version exposes, and which profile rights your reviewers hold, before you build a reporting routine around them.
Run a monthly review and pair it with a sample-based check of the timeline. A standing monthly review should cover the breached tickets, the tickets that stayed in pending status for long periods, and any SLA that reached its target only because of a status change. For the sample, pick a small set of tickets from each priority and entity, open each one, and compare the ticket history (creation, first assignment, first response, pending periods and solution) with the TTO and TTR deadlines GLPI calculated. The aim is to confirm that the calendar, the start date and the pending pauses were applied the way your documented rules describe. Record the outcome of each sample so that a discrepancy can be traced to a configuration change or to a user practice. Ask your implementation partner to document the exact report fields and rights needed so the routine can be repeated by your own staff.
Access and data controls for SLA and OLA settings
SLA and OLA definitions drive response and resolution targets for every ticket that falls under them, so who can change them, how changes are recorded and how the underlying database is protected all matter. The cards below cover the rights, audit trail and backup steps to settle before the first calendar or target goes live.
Who can define SLAs and OLAs
Creating and editing SLA and OLA objects is controlled by GLPI profile rights, so only a small set of administrators should hold them. Review which profiles can open the SLA and OLA configuration screens, and separate the people who define targets from the people who only run the service desk. Confirm this against your own profiles, since the exact rights names depend on your GLPI version.
Profile rights on calendars and targets
Calendars, TTO and TTR targets and escalation settings each sit behind rights that can be granted separately. A calendar change affects every SLA that uses it, so restrict calendar editing more tightly than ticket editing. Test each profile with a non-admin account before you hand it to a team lead, and record the rights matrix as part of your configuration documentation.
Change history for audit
Before you rely on SLA reporting for customer or internal reviews, confirm how GLPI records changes to SLA and OLA objects and whether the history is visible to auditors. Ask who can view that history and how long entries are kept in your version. Pair the history with a short change log in your own system for each target change, including the reason and the approver.
Database backups holding SLA objects
SLA, OLA, calendar and pending-status settings are stored in the GLPI database, so a restore point must include it. Schedule database dumps at a frequency that matches how often targets change, and test a restore into a separate environment. Ask your database team how the backups are encrypted and where copies are held.
Backup before configuration migrations
The GLPI update procedure requires a backup of the database, the application files and the config directory before any update runs. The config directory includes the glpi.key and glpicrypt.key files, which protect stored secrets, so a database dump alone is not enough to restore a working instance. Run php bin/console db:update only after that backup is verified, and plan a review of SLA and OLA objects afterward.
Questions buyers ask before setting up GLPI SLAs and OLAs
What drives the effort to configure SLAs and OLAs in GLPI?
The effort is driven mostly by how many distinct service commitments you have and how well they are defined before configuration starts. Each SLA or OLA needs a calendar, a time to own (TTO) target and a time to resolve (TTR) target, and each target can differ by priority, category or entity. A service desk with one customer tier and a single working calendar is a small job. A multi-entity deployment with several customer contracts, support groups in different time zones and holiday rules is a larger one. Testing against real ticket histories also adds effort, because pending-status behavior and calendar edge cases only show up when tickets move through the workflow.
Can an internal team set up GLPI SLAs and OLAs without a partner?
Yes, a capable internal GLPI administrator can configure SLAs and OLAs, provided they have time to read the official GLPI documentation and test the results. The harder part is usually the decisions behind the configuration: agreed targets, calendar definitions, which groups own which OLA and who is accountable when a target is missed. A partner is most useful when those decisions are still open, when the same model must be reproduced across several entities, or when the configuration must be tied to business rules, escalation and reporting at the same time. Ask your team to list the gaps honestly before deciding.
What does the business need to provide before SLA and OLA work starts?
Before configuration starts, the business should supply the service targets, the working calendars, and the names of the escalation owners. Targets need to be stated per priority and per customer tier, with the agreed response and resolution times. Calendars must define working hours, time zones, public holidays and any closure periods that affect the clock. Escalation owners are the people or groups who receive alerts when a target is at risk or breached. Without these inputs, the configuration will reflect assumptions rather than commitments, and the first compliance report will raise questions nobody can answer.
How does pending status affect SLA and OLA clocks in GLPI?
In GLPI, the pending status is the main mechanism that stops the clock while a ticket waits on someone outside the support team, such as a requester or a third party. Whether the clock pauses, and under which conditions, depends on how the SLA and OLA are set up and how status changes are handled. Engineers should test each transition path, including waiting for information, reopening after solution and reassignment between groups. Pausing the clock too often hides real delays, while never pausing it penalizes the support team for time it does not control. Agree on the rule with the business before building it.
How long does validating SLA and OLA compliance take?
Validation takes as long as it takes to create representative tickets and check each result, so the duration depends on the number of targets, calendars and status paths you need to test. The most useful checks are: a ticket that is resolved inside its target, one that breaches, one that is placed in pending and resumed, and one that crosses a holiday or out-of-hours boundary. Compare the results in the ticket statistics against what you expect by hand. Ask any partner to show the test cases and the expected values in the written scope, so you can judge the work before accepting it.
How do I request a quote for GLPI SLA and OLA setup?
DeployOpen does not publish a price list. Most engagements are fixed-scope, and a quote follows from a written scope that defines the deliverables and timeline before work starts. To prepare a request, list your entities, the SLA and OLA targets per priority and tier, your calendars, the groups that own each OLA, the status workflow you use, and any related work such as escalation, routing rules or email-to-ticket. Also state whether you need ongoing support after go-live, since retainers are available separately. Clear inputs produce a quote you can compare fairly with your internal estimate.
Should SLA and OLA design be finished before escalation and routing rules?
Yes, in most cases the service targets and calendars should be agreed first, because escalation levels and business rules refer to them. Escalation fires against time thresholds that come from the SLA or OLA, and routing rules often assign the tickets whose targets you are measuring. If you build escalation or routing before the targets are settled, you will need to rework conditions and retest. Treat SLA and OLA design as the foundation, then add escalation, routing and reporting in a second pass with the same test cases.
How DeployOpen works on this
DeployOpen plans, implements and hands over GLPI inside infrastructure you control, including the SLA and OLA model that your service desk depends on. We start from your service commitments and working calendars, then configure, test and document the targets so your team can run and adjust them after handover.
How we scope
- We map your service catalog, priority levels and customer commitments to the SLAs and OLAs GLPI needs to hold.
- We agree which calendars, entities and ticket categories each target applies to before any configuration starts.
- Engagements are fixed-scope, so the written scope lists the SLA and OLA objects, tests and documents included.
- We confirm which GLPI version and database your instance runs, since target behavior is checked against that release.
How we build
- We create calendars, then SLAs with TTO and TTR targets and OLAs for each internal support group.
- We configure pending status rules so the clock behavior matches what your customers and teams have agreed.
- We test sample tickets across priorities, entities and pending transitions, and record the results for your review.
- We check compliance figures in ticket statistics against test cases so reporting reflects the configured targets.
How we hand over
- We document each SLA and OLA with its calendar, trigger conditions, pending behavior and owning group.
- We walk your service desk leads through the configuration and the test evidence in a working session.
- We provide change steps for adjusting targets, so future edits are made deliberately and logged in your records.
- We record how the targets interact with escalation, routing and recurring work so related settings are not changed in isolation.
How we support
- Ongoing support, upgrades and reviews of SLA and OLA behavior are available as retainers after handover.
- We can review target configuration when GLPI moves to a new major version, since plugins are suspended after updates and must be reactivated.
- Ask us to confirm the support scope, response expectations and version coverage in the written quote before work begins.
