Troubleshooting common SLA issues

If you're experiencing 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 is breached
Breached targets do not take business hours into consideration
The new policy does not display
SLA applied only to some tickets
First reply time metric not working
SLA is not paused when ticket status is pending
Target hours showing incorrectly
Newly applied SLA executes 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 is breached 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 do not take business hours into consideration Even if you set up the target on business hours, the badge always shows the time in calendar hours. It doesn't matter if your target is in business or calendar hours. The new policy does not display Zendesk doesn't apply a newly created SLA policy to existing tickets, or Zendesk doesn't apply an updated SLA policy to tickets already using that SLA. Explanation SLAs are based on ticket events. For an SLA policy to match tickets, an event such as ticket creation or ticket update must happen on the ticket. Otherwise, the ticket shows no SLA information or continues to show the old SLA information. In the example below, an SLA policy didn't apply because 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 the example below, an SLA policy applies after a ticket update, after you create a policy or update the ticket to meet an existing policy's conditions: SLA applied only to some tickets An SLA doesn't apply to tickets that meet all the SLA policy 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 using custom ticket fields. Depending on the ticket priority, SLA policies can have different target times and types of hours of operation: If the ticket doesn't have a priority to match the target time in the SLA policy, the target time doesn't apply and no timer displays until you add a priority. This can also happen if you create the ticket with a private comment or internal note from a user who is not a light agent. For private tickets, first reply time SLA targets are deferred. The SLA target activates when the first public end-user comment is added, even if there are public agent comments before that point. In the example below, Zendesk didn't apply an SLA policy because the ticket was created without a priority. After you update the same ticket to have a priority, Zendesk applies the SLA policy. First reply time metric not working A newly created ticket doesn't show a timer for the first reply time metric even though all criteria for the SLA policy are met. Explanation This happens when an agent creates a ticket on behalf of an end user and the first comment is public. The first reply target is fulfilled at ticket creation because the agent submits the first public comment, which is the first reply. 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 is not paused 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. There are currently four SLA targets that 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 if an agent replies with a public comment to the requester. The first reply time and the next reply time always use an end-user comment as the starting point and a public agent response as an endpoint. For more information, see Defining and using SLA policies. Target hours showing incorrectly Tickets with SLAs that have a target in business hours show a higher number of hours than the SLA metrics should have set. Explanation SLA badges always display in calendar hours. Real time remaining appears so agents can prioritize their work. Although you can choose to calculate the target time in business hours, the timer still displays time in calendar hours and won't take into consideration non-working days or holidays set in your account. For a detailed explanation, see Why do I see differences in SLA target hours? Newly applied SLA executes additional breach event When Zendesk applies a new policy to a ticket that already had the SLA breached, even if the new policy is only a modified version of an existing policy, the system records another breach event at the time of the update. Explanation
The system can't modify past ticket events history. When a new SLA application happens, the SLA counter always looks forward from that point.
Why don't I see an SLA badge when there's an SLA policy on the ticket?
There are several reasons why an SLA badge won't appear on a ticket with an SLA policy applied. 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, including adding or removing 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 its SLA badge according to the new schedule. Minimize schedule changes, since frequent changes cause confusion.


Note: SLAs don't apply to tickets that you solve upon creation. The solved status satisfies SLAs and prevents policies from activating, as long as the ticket remains solved. If you reopen tickets, SLAs can start activating and running normally.

.ai-only {
position: absolute !important;
width: 1px !important;
height: 1px !important;
padding: 0 !important;
margin: -1px !important;
overflow: hidden !important;
clip: rect(0, 0, 0, 0) !important;
white-space: nowrap !important;
border: 0 !important;
}



THIS SECTION IS AI CONTENT. DON'T EDIT OR DELETE.

Why does the SLA badge or due date show "Now" after a breach? Why does the deadline change to "Now" after breaching?
The badge displays "Now" when the target changes after a breach. Public comments, ticket status or progress changes, priority changes, or policy changes cause these adjustments.

