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 as long as each one measures a different metric — for example a resolution SLA and a first-response SLA can coexist on the same ticket.

​
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

FieldDescription
NameDescriptive name (e.g., “Critical Priority Resolution”)
Target durationTime limit for the metric — choose from presets or set a custom duration in days, hours, and minutes
Calendar typeWhether to track against calendar time (24/7) or business hours
What to measureThe metric the SLA tracks. See Metrics below
Start the clockWhen the clock begins counting. See Starting Points below
Auto-attach criteriaConditions that determine which tickets this SLA applies to (e.g., priority, status, labels, groups)
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.
MetricWhat it tracksClock stops when
Time to resolutionThe total time a ticket is openTicket status reaches Done or Canceled
Time to first human responseThe time until the first human agent repliesA human agent (not the requester, not AI, not an internal note) posts a public message on the ticket after the clock started, or the ticket is resolved without one
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.
Starting pointWhen it starts
When the SLA is attachedThe moment the SLA attaches to the ticket (default)
When the ticket was createdBackdated to the ticket’s creation time. Useful when tickets sit in a queue before being routed
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
  • Status — Apply based on current status
  • Labels — Apply to tickets with specific labels
  • Groups — Apply to tickets assigned to specific groups
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

​
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 metric — one resolution SLA and one first-response SLA can coexist, for example. If two policies on the same metric both match a ticket, the first matching policy attaches and the rest are skipped. 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 metric.
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.