SLA definitions let you track whether your team is meeting response and resolution targets for incidents. This guide walks you through creating an SLA definition that automatically starts timing when incidents meet your criteria.
The problem with manual SLA tracking
Before SLA definitions, teams tracked response times manually or with clunky reporting after the fact. Incident managers couldn't see real-time SLA status, stakeholders had no visibility into breach risks, and calculating performance percentages meant pulling data from multiple sources weeks later. The people managing incidents — service desk agents and managers — had to guess whether they were on track or rely on static reports that were already outdated.
How SLA definitions work
An SLA definition is a template that tells ServiceNow when to start timing, when to pause the clock, and when to stop. When an incident meets your start conditions, ServiceNow creates a task_sla record that tracks actual timing against your target. The definition sets the duration (like '4 hours') and schedule (business hours vs 24/7). Start conditions determine when timing begins, pause conditions stop the clock temporarily, and stop conditions end timing permanently. Most teams start with basic priority-based rules and add complexity for VIP users or specific categories over time.
Building production-quality SLAs
Once basic timing works, the improvements that matter are: adding pause conditions for customer holds and pending states, setting different targets by impact/urgency matrix instead of just priority, and creating separate definitions for response vs resolution. Production SLAs also need reset conditions for when incidents get escalated or reassigned to different teams, and careful schedule configuration that matches your actual support hours, not theoretical business hours.
Before you start
- •sla_admin role or admin role
- •Incident table configured with Priority and State fields
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to SLA Definitions
Go to Service Level Management > SLA > SLA Definitions. Click New to create a new definition. Set the Name to something descriptive like 'Incident Response - Priority 1' and leave Active checked. The Document table should default to Incident [incident] — if not, set it manually.
Set duration and schedule
In the Duration field, enter your target time like '4 hours' or '2 business days'. Choose your Schedule — leave blank for 24/7 timing, or select a schedule record for business hours only. The schedule determines whether weekends and holidays count toward your SLA time. Set Timezone if your schedule needs to run in a specific timezone different from your instance default.
Configure start conditions
In the Start condition field, build a filter that defines when this SLA begins timing. For a Priority 1 response SLA, use 'Priority is 1'. For resolution SLAs, you might use 'Priority is 1^State is not Resolved^State is not Closed'. The start condition runs every time an incident is created or updated — be specific to avoid unwanted SLA instances.
Test your start condition on a few real incident records before activating the SLA definition.
Set pause conditions
Use Pause condition to stop timing when waiting on customer response or external dependencies. Common pause conditions include 'State is Awaiting User Info' or 'State contains Pending'. Leave this blank if you want continuous timing. Paused time doesn't count toward breach calculation — use this carefully since pausing can mask real performance issues.
Configure stop conditions
The Stop condition defines when SLA timing ends successfully. For response SLAs, use something like 'Work notes is not empty' or 'Assigned to is not empty'. For resolution SLAs, use 'State is Resolved^State is Closed'. The stop condition should match your actual definition of meeting the SLA, not just closing the incident.
Set reset conditions if needed
Reset condition restarts the SLA timer when circumstances change. Use this when incidents get escalated ('Priority changes from 3 to 1') or reassigned between teams ('Assignment group changes'). Leave blank unless you need the SLA to restart timing from zero. Reset creates a new task_sla record, so use sparingly to avoid confusing metrics.
Configure breach notification
Set the Workflow field to an existing notification workflow if you want breach alerts, or leave blank. In Advanced settings, you can set a percentage threshold (like 80%) to trigger early warnings before actual breach. Click Submit to save the SLA definition — it becomes active immediately for new incidents matching your conditions.
Best practices
Create separate SLA definitions for response and resolution — they have different stop conditions and trying to combine them creates confusing metrics.
Always test start conditions on existing incident data before activating — overly broad conditions create thousands of unwanted SLA records that are painful to clean up.
Use business hour schedules for customer-facing SLAs but 24/7 schedules for internal operational targets — mixing them creates unrealistic expectations.
Set pause conditions conservatively — every pause condition becomes a way for teams to game the metrics instead of improving actual performance.
Breach percentages calculate as (total SLA instances - breached instances) / total instances, so reset conditions that create multiple task_sla records will skew your numbers.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue