Troubleshooting common SLA issues

If you experience service level agreement (SLA) issues, use this guide to find solutions to the most common behaviors.

This article contains the topics below:

The badge shows Now after the target breaches

Breached targets don't consider business hours

The new policy doesn't appear

SLA applies only to some tickets

First reply time metric doesn't work

SLA doesn't pause when the ticket status is pending

Target hours show incorrectly

Newly applied SLA executes an additional breach event

Why don't I see an SLA badge when there's an SLA policy on the ticket?

Updates to schedules don't reflect in SLA targets

For general information about how SLAs function, see Viewing and understanding SLA targets.

The badge shows Now after the target breaches

The badge displays Now when the target changes after a breach. These changes include public comments, status changes, priority changes, or policy changes.

Breached targets don't consider business hours

Even if you set up the target in business hours, the badge shows the time in calendar hours. This applies whether your target uses business or calendar hours.

The new policy doesn't appear

A newly created SLA policy doesn't apply to existing tickets. Also, an updated SLA policy doesn't apply to tickets that already use that SLA.

Explanation

SLAs rely on ticket events. An event such as ticket creation or update must occur on the ticket for an SLA policy to match. Otherwise, the ticket doesn't show SLA information, or it continues to show the old SLA information.

In the example below, the SLA policy didn't apply. No policy existed during the last ticket update, or the ticket didn't meet the conditions.

In the example below, the SLA policy applies after you update the ticket to meet the conditions.

SLA applies only to some tickets

An SLA doesn't apply to tickets even when they meet all the conditions.

Explanation

This happens when tickets don't have a set ticket priority. Tickets must have a priority for the SLA target to apply. The ticket priority must be the system default field. SLAs don't apply to custom ticket fields.

Depending on the ticket priority, SLA policies can have different target times and operating hours.

If the ticket doesn't have a priority to match the SLA policy, the target time doesn't apply. No timer appears until you add a priority.

This also happens if you create a ticket with a private comment from a user who isn't a light agent. The system defers first reply time SLA targets for private tickets. The SLA target activates when an end user adds the first public comment, even if public agent comments exist before that point.

In the example below, the SLA policy didn't apply because you created the ticket without a priority.

After you update the ticket to include a priority, the system applies the SLA policy.

First reply time metric doesn't work

A newly created ticket doesn't show a timer for the first reply time metric, even though the ticket meets all policy criteria.

Explanation

This happens when an agent creates a ticket on behalf of an end user and makes the first comment public. Ticket creation fulfills the first reply target because the agent submits the first public comment.

In the example below, no first reply time metric applies because the agent created the ticket.

You can create exceptions in your advanced settings.

SLA doesn't pause when the ticket status is pending

The SLA timer doesn't pause when the ticket status changes to pending.

Explanation

This happens because the ticket waits for agents to fulfill the first reply time or the next reply time metric. Four SLA targets don't pause in pending status: First Reply Time, Next Reply Time, Periodic Update Time, and Total Resolution Time. Reply metrics don't change based on ticket status. You fulfill reply metrics when an agent replies with a public comment to the requester.

Both first and next reply times use an end-user comment as the starting point and a public agent response as the endpoint. For more information, see Defining and using SLA policies.

Target hours show incorrectly

Tickets with SLAs in business hours show more hours than the SLA metrics set.

SLA time targets are always displayed in calendar hours. This is done for agents to identify which tickets have a higher priority in real-time.

For example, the tickets below arrive during the middle of the weekend, and your business hours are defined from Monday to Friday, from 9:00 AM to 5:00 PM.

Ticket A has an SLA target that's due in 18 business hours.

Ticket B has an SLA target that's due in 72 calendar hours.

The ticket view shows due time in a way that the target due sooner will receive higher attention, with the remaining time using the same type of hours.

For additional information about how SLAs work, see the article: Defining and using SLA policies.

Newly applied SLA executes an additional breach event

When a new policy applies to a ticket that already breached the SLA, the system records another breach event during the update. This occurs even if the new policy is a modified version of the existing policy.

Explanation

The system can't modify past ticket events. When you apply a new SLA, the counter looks forward from that point.

Why don't I see an SLA badge when there's an SLA policy on the ticket?

An SLA badge won't appear on a ticket with an applied SLA policy for several reasons. For more information, see Why aren't SLA badges appearing?

Updates to schedules don't reflect in SLA targets

Explanation

When you edit a schedule to add or remove holidays, SLA targets don't automatically update. However, if a ticket receives an SLA update, targets reassess. If there's a public comment, status change, priority change, or policy change, the ticket recalculates the SLA badge based on the new schedule. Minimize schedule changes because frequent changes cause confusion.

Note: SLAs don't apply to tickets that you solve upon creation. The solved status satisfies SLAs and prevents policy activation as long as the ticket remains solved. If you reopen tickets, SLAs activate and run normally.