Freshdesk SLA Not Calculating Correctly: Fixes

First, understand what the timer is actually counting

Before you debug anything, it helps to know what the number on the ticket represents. A Freshdesk SLA is a target attached to a priority — Urgent, High, Medium, or Low — and every policy defines separate targets for first response time, resolution time, and (on higher tiers) every response time. Those targets live under Admin → Workflows → SLA Policies, and each policy can be calculated one of two ways, which is where most confusion begins.

The two modes matter enormously:

• Calendar hours (24×7): the clock runs continuously — nights, weekends, holidays, all of it. A one-hour first-response target means sixty real minutes no matter when the ticket lands.
• Business hours: the clock only runs during your configured working hours. A ticket that arrives at 6 PM on Friday, with a one-hour target, isn't due until an hour into Monday morning.

If your policy uses business hours and you're reading the timer as if it's counting real elapsed time, every ticket will look wrong. It isn't — it's pausing overnight and on weekends exactly as designed. Freshworks documents both modes in Understanding SLA Policies, and it's the single most common reason a timer seems broken.

Fix 1: Confirm which business-hours calendar the ticket is using

Here's the subtlety that catches even experienced admins. In business-hours mode, a ticket doesn't use one global calendar — it inherits the business hours of the group it's assigned to. If the ticket has no group, it falls back to your default business hours. Freshworks spells this out in What are business hours and calendar hours?: a ticket "automatically inherits that group's business hours," and with no group it "defaults to the business hours" of your account.

So a ticket assigned to your EMEA group is timed against EMEA working hours; the same ticket routed to a 24/7 group is timed differently. If two identical tickets show different due-by times, the group assignment — not the SLA policy — is usually the reason.

To check and fix:

1. Open the ticket and note its assigned group.
2. Go to Admin → Team → Business hours and open the calendar attached to that group.
3. Confirm the working days, hours, and timezone match what you expect.
4. Check the Holidays tab — holidays are excluded from business-hours calculations, so a target that spans a holiday will legitimately extend.

A single mis-set timezone on one group's calendar will make every ticket in that queue look off by hours.

Fix 2: Priority and group changes recalculate from ticket creation

This one surprises almost everyone. When you change a ticket's priority — or reassign it to a different group — Freshdesk doesn't start a fresh SLA countdown from that moment. It recalculates the SLA against the ticket's original created time.

Play that out. A Low-priority ticket comes in Monday at 9 AM with a 24-hour resolution target. On Tuesday at 3 PM an agent bumps it to Urgent, whose target is 4 hours. Freshdesk now applies the 4-hour Urgent target from Monday 9 AM — which is already long past. The ticket flips to breached the instant you change the priority, even though a human only just touched it. Nothing is broken; the timer is anchored to creation, not to the change.

The fix here is process, not configuration:

• Set priority correctly at intake so you're not re-triaging into a breach later. A good first-response and routing decision up front is worth more than any timer tweak.
• Know that escalation-by-priority is retroactive and communicate that to your team, so an "instant breach" after a priority bump doesn't look like a bug.
• If you genuinely need timers that restart on reassignment, that's a workflow requirement Freshdesk's native SLA engine won't satisfy on its own — plan for it rather than fighting the timer.

If you're building policies from scratch and want the anchoring behaviour laid out end to end, our walkthrough on how to set up SLA policies in Freshdesk covers the full setup.

Fix 3: The day-based SLA change (1 day now means 24 business hours)

If your targets are defined in days and the math suddenly stopped matching your intuition, this is likely why. Freshworks changed how day-based SLAs behave in business-hours mode: a target of "1 day" is now interpreted as 24 business hours, not "the working hours in one business day." So if your business day is 8 hours, a 1-day target now accumulates across three working days until it reaches 24 business hours — roughly triple what many admins assumed.

Freshworks documents this in Upcoming changes to day-based SLAs in Business hours. The recommended fix is straightforward: convert any day-based targets to explicit hours so there's no ambiguity. If you meant "resolve within one 8-hour working day," set the target to 8 hours, not 1 day. Auditing your policies for day-based targets and rewriting them in hours removes an entire class of "why is this due three days out?" tickets.

Fix 4: Check which policy is actually winning

You can have several SLA policies, each with its own conditions (company, group, ticket type, source). But only one applies to a given ticket, and the rule is simple: the first policy in the ordered list whose conditions match is the one that's used. A more specific policy sitting below a broad catch-all will never fire, because the broad one matched first.

