FAQ — Why didn’t my SLA timer pause overnight?

You expected the SLA to pause outside business hours. It didn’t, and a conversation breached. These things are worth checking, in order.

1. Did Ignore office hours get toggled on?

Open the policy in Settings → SLA Policies and look at the Ignore office hours toggle. If it’s on, the timer counts continuously regardless of opening hours — which is a feature for 24/7 SLAs but a bug if you didn’t mean to enable it.

This is the most common cause when a policy that used to respect office hours suddenly starts breaching overnight. Someone (maybe a previous-you) toggled it on for a specific use case and didn’t toggle it back.

2. Are the right opening hours actually configured?

The SLA counts in the opening hours of the conversation’s team and channel. A team with no hours of its own, and a conversation with no team yet, use the workspace’s default opening hours. If the workspace has no default rule either, the timer counts around the clock.

Open Settings → Opening Hours. On the Coverage tab, find the conversation’s team and channel and see which rule applies (Inherit means the default rule). Then confirm, on that rule:

• Hours are defined for each business day
• The timezone is correct for the team
• Holidays / date overrides reflect actual closures

The most subtle failure here: opening hours that span 24 hours per day. A schedule like “Monday 00:00 — Sunday 23:59” technically respects office hours, but the office is always open, so the timer never pauses. Look for accidentally-broad coverage.

Also worth checking: the country code on the opening-hours definition controls the holiday calendar. A wrong country code means the team’s holidays aren’t recognized as closed.

3. Is a different policy winning the assignment race?

You configured Standard Support to respect office hours, but maybe a different policy is actually applying to the conversation. SLA policies resolve by assignment specificity:

• Team + channel → score 3
• Team only → score 2
• Channel only → score 1

If a Premium policy (with Ignore office hours on) is assigned to a team and the breaching conversation routes to that team, Premium wins over Standard Support’s channel-only assignment. The timer keeps counting overnight per Premium’s rules.

Open the breaching conversation, look at its assigned team and channel, and trace which policy actually applied:

1. Did any Team + channel policy match? It wins.
2. Otherwise, did any Team only policy match the assigned team? It wins.
3. Otherwise, the Channel only policy applies.

The conversation’s audit trail records which policy was active. If you can’t find it in the UI, the Run history section of any SLA-triggered automation will reference the policy ID.

4. Did the conversation change team or channel?

When an agent or a team lead moves the conversation to another team, an automation assigns it, the AI hands it over, or the conversation switches channel, the SLA is chosen again and its deadline is counted again in the new team’s opening hours. The clock keeps the time the customer wrote in; it does not start again. So a conversation that moved to a 24/7 team counts as if it had been on that team from the start, and its deadline can move earlier.

Two SLAs are not counted again: an SLA that an automation set, and a First Reply SLA that is already answered.

5. Less common — the conversation reopened mid-night

When a conversation moves from done back to active (because the customer replied), the SLA timer restarts — including for Resolution Time, but not for a First Reply SLA that was already answered. If the conversation reopened at 23:50 the night before, the timer restarted at 23:50, started counting from 00:00 office hours the next morning, and may have breached if the new countdown was shorter than the time before next office-hours start.

This is rare but worth checking on conversations that have a reopen event in their timeline.

Quick diagnostic

Open the breached conversation, then check in this order:

1. The policy that applied (audit trail or live badge details)
2. That policy’s Ignore office hours toggle
3. The opening hours of the conversation’s team and channel (or the default hours, if it has no team) for the date range that breached
4. Whether the conversation changed team or channel
5. Whether the conversation reopened recently

That’s the dependency chain. The cause is almost always one of these five.

See also

• Run an SLA 24/7 (ignore office hours)
• Set up channel-specific SLAs
• Opening Hours