Troubleshooting common issues with SLAs Follow

professional enterprise plans

Service Level Agreement (SLA) policies are agreed-upon ticket response, update, and resolution times from your support team to your customers. SLAs make work easier by quickly identifying tickets that need more immediate attention, and setting a timer on them.

However, things can get confusing when creating an SLA policy if you're not seeing it work as expected.

This tip contains the following scenarios for the most common SLA issues:

New policy not being displayed


A newly created SLA policy is not applied to existing tickets, or an updated SLA policy is not applied to tickets already using that SLA.

Explanation :

SLAs are based on ticket events. This means that in order for tickets to be matched to an SLA policy, something needs to happen to the ticket, like a ticket creation or update event; otherwise, the ticket shows no SLA information or keeps showing the old SLA information.

In this example, an SLA policy was not applied because either there wasn't an existing policy to apply the last time the ticket was updated, or the ticket didn't meet the policy's conditions:

In this example, an SLA policy is applied after an update to the ticket, after either a policy was created, or the ticket was updated to meet an existing policy's conditions:

SLA applied only to some tickets


An SLA is not applied to tickets that meet all of the SLA policy conditions.

Explanation :

This happens when tickets do not have a set Ticket Priority . Tickets must have a priority in order for the SLA policy to apply.

SLA policies can have different due times depending on the ticket priority:

However, if the ticket doesn't have a priority to match the time set in the SLA policy, the policy is not applied, and no timer is displayed, until a priority is added.

In this example, no SLA policy is applied because the ticket was created without a priority:

After the same ticket is updated to have a priority, the SLA policy is applied:

First Reply Time metric not working


A newly created ticket doesn't show a timer for the First Reply Time metric even though it meets all the criteria for the SLA policy.


This happens when a ticket is created by an agent on behalf of an end-user. The First Reply metric does not apply on tickets created by agents because the description, being a public comment, is considered to be the first reply.

In this case, there is no First Reply Time metric applied, because the ticket was created by an agent:

Here, however, the First Reply Time metric is applied because the ticket was created by an end-user:

Other metrics, like Agent Work Time, Requester Wait Time, Next Reply Time, and Periodic Update Time, will still apply and display if the ticket meets the SLA Policy criteria.

SLA not paused when ticket status is Pending


The SLA timer does not pause when the ticket status is changed to Pending.


This happens because the ticket is waiting for the First Reply Time or Next Reply Time metric to be fulfilled. Reply metrics do not change based on the ticket status; they can only be fulfilled if there is a public reply made from an agent to the requester.

First Reply Time and Next Reply Time always use an end-user comment as starting point and a public agent response as an end point. The following graphic shows how the First and Next Reply Time metrics fit within the lifecycle of a ticket.

Target hours showing incorrectly


Tickets with SLAs that have a target in business hours show a higher number of hours than what the SLA metrics should have set.


SLA time targets are always displayed in one unit of measurement: calendar hours. This means that no matter if you use business or calendar hours for the SLA policy, the timer displayed will always show in calendar hours and exclude non-working days and holidays set in your account .

A longer explanation for this case can be found in Understanding the differences in SLA target hours .

For additional information about how SLAs work, check out Defining and using SLA policies .

That's it! Happy ticketing!

Have more questions? Submit a request


  • 0

    "In this case, there is no First Reply Time metric applied, because the ticket was created by an agent"

    When we create a ticket on behalve of a customer, we need a SLA target. It should be replied in time. Any solutions?

  • 0


    In that situation, your best bet is to make an SLA using the reply time metric of "Periodic Update Time" which looks at the time between each public comment from agents, displayed in minutes. Unfortunately if an agent creates a ticket the First Reply Time metric is already out as an option, as it looks for the first public agent comment. You can see a bit more in this document.

  • 2
    Brad M.

    Is there any way to pause the "Next SLA breach" for "Periodic update" if it is in a status of Pending? Pending, to us, implies that we are waiting for a customer response and there is no dependency on the agent until the customer has fulfilled their responsibility. However, the timer keeps on going down and can mess up our workflows as you have to ignore some SLA's and pay attention to others.

  • 2

    I agree with Brad- more granular control over SLA events would be extremely helpful.  I understand the rationale for wanting to enforce the SLAs without an easy opt-out that could allow the metrics to be fudged.  However, there are many instances where an agent may review a ticket it but push it back to pending/hold status without comment:

    • inactionable responses (e.g. 'ok', 'thanks', etc.)
    • 'customer' responses come from automated systems (e.g. 'your ticket has been created') or similar sources that don't require actual response/confirmation at some points of a lifecycle

    There are workarounds, such as temporarily switching the ticket to a dummy SLA, then removing it when a new response arrives.  To combat abuse, you can also log any time this SLA is manually overridden in a custom field or tag so you can monitor that it's being used appropriately.  

    Obviously, this isn't ideal, but it is one solution that adds the basic functionality with some oversight.  You could combine this configuration with a trigger that gives you real-ish time notifications (email, Slack, PagerDuty, etc.) if you're concerned about monitoring it more proactively.  However, it'd be nice to have more control directly in the SLA policies rather than using complex workarounds.

  • 0

    Can a ticket have SLA policies applied to it in succession?

    e.g. I've got a ticket that comes into our Tier 1 queue, to which a blanket 24 FRT SLA is applied. The agent replies back and achieves the SLA. But the ticket is not solved and needs to be escalated.

    The Tier 1 agent escalates that ticket to Tier 2.

    I have another SLA policy with 40 hour requester wait time, which should be applied to all tickets with a specific tag (applied via the escalation macro tier 1 agent used).

    That policy never gets applied. Does the ticket not get run through the SLA rules again after one SLA has been met?




  • 0

    We have the following metrics in our existing SLA:

    - 1 hour "acceptance time" for all priorities

      in this time span, we have to assign the ticket to a 2nd level agent

    - depending on priority, 1/2/4/8 hours "reaction time"

      after acceptance, we have to report an initial response by the 2nd level agent.

    - for blockers, there's a requirement for an update all 4 hours.

    There are no further requirements; there is no resolution time or some such.

    The first and last point are easy to implement, however, how do I handle and evaluate the second requirement? 

    The only idea i'd see is to "stop" the SLA after the "reaction time", i.e. first substantial response to the ticket by a 2nd level agent.


    Any pointers, ideas, tips?




  • 0

    Hi Peter!

    Interesting question here! I see you opened a ticket with our Support team and appear to be in good hands. 

    Edited by Rebecca

Please sign in to leave a comment.

Powered by Zendesk