Skip to main content
Service Level Agreements (SLAs) define your team’s commitments — how quickly tickets should be resolved, how quickly a human agent should respond, and so on. Configure SLA policies to track performance and surface tickets that are at risk of breaching.

​
Understanding SLAs

An SLA policy measures one specific commitment against a target duration. A policy has three pieces:
  • What to measure — the metric (e.g. time to resolution, time to first response).
  • When the clock starts — the starting point (when the SLA is attached, or backdated to when the ticket was created).
  • What stops the clock — implied by the metric. Resolution stops on ticket closure; first response stops on the first agent reply.
Tickets that match the policy’s criteria are tracked automatically. A single ticket can have several SLAs running at once, one per policy group: policies in different groups run concurrently, while policies in the same group share a single slot (the first matching policy attaches). A policy without a group uses its metric as the group, so by default a ticket carries at most one resolution SLA and one first-response SLA. Named groups unlock several same-metric SLAs on one ticket — for example a “Resolution — full time” SLA alongside a “Resolution — excluding vendor time” variant that pauses while you wait on a third party.

​
Creating an SLA Policy

1

Open SLA settings

Go to Team Settings → SLAs.
2

Add an SLA policy

Click Add SLA.
3

Configure the policy

4

Save the policy

Click Create to activate the SLA policy. Matching tickets will begin tracking automatically.

​
Metrics

The metric determines what the SLA is measuring — and therefore what stops the clock.
First-human-response SLAs only count human agent messages. AI assistant messages, internal notes, system-generated messages, and messages from the ticket’s requester do not stop the clock — first response is specifically about a person picking up the conversation.
If a ticket is resolved before a human ever responds (for example, fully handled by AI), the SLA closes out at resolution time. It records as Met if resolution happened within the SLA’s target duration, or Breached if it took longer — same met/breached logic as a normal completion.

​
Starting Points

The starting point controls when the clock begins.
To measure time-to-first-human-response after a specific event (e.g. after escalation to a human), express the event with auto-attach criteria rather than the starting point. For example, combine the Time to first human response metric with When the SLA is attached and add ticket.escalation_level = human to the auto-attach criteria — the SLA will only attach (and start counting) once the ticket has been escalated.

​
Calendar Time vs. Business Hours

When creating an SLA, you choose how time is counted:
  • Calendar time (24/7) — The clock runs continuously, including nights and weekends. Use this for critical issues that require around-the-clock attention.
  • Business hours — The clock only runs during your configured working schedule. Use this for standard requests where resolution outside business hours isn’t expected.

​
Configuring a Business Hours Schedule

If you select business hours, you’ll choose a schedule that defines your team’s working days and hours. Schedules include a timezone and per-day time windows (e.g., Monday–Friday, 9 AM – 5 PM).
Schedules are reusable — the same schedule can be shared across SLA policies and assignment rules.

​
Auto-Attach Criteria

SLA policies can automatically apply to tickets based on conditions like:
  • Priority: Apply to tickets of a specific priority level
  • Labels: Apply to tickets with specific labels
  • Assignment group: Apply to tickets assigned to one of the assignment groups you select. Available once your team has assignment groups configured.
Each criterion can match on is or is not. For example, attach an SLA to every ticket whose Priority is not Low. The same is / is not option applies to pause conditions. This lets you create different SLA targets for different types of tickets. For example, you might have a 4-hour SLA for critical priority tickets and a 72-hour SLA for low priority requests.

​
SLA Pausing

You can configure pause conditions so the SLA timer stops when the ticket is in certain states. This prevents your team from being penalized for time spent waiting on external parties. Common pause scenarios:
  • Waiting on requester — Pause while waiting for the requester to provide more information
  • Waiting on vendor — Pause while waiting for a third-party response
  • On hold — Pause for tickets that are intentionally paused
Pause conditions are configured per SLA policy. The timer resumes automatically when the pause condition is no longer met.

​
SLA Tracking

​
SLA Status

Tickets tracked by an SLA policy show their SLA status:
  • On track — The ticket is within its SLA target
  • At risk — The ticket is approaching its SLA deadline
  • Breached — The ticket has exceeded its SLA deadline

​
SLA column in ticket lists

Add the SLA column to any ticket list to see how much time each ticket has before its SLA breaches. The column is hidden by default—turn it on from the ticket list’s column picker. Each cell shows the ticket’s most urgent active SLA:
  • Time remaining: a live countdown to the breach deadline. It turns red in the final hour.
  • Overdue: how long the SLA has been past its deadline.
  • Paused: the SLA timer is currently paused.
  • Met or Failed: the SLA finished within, or past, its target.
Sort by the column to bring the tickets closest to breaching to the top.

​
When SLA Tracking Ends

SLA tracking stops when the metric’s completion event fires:
  • Resolution SLAs stop when the ticket reaches a “Done” or “Canceled” status.
  • First-human-response SLAs stop when a human agent posts the first qualifying reply on the ticket after the clock started, or when the ticket is resolved without one.
You can also manually detach an SLA from a ticket by opening the SLA row in the ticket sidepanel, expanding the picker, and clicking Remove SLA. The detached SLA is recorded in the ticket activity timeline; other SLAs on the ticket are unaffected.

​
SLA Reporting

Track SLA performance in analytics: The analytics dashboard includes an SLA performance chart that shows the percentage of tickets meeting SLA targets vs. breaching. You can filter the chart by priority, assignee, or other attributes to drill into specific areas.
Use the SLA filter in the ticket list to quickly find tickets that are at risk or breached and need immediate attention.

​
Common Questions

Yes. You can create different policies for different ticket types using auto-attach criteria. For example, one policy for critical tickets with a 4-hour target and another for low priority with a 72-hour target.
A ticket can have one active SLA per policy group. Policies without a group use their metric as the group, so by default one resolution SLA and one first-response SLA can coexist. If two policies in the same group both match a ticket, the first matching policy (by name order) attaches and the rest are skipped — use this to build priority ladders, where each rung’s auto-attach criteria target a different priority. Policies in different groups all attach and track independently. The ticket’s headline SLA status reflects the most urgent of the active SLAs (a breached SLA outranks an in-progress one; in-progress outranks paused; if two are tied, the one breaching soonest wins).
Yes — that’s the point of separating what to measure from when the clock starts. Configure two policies (e.g. “Resolve within 4h from creation” and “First response within 15m from attachment”), and both will track independently. The ticket sidepanel shows one row per SLA slot.
Yes — give each variant its own policy group. For example, create groups “Resolution — full time” (no pause conditions), “Resolution — excluding requester time” (pauses on a Waiting on requester status), and “Resolution — excluding vendor time” (pauses on Waiting on vendor). One SLA from each group attaches, and each clock pauses by its own rules, so you can report total time, time excluding the requester, and time excluding the vendor side by side. Within each group you can still build a priority ladder with several target durations. All policies in one group must measure the same metric, and the ticket sidepanel labels each row with its group name.
Yes. Updating an SLA policy affects how future tickets are tracked. Existing tickets that already have the SLA attached continue with their original target.
Filter your ticket list by SLA status to find at-risk or breached tickets. You can also use the SLA performance chart in analytics to see compliance trends.
Open the ticket, expand the SLA row in the sidepanel, and select Remove SLA. The SLA moves to a “cancelled” state — it stays in the ticket’s activity history but no longer counts toward breach scanning. Other SLAs on the ticket are untouched.