To fix a ticket that's using the "wrong" targets:

1. Go to Admin → Workflows → SLA Policies and read the list top to bottom.
2. Identify the first policy whose conditions match the ticket in question.
3. If that's not the policy you intended, reorder — drag the more specific policy above the broad one.

Multiple SLA policies are a Pro-plan-and-up feature; on lower tiers you have a single default policy, which removes this ambiguity entirely but also removes the flexibility. Match precedence to your real routing and the timers line up.

Fix 5: Reminders and escalations fire on their own schedule

Sometimes the timer is right but the notifications feel wrong — a reminder lands when you didn't expect it, or an escalation email never arrives. On Pro and above, reminders can be set from 5 minutes to 4 hours before an SLA breach, and escalations can be configured to trigger from immediately (5 minutes) up to a month after a breach. If a reminder seems mistimed, it's measuring against the same business-hours-adjusted due-by you verified above — so an overnight pause shifts the reminder too. And escalation emails are governed separately under Admin → Email notifications → Agent Notifications; if agents aren't getting them, the notification toggle, not the SLA policy, is usually the culprit.

The honest limits — and where an AI layer helps

Freshdesk's SLA engine is genuinely good at what it does. Once you understand business hours, the creation-time anchor, and policy ordering, it's precise, deterministic, and dependable — and for most teams the native feature is all the SLA machinery you'll ever need. Credit where it's due: the calculations aren't wrong, they're just easy to misread.

What the SLA engine can't do is anything to actually hit the target. A timer is a scoreboard, not a player. It can tell you a first response is due in fifteen minutes; it can't read the ticket, understand the intent, and draft that response. It can't pull an order status from your backend to resolve a shipping question before the resolution clock runs out. That gap — between measuring the deadline and meeting it — is where an AI agent layer earns its place, and it's worth being clear-eyed about the build-versus-buy tradeoff before you commit to either.

Macha runs on top of the Freshdesk you already use — it's not a help desk replacement, and it doesn't touch your SLA policies or business hours. You connect Macha to Freshdesk with your subdomain and API key, and it works the same tickets your SLAs already govern: drafting or posting first replies grounded in your help center, triaging by intent rather than keyword, and looking up account or order data through a custom tool that turns any REST API into something the agent can call. The category of AI agents for customer service exists precisely to do the reasoning-heavy work that keeps first-response and resolution timers green — so the SLA you configured actually gets met, not just measured. Because Macha bills per AI action rather than per outcome, you can see the pricing up front, and the Freshdesk connector page covers exactly what it reads and writes.

FAQ

Why is my Freshdesk SLA timer showing a longer due-by time than my target? Almost always because the policy is set to business hours, not calendar hours. In business-hours mode the clock pauses overnight, on weekends, and on holidays, so a target of "1 day" or "4 hours" spreads across your working schedule rather than real elapsed time. Check the policy's calculation mode under Admin → Workflows → SLA Policies, and confirm which group's business-hours calendar the ticket inherited.

Why did my ticket breach SLA the moment I changed its priority? Because Freshdesk recalculates the SLA from the ticket's original created time, not from the moment you changed the priority. Bumping a two-day-old ticket to Urgent applies the shorter Urgent target retroactively to when the ticket was created, which can already be past due. Set priority correctly at intake to avoid re-triaging into a breach.

Why does "1 day" in my SLA now behave differently? Freshworks changed day-based SLAs so that 1 day now means 24 business hours rather than one working day's worth of hours. If your business day is 8 hours, a 1-day target now spans three working days. Convert day-based targets to explicit hours to remove the ambiguity.

Which SLA policy applies when I have several? The first policy in the ordered list whose conditions match the ticket wins. If a specific policy sits below a broad catch-all, the broad one fires first and the specific one never applies. Reorder policies so the most specific ones sit at the top. Multiple SLA policies are available from the Pro plan onward.

Can AI help me actually meet SLA targets, not just measure them? Yes — but not by changing the timer. An AI agent layer like Macha connects to Freshdesk as a native connector (Freshdesk specifically, not Freshchat, Freshservice, or Freshcaller) and does the reasoning-heavy work of drafting and posting first replies, triaging by intent, and resolving lookups from your systems — the things that keep first-response and resolution clocks from slipping. It runs on top of your existing help desk and leaves your SLA configuration untouched.

Ready to keep your Freshdesk SLAs green instead of just watching them tick? Start a free trial and connect Macha to your Freshdesk in minutes.