Freshdesk SLA Policies & Business Hours
Overview
SLA policies define the response and resolution targets a Freshdesk account
commits to, and business-hours calendars define when the SLA clock runs.
Together they compute each ticket's fr_due_by (first-response deadline) and
due_by (resolution deadline). This skill covers listing policies and
calendars and reasoning about deadlines and breaches through tools named
freshdesk_sla_list and freshdesk_business_hours_list.
Anti-triggers
A Freshdesk SLA policy is helpdesk configuration that computes ticket
deadlines. It is not the commercial SLA in a signed agreement, and not an
on-call response target.
- The SLA a contract commits you to — coverage hours, response
credits, and the agreement the customer signed are
halopsa-contracts
or autotask-contracts. Freshdesk's policy is how the
helpdesk approximates that commitment; the two can legitimately
disagree.
- MTTA/MTTR for on-call responders — those measure how fast a page
was answered, not helpdesk SLA attainment; use
pagerduty-analytics.
- Escalation rotas and who is on-call after hours — coverage windows
here only pause a clock; they do not page anyone. Use
pagerduty-oncall.
- Acting on a breached ticket — re-prioritising, reassigning, or
replying is
freshdesk-ticketing; this skill explains the deadline,
it does not change it.
SLA Policies
List SLA Policies
GET /api/v2/sla_policies
Each policy describes targets per priority and the conditions under which it
applies.
Key SLA Policy Fields
| Field |
Type |
Description |
id |
Integer |
Unique identifier |
name |
String |
Policy name |
is_default |
Boolean |
Applies when no other policy matches |
active |
Boolean |
Whether the policy is in force |
applicable_to |
Object |
Conditions (company, group, source) that select the policy |
sla_target |
Object |
Targets keyed by priority |
escalation |
Object |
Who is notified, and when, as deadlines approach or pass |
SLA Targets by Priority
Targets are defined per priority level (recall the encodings: 1 Low, 2 Medium,
3 High, 4 Urgent). Each target typically specifies:
| Target |
Drives |
Description |
respond_within |
fr_due_by |
Time allowed for the first agent response |
resolve_within |
due_by |
Time allowed to resolve the ticket |
business_hours |
clock mode |
Whether the target counts only business hours or calendar (24x7) time |
escalation_enabled |
escalations |
Whether breach/approach escalations fire |
Higher-priority tickets get tighter targets — an Urgent (4) ticket usually has
a much shorter respond_within and resolve_within than a Low (1) ticket.
Business Hours
List Business Hours
GET /api/v2/business_hours
Each calendar defines the working week, daily hours, time zone, and holidays.
Key Business-Hours Fields
| Field |
Type |
Description |
id |
Integer |
Unique identifier |
name |
String |
Calendar name |
is_default |
Boolean |
Default calendar for the account |
time_zone |
String |
Time zone the hours are expressed in |
business_hours |
Object |
Working hours per weekday |
holidays |
Array |
Dates excluded from the SLA clock |
How Targets + Business Hours Drive Deadlines
When a ticket is created or its priority changes, Freshdesk selects the
matching SLA policy and computes deadlines:
- Select the policy — match the ticket against each policy's
applicable_to conditions (company, group, source); fall back to the
is_default policy.
- Pick the target — choose the
sla_target entry for the ticket's
priority.
- Choose the clock — if the target uses business hours, the SLA clock
only advances during the calendar's working hours and skips holidays; if it
is 24x7, the clock runs continuously.
- Compute
fr_due_by — created-time plus respond_within, advanced
through the chosen clock.
- Compute
due_by — created-time plus resolve_within, advanced through
the chosen clock.
- Pause on Pending — when a ticket moves to Pending (status 3) awaiting
the customer, the resolution clock can pause depending on policy
configuration, shifting
due_by accordingly.
Urgent (priority 4) ticket created Fri 16:00, business-hours calendar Mon-Fri 09:00-17:00
respond_within = 1h -> fr_due_by = Fri 17:00 (1 business hour)
resolve_within = 8h -> due_by = Mon 15:00 (1h Fri + 7h spilling into Mon)
Breach Detection
To detect breached and at-risk tickets:
- Pull the unresolved queue — search tickets with
status:2 OR status:3.
- Read SLA timestamps — fetch each ticket with
include=stats to get
fr_due_by, due_by, and whether first response / resolution has
occurred.
- Classify against now:
| Condition |
State |
fr_due_by in the past and no first response sent |
First-response breached |
due_by in the past and not resolved |
Resolution breached |
due_by within the next escalation window |
At risk |
| Both deadlines comfortably ahead |
Healthy |
- Prioritize — breached first (longest overdue first), then at-risk
ordered by nearest deadline.
- Escalate — for breached/at-risk tickets, follow the policy's
escalation settings: notify the responsible agent/group, bump priority,
and record an internal note.
Error Handling
| Error |
Cause |
Resolution |
| 404 Not found |
Unknown policy/calendar (or none configured) |
List policies/calendars to confirm what exists |
| 403 Forbidden |
API key lacks admin scope for SLA config |
Use an admin-scoped key to read SLA/business-hours config |
| 400 Bad request |
Malformed include on the ticket fetch |
Use include=stats to retrieve SLA timestamps |
Best Practices
- Map priorities to targets explicitly — translate priority integers to
the policy's targets when explaining deadlines.
- Account for business hours — never assume 24x7; check whether each
target counts business hours and skip holidays accordingly.
- Watch Pending transitions — a paused clock shifts
due_by; recompute
rather than trusting a stale value.
- Drive triage by deadline — order the queue by SLA pressure, not just
raw priority.
Related Skills
1---2name: freshdesk-sla-business-hours3description: Freshdesk SLA policies and business-hours calendars: policy and calendar fields, per-priority respond_within / resolve_within targets, how the business-hours vs 24x7 clock computes a ticket's fr_due_by and due_by, and breach / at-risk detection through the Freshdesk REST API v2.4---56# Freshdesk SLA Policies & Business Hours78## Overview910SLA policies define the response and resolution targets a Freshdesk account11commits to, and business-hours calendars define when the SLA clock runs.12Together they compute each ticket's `fr_due_by` (first-response deadline) and13`due_by` (resolution deadline). This skill covers listing policies and14calendars and reasoning about deadlines and breaches through tools named15`freshdesk_sla_list` and `freshdesk_business_hours_list`.1617## Anti-triggers1819A Freshdesk SLA policy is helpdesk configuration that computes ticket20deadlines. It is not the commercial SLA in a signed agreement, and not an21on-call response target.2223- **The SLA a contract commits you to** — coverage hours, response24 credits, and the agreement the customer signed are `halopsa-contracts`25 or `autotask-contracts`. Freshdesk's policy is how the26 helpdesk approximates that commitment; the two can legitimately27 disagree.28- **MTTA/MTTR for on-call responders** — those measure how fast a page29 was answered, not helpdesk SLA attainment; use `pagerduty-analytics`.30- **Escalation rotas and who is on-call after hours** — coverage windows31 here only pause a clock; they do not page anyone. Use32 `pagerduty-oncall`.33- **Acting on a breached ticket** — re-prioritising, reassigning, or34 replying is `freshdesk-ticketing`; this skill explains the deadline,35 it does not change it.3637## SLA Policies3839### List SLA Policies4041```http42GET /api/v2/sla_policies43```4445Each policy describes targets per priority and the conditions under which it46applies.4748### Key SLA Policy Fields4950| Field | Type | Description |51|-------|------|-------------|52| `id` | Integer | Unique identifier |53| `name` | String | Policy name |54| `is_default` | Boolean | Applies when no other policy matches |55| `active` | Boolean | Whether the policy is in force |56| `applicable_to` | Object | Conditions (company, group, source) that select the policy |57| `sla_target` | Object | Targets keyed by priority |58| `escalation` | Object | Who is notified, and when, as deadlines approach or pass |5960### SLA Targets by Priority6162Targets are defined per priority level (recall the encodings: 1 Low, 2 Medium,633 High, 4 Urgent). Each target typically specifies:6465| Target | Drives | Description |66|--------|--------|-------------|67| `respond_within` | `fr_due_by` | Time allowed for the first agent response |68| `resolve_within` | `due_by` | Time allowed to resolve the ticket |69| `business_hours` | clock mode | Whether the target counts only business hours or calendar (24x7) time |70| `escalation_enabled` | escalations | Whether breach/approach escalations fire |7172Higher-priority tickets get tighter targets — an Urgent (4) ticket usually has73a much shorter `respond_within` and `resolve_within` than a Low (1) ticket.7475## Business Hours7677### List Business Hours7879```http80GET /api/v2/business_hours81```8283Each calendar defines the working week, daily hours, time zone, and holidays.8485### Key Business-Hours Fields8687| Field | Type | Description |88|-------|------|-------------|89| `id` | Integer | Unique identifier |90| `name` | String | Calendar name |91| `is_default` | Boolean | Default calendar for the account |92| `time_zone` | String | Time zone the hours are expressed in |93| `business_hours` | Object | Working hours per weekday |94| `holidays` | Array | Dates excluded from the SLA clock |9596## How Targets + Business Hours Drive Deadlines9798When a ticket is created or its priority changes, Freshdesk selects the99matching SLA policy and computes deadlines:1001011. **Select the policy** — match the ticket against each policy's102 `applicable_to` conditions (company, group, source); fall back to the103 `is_default` policy.1042. **Pick the target** — choose the `sla_target` entry for the ticket's105 `priority`.1063. **Choose the clock** — if the target uses business hours, the SLA clock107 only advances during the calendar's working hours and skips holidays; if it108 is 24x7, the clock runs continuously.1094. **Compute `fr_due_by`** — created-time plus `respond_within`, advanced110 through the chosen clock.1115. **Compute `due_by`** — created-time plus `resolve_within`, advanced through112 the chosen clock.1136. **Pause on Pending** — when a ticket moves to Pending (status 3) awaiting114 the customer, the resolution clock can pause depending on policy115 configuration, shifting `due_by` accordingly.116117```text118Urgent (priority 4) ticket created Fri 16:00, business-hours calendar Mon-Fri 09:00-17:00119 respond_within = 1h -> fr_due_by = Fri 17:00 (1 business hour)120 resolve_within = 8h -> due_by = Mon 15:00 (1h Fri + 7h spilling into Mon)121```122123## Breach Detection124125To detect breached and at-risk tickets:1261271. **Pull the unresolved queue** — search tickets with `status:2 OR status:3`.1282. **Read SLA timestamps** — fetch each ticket with `include=stats` to get129 `fr_due_by`, `due_by`, and whether first response / resolution has130 occurred.1313. **Classify against now:**132133| Condition | State |134|-----------|-------|135| `fr_due_by` in the past and no first response sent | First-response breached |136| `due_by` in the past and not resolved | Resolution breached |137| `due_by` within the next escalation window | At risk |138| Both deadlines comfortably ahead | Healthy |1391404. **Prioritize** — breached first (longest overdue first), then at-risk141 ordered by nearest deadline.1425. **Escalate** — for breached/at-risk tickets, follow the policy's143 `escalation` settings: notify the responsible agent/group, bump priority,144 and record an internal note.145146## Error Handling147148| Error | Cause | Resolution |149|-------|-------|------------|150| 404 Not found | Unknown policy/calendar (or none configured) | List policies/calendars to confirm what exists |151| 403 Forbidden | API key lacks admin scope for SLA config | Use an admin-scoped key to read SLA/business-hours config |152| 400 Bad request | Malformed include on the ticket fetch | Use `include=stats` to retrieve SLA timestamps |153154## Best Practices155156- **Map priorities to targets explicitly** — translate priority integers to157 the policy's targets when explaining deadlines.158- **Account for business hours** — never assume 24x7; check whether each159 target counts business hours and skip holidays accordingly.160- **Watch Pending transitions** — a paused clock shifts `due_by`; recompute161 rather than trusting a stale value.162- **Drive triage by deadline** — order the queue by SLA pressure, not just163 raw priority.164165## Related Skills166167- [Freshdesk Ticketing](../ticketing/SKILL.md) - due_by / fr_due_by live on tickets; triage by SLA168- [Freshdesk API Patterns](../api-patterns/SKILL.md) - Search and include parameters for SLA stats169- [Freshdesk Contacts & Companies](../contacts-companies/SKILL.md) - Company/tier conditions that select SLA policies