Schedule icon
Request icon
Return icon
Switch icon
Log icon
SlackIncomingWebhook icon

Freshdesk SLA Breach Sentinel

Read Freshdesk tickets on a schedule, change nothing, and alert Slack when open tickets pass their due time, paging for High and Urgent ones.

Categories
Business

Freshdesk sets a resolution due time and a first-response due time on every ticket from its SLA policies, but a breach only shows up in a view someone has to open. By the time a manager notices, an urgent customer has already waited too long. This blueprint turns a scheduled, read-only call to the Freshdesk Tickets API into an SLA gate: io.kestra.plugin.core.http.Request reads recent tickets, one jq query counts open tickets past their due time and first responses that were escalated, and the result routes to a quiet log, a Slack note, or a Slack page for High and Urgent tickets.

How it works

  1. list_tickets (io.kestra.plugin.core.http.Request) calls GET /api/v2/tickets with updated_since set to the lookback window, per_page=100 and order_by=due_by ascending, using HTTP basic auth with the API key as the username and X as the password, as Freshdesk documents. It is a read: no ticket is changed. Retries cover short network blips, and allowFailed plus allowFailure keep an API error from aborting the flow so it can be reported instead.
  2. summarize_sla (io.kestra.plugin.core.debug.Return) first guards for a missing or non-200 response (UNREACHABLE). Otherwise one jq query keeps tickets in status 2 (Open) or 3 (Pending), counts those whose due_by is earlier than now (UTC) and those with fr_escalated set, counts how many breached tickets have priority 3 (High) or 4 (Urgent), and names the oldest breach. Any High or Urgent breach is CRITICAL, any other breach is WARNING, otherwise HEALTHY.
  3. route_by_sla_state (io.kestra.plugin.core.flow.Switch) branches on that classification: HEALTHY logs quietly, WARNING posts a Slack note, CRITICAL and UNREACHABLE page Slack. A defaults fallback logs anything unexpected.
  4. log_audit_result (io.kestra.plugin.core.log.Log) writes one audit line per run with the HTTP status and the full summary.
  5. The flow-level errors block pages Slack if the flow itself fails, so a broken sentinel is never mistaken for a healthy queue.
  6. The sla_check trigger runs every 30 minutes from 09:00 to 19:00 IST, Monday to Saturday, and ships disabled: true.

What you get

  • A read-only SLA check across open and pending tickets with no custom scripting and no extra plugin to install.
  • A status output (HEALTHY / WARNING / CRITICAL / UNREACHABLE) other flows can gate on.
  • Slack messages with the number of resolution and first-response breaches and the oldest breached ticket, so the team knows where to start.
  • An audit line on every run, separate from Slack.

Who it's for

  • Support teams on Freshdesk who want to hear about an SLA breach while there is still time to fix it.
  • Support managers who report SLA compliance and want the history in one place.
  • Teams that already run alerting in Kestra and want customer support health next to their data and infrastructure checks.

Why orchestrate this with Kestra

Freshdesk's SLA reminders are per ticket and per agent. Kestra turns a plain, read-only API call into a scheduled, typed classification across the whole queue, with retries, a failure path and an execution history, and the Switch branch is ready to grow into real actions (reassigning a group, opening an incident) without rewriting the check.

Prerequisites

  • A Freshdesk account (the free plan includes API access) and an agent API key from Profile settings > View API key.
  • SLA policies configured in Freshdesk so tickets carry due_by and fr_due_by.
  • A Slack incoming webhook for the WARNING, CRITICAL, UNREACHABLE and flow-failure alerts.

Secrets

  • FRESHDESK_DOMAIN: the subdomain only, for example acme for acme.freshdesk.com.
  • FRESHDESK_API_KEY: the agent API key.
  • SLACK_WEBHOOK: Slack incoming webhook used for every alert branch and the flow-failure alert.

In Kestra OSS, secrets are supplied as environment variables prefixed SECRET_ and base64-encoded, for example SECRET_FRESHDESK_DOMAIN=$(echo -n 'acme' | base64), and read back with {{ secret('FRESHDESK_DOMAIN') }}. Use the Enterprise secrets backend for encryption at rest and access control.

Quick start

  1. Create a free Freshdesk account and copy your API key.
  2. Add FRESHDESK_DOMAIN, FRESHDESK_API_KEY and SLACK_WEBHOOK as secrets.
  3. Create a test ticket with priority Urgent and a due time a few minutes away (or edit the due time on an existing ticket), wait until it passes, and run the flow manually: status should be CRITICAL.
  4. Enable sla_check.

How to extend

  • Page through more than 100 tickets with the page parameter.
  • Filter by group_id with the Filter Tickets API to run one sentinel per support team.
  • Store the breached ticket IDs in a KV store and alert only on new breaches.
  • Add a Request that sets a tag or reassigns breached tickets, behind an approval step.

Inputs

  • lookback_days: type INT, default 30.

Outputs

  • status: one of HEALTHY, WARNING, CRITICAL, UNREACHABLE.
  • Example path: {{ fromJson(outputs.summarize_sla.value).oldest_breach }} for the oldest breached ticket.

Links

Pitfalls

  • per_page is capped at 100. Tickets are sorted by due_by ascending, so the most overdue ones come first, but a queue with more than 100 recently updated tickets needs paging to see all of them.
  • An open ticket that has not been updated within lookback_days is not returned; keep the window at least as long as your longest SLA.
  • due_by is compared with the current time in UTC; Freshdesk returns timestamps in UTC, so time zones do not shift the result.
  • This flow only reads; it never replies to, updates or closes a ticket.
See How

New to Kestra?

Use blueprints to kickstart your first workflows.