Why do breached SLA targets ignore business hours or schedules? Why do deadlines show calendar hours after breaching?
Even if you set up the target on business hours or schedules, the badge always shows the time in calendar hours. It does not matter if your target uses business or calendar hours.

Why does a new SLA policy or due date rule not display? Why does an updated policy not apply to existing tickets?
Zendesk does not apply a newly created SLA policy to existing tickets. Zendesk also does not apply an updated SLA policy to tickets already using that SLA. For an SLA policy to match tickets, an event such as ticket creation or a ticket update must happen on the ticket. Otherwise, the ticket shows no SLA information or continues to show the old SLA information. This happens when the ticket does not meet the policy conditions, or an existing policy does not exist to apply the last time you update the ticket.

Why does an SLA apply only to some tickets? Why do some deadlines or due dates fail to show on tickets?
An SLA does not apply to tickets that meet all the SLA policy conditions when tickets do not have a set ticket priority. Tickets must have a priority for the SLA target to apply. The ticket priority must use the system default field. SLAs do not apply using a custom field or extra dropdown. If the ticket does not have a priority to match the target time in the SLA policy, the target time does not apply and no timer displays until you add a priority.
This also happens if you create the ticket with a private comment or internal note from a user who is not a light agent or viewer. For private tickets, first reply time SLA targets defer. The SLA target activates when the first public comment from an end user or customer is added, even if public agent comments exist before that point.

Why is the first reply time metric or deadline not working? Why does a new ticket show no timer for the first reply time?
This happens when an agent or team member creates a ticket on behalf of an end user or customer and the first comment is public. The first reply target fulfills at ticket creation because the agent submits the first public comment, which acts as the first reply. You can create exceptions in your advanced settings.

Why is the SLA not paused when the ticket status is pending? Why does the deadline timer keep running in pending state or progress?
The SLA timer does not pause when the ticket status changes to Pending. This happens because the ticket waits for agents to fulfill the first reply time or the next reply time metric. Four SLA targets do not pause in pending status: First Reply Time, Next Reply Time, Periodic Update Time, and Total Resolution Time. Reply metrics do not change based on ticket status. You fulfill reply metrics if an agent replies with a public comment to the requester or customer. The first reply time and the next reply time always use an end-user comment as the starting point and a public agent response as an endpoint.

Why are SLA target hours showing incorrectly? Why do deadlines with business hours show a higher number of hours?
Tickets with SLAs that use a target in business hours or schedules show a higher number of hours than the SLA metrics should set. SLA badges always display in calendar hours. Real time remaining appears so agents can prioritize their work. Although you can choose to calculate the target time in business hours, the timer still displays time in calendar hours and does not take into consideration non-working days or holidays set in your account.

Why does a newly applied SLA execute an additional breach event? Why does updating a policy log another deadline breach?
When Zendesk applies a new policy to a ticket that already breached the SLA, even if the new policy is only a modified version of an existing policy, the system records another breach event at the time of the update. The system cannot modify past ticket events history. When a new SLA application happens, the SLA counter always looks forward from that point.

Why do updates to schedules, business hours, or holidays not reflect in SLA targets? Why does editing a schedule fail to update deadlines?
When you edit a schedule, including adding or removing holidays, SLA targets do not automatically update. However, if a ticket receives an SLA update, targets reassess. If a public comment, status change, priority change, or policy change occurs, the ticket recalculates its SLA badge according to the new schedule. Minimize schedule changes, since frequent changes cause confusion.

Do SLAs apply to tickets solved upon creation? Can a fixed in one go ticket trigger a deadline timer?
SLAs do not apply to tickets that you solve upon creation. The solved ticket status satisfies SLAs and prevents policies from activating, as long as the ticket remains solved. If you reopen tickets, SLAs can start activating and running normally.




