Short definition
An SLA (Service Level Agreement) in Jira Service Management is a configured time target for responding to or resolving customer tickets. Each SLA has a goal (e.g., respond within 4 hours), calendar (business hours), conditions (which tickets it applies to), and start/pause/stop triggers. SLAs feed queue columns, reports, and breach notifications, and are central to JSM's service-desk model.
What an SLA tracks
A JSM SLA is a configured measurement of how quickly a service desk responds to or resolves customer work. Each SLA has:
- A name (e.g., “Time to First Response,” “Time to Resolution”).
- One or more goals - target durations, scoped by JQL conditions.
- A calendar - which hours count toward the SLA (e.g., business hours only).
- Start, pause, stop triggers - which events on the issue start, pause, or stop the timer.
A typical service desk has at least two SLAs: a response-time SLA and a resolution-time SLA. Each is displayed on agent queues as a colour-coded timer, sorted so the most urgent work surfaces first.
Triggers and calendars
SLA timers are precision objects. Three trigger types:
- Start triggers - what starts the clock. Usually “Issue created” or “Status changes to X.”
- Pause triggers - what stops the clock without resolving it. Usually “Status: Waiting for Customer.” When the trigger reverses, the clock resumes.
- Stop triggers - what stops the clock permanently. Usually “Issue resolved” or “First public comment by agent.”
Calendars define which hours count. A 24/7 ops desk uses a 24-hour-a-day calendar; a business-hours help desk uses Monday-Friday 9-to-5. Holidays are configured per calendar so the clock doesn’t run on public holidays.
Priority-based goals
A single SLA can carry multiple goals scoped by JQL. The standard pattern:
priority = Highest -> 1h
priority = High -> 4h
priority = Medium -> 24h
priority = Low -> 72h
Jira evaluates goals top-to-bottom and applies the first match. So goals must be ordered from
most-specific to most-general. A catch-all goal at the bottom (status != Done) handles tickets that
don’t match any specific priority.
SLAs in queues and reports
The two main agent-facing surfaces:
- Queue columns show the live SLA timer per ticket, colour-coded (green / amber / red). Sorting by SLA descending puts the most urgent at top.
- SLA reports show breach rates and trends over time. Used in management reviews and customer reporting (most service contracts require monthly SLA breach figures).
For service desks where SLA accuracy is contract-critical, audit the pause/resume triggers periodically - a misconfigured pause that doesn’t actually fire is the most common source of “we thought we hit SLA but the report says we didn’t” disputes.
Common questions
What is an SLA in Jira?
An SLA (Service Level Agreement) in Jira Service Management is a configured time target for responding to or resolving customer tickets. Each SLA has a goal (e.g., respond within 4 hours), calendar (business hours), conditions (which tickets it applies to), and start/pause/stop triggers. SLAs feed queue columns, reports, and breach notifications, and are central to JSM's service-desk model.
What's the difference between Time to First Response and Time to Resolution?
Time to First Response measures how long until an agent first replies (publicly) to a ticket - the customer-experience clock. Time to Resolution measures total time from creation to resolved - the throughput clock. Most service desks track both, with shorter goals for response and longer for resolution. Different priorities usually have different goals for each.
How do SLAs pause and resume?
An SLA can be configured to pause when a ticket enters certain statuses (commonly 'Waiting for Customer') and resume when it returns to others ('Waiting for Support'). This stops the clock during periods outside the agent's control. Pause/resume rules are configured per SLA in the project's SLA settings.
Can different priorities have different SLA goals?
Yes - this is the standard configuration. A single SLA can have multiple goals, each scoped by JQL: `priority = Highest` -> 1 hour first response; `priority = High` -> 4 hours; `priority = Medium` -> 24 hours; etc. The first matching goal wins, so order them from most-specific to most-general.