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. Three 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 workspace’s opening hours actually configured?

Open Settings → Opening Hours. Confirm:

• 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 Manual Executions section of any SLA-triggered automation will reference the policy ID.

4. Less common — the conversation reopened mid-night

When a conversation moves from done back to active (because the customer replied), each tracked metric’s timer restarts — including for Resolution Time. 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 workspace’s Opening Hours definition for the date range that breached
4. Whether the conversation reopened recently

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

See also

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