SLA Management in ServiceNow
Introduction
Service Level Agreements (SLAs) define the response and resolution commitments your IT team makes to the business. ServiceNow's SLA engine automatically tracks these commitments in real time, pausing and resuming timers based on ticket state, raising breach warnings, and escalating when deadlines approach.
Configuring SLAs correctly is one of the most operationally impactful things an administrator can do. This guide covers every layer of the SLA stack.
SLA Terminology
| Term | Definition |
|---|---|
| SLA | Agreement with the customer (external) |
| OLA | Operational Level Agreement — internal team commitments |
| UC | Underpinning Contract — vendor commitments |
| SLA Definition | The rule that creates SLA records on tickets |
| Task SLA | The actual timer record on a specific ticket |
| Schedule | Business hours configuration (when the clock runs) |
SLA Definition Structure
Every SLA Definition (contract_sla) defines:
- Table: Which table to apply to (e.g.,
incident) - Type: Response, Resolution, or custom
- Target: Duration (e.g., 4 hours, 8 hours)
- Schedule: The business hours schedule to measure against
- Start condition: When the timer begins
- Pause condition: When the timer pauses (e.g., On Hold state)
- Stop condition: When the timer stops (e.g., Resolved state)
- Reset condition: When the timer resets and starts fresh
Schedules: Business Hours
SLAs almost always measure elapsed business time, not calendar time. Schedules (cmn_schedule) define working hours:
Schedule: US Eastern Business Hours
Monday–Friday: 8:00 AM – 6:00 PM EST
Excludes: Public holidays
Link the schedule to the SLA Definition. The engine will only count time when the schedule is active.
Tip: Create separate schedules for different support tiers (24x7 for P1, business hours for P3/P4).
Start, Pause, and Stop Conditions
Start Condition
When should the SLA clock begin?
Start when: State changes to "In Progress"
— OR —
Start when: Record is created (incident created)
For P1 incidents, the clock often starts on creation. For standard requests, it may start when work begins.
Pause Condition
When should the clock pause?
Pause when: State = On Hold
This is critical. If a ticket is waiting on the customer ("On Hold - Awaiting User Info"), the SLA timer should not count against your team.
Stop Condition
When should the timer stop?
Stop when: State = Resolved OR State = Closed
Reset Condition
Optional — restarts the timer from zero:
Reset when: State changes back to "New" from "On Hold"
Priority-Based SLA Example
A typical IT service desk SLA structure:
| Priority | Response Target | Resolution Target | Schedule |
|---|---|---|---|
| P1 - Critical | 15 minutes | 4 hours | 24x7 |
| P2 - High | 1 hour | 8 business hours | Business hours |
| P3 - Moderate | 4 hours | 3 business days | Business hours |
| P4 - Low | 8 hours | 5 business days | Business hours |
For each row, create one Response SLA Definition and one Resolution SLA Definition, each with an appropriate condition like Priority = 1.
Breach Notifications
SLA breach alerts fire via the SLA workflow or notifications tied to SLA percentage milestones:
- 50% elapsed: Early warning to assignee
- 75% elapsed: Warning to assignee + team lead
- 100% elapsed (breach): Alert to manager + incident escalation
Configure via SLA Workflow on the SLA Definition or via dedicated notification conditions:
Notification condition:
Task SLA.Has breached = true
AND Task SLA.Type = Resolution
Task SLA Records
When a ticket meets an SLA Definition's start condition, a Task SLA record (task_sla) is created on the ticket:
| Field | Value |
|---|---|
| Task | INC0001234 |
| SLA | P1 Resolution SLA |
| Stage | In Progress |
| Planned end time | 2024-03-15 14:00:00 |
| Time elapsed (%) | 62% |
| Has breached | false |
The related list on any incident shows all active and historical Task SLA records.
Retroactive SLAs
If you create or modify an SLA Definition after tickets already exist, use Retroactive Start to apply the SLA to existing open records:
SLA Definition → Retroactive start checkbox
Use with caution — this can generate a large number of Task SLA records on existing tickets.
Reporting on SLAs
Key reports for SLA performance:
- SLA Compliance %: Percentage of tickets resolved within target
- Breached tickets by team: Which assignment groups are missing SLAs
- Average time to resolution by priority: Trend over time
- Near-breach alerts: Tickets at 75%+ elapsed that haven't resolved
Navigate to Service Level Management > SLA Reports for out-of-the-box dashboards.
Best Practices
- Use meaningful, descriptive names for SLA Definitions (include priority and type)
- Always define pause conditions for "waiting on customer" states
- Test SLA behavior with a sample ticket before go-live
- Build breach notifications before SLAs go live — not after first breach
- Review SLA attainment rates monthly and adjust targets if consistently >95% or <50%
- Use separate schedules for different support tiers
- Don't attach multiple SLAs of the same type to the same ticket — causes confusion in reporting
Conclusion
SLAs are the contract between IT and the business. The ServiceNow SLA engine automates the tracking, but the configuration must accurately reflect those agreements — including pauses for factors outside IT's control. Get the conditions right, build breach notifications before go-live, and report on SLA performance weekly to build credibility with your stakeholders.