SLA Breach Monitoring

skill

Run a recurring sweep of open tickets against SLA targets and escalate approaching or blown breaches.

Download .md

SLA Breach Monitoring

Run a recurring sweep of open support tickets against SLA (service level agreement — the target response/resolution time) targets, and escalate anything approaching or already past its deadline.

When to use

  • You need a standing job that regularly checks open tickets for SLA risk instead of relying on agents to notice manually.
  • A customer's ticket is nearing its response or resolution deadline and needs a nudge before it breaches.
  • A ticket has already blown its SLA and requires immediate escalation to a human or a specialist agent.
  • Leadership wants a running log of breach risk so nothing slips through silently.

Tools

  • http-get
  • schedule-task
  • send-message
  • create-task

Playbook

  1. Use schedule-task to set up a recurring sweep (e.g. every 15-30 minutes) that triggers this playbook automatically.
  2. On each run, call http-get against the helpdesk's REST API to pull open tickets, e.g. GET https://api.helpdesk.example.com/v1/tickets?status=open. Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
  3. For each ticket returned, read its SLA target and elapsed time fields (or fetch ticket detail via http-get if the list response omits them, e.g. GET https://api.helpdesk.example.com/v1/tickets/{id}).
  4. Compare elapsed time to the SLA target from the org knowledge base for that ticket's priority tier. Do not invent SLA policy — if the knowledge base has no defined target for a ticket's tier or category, treat it as a human handoff rather than guessing.
  5. For tickets within the warning window (e.g. 80% of SLA time consumed) but not yet breached, use send-message to notify the assigned agent or team channel that the deadline is approaching.
  6. For tickets that have already breached SLA, use create-task to open an escalation task assigned to the on-call lead or support manager, including the ticket ID, customer, and how long it has been overdue.
  7. If a ticket update requires changing its priority, status, or owner via the helpdesk API (PUT/PATCH/DELETE), use http-request — do not attempt this with http-get.
  8. If the helpdesk API returns 401/403, or no Integration row exists for the host, stop and use send-message to alert a human, naming the service and the scopes needed.
  9. If any customer-facing reply is drafted as part of an escalation, route it for human review before sending, unless the org has explicitly opted into auto-send.

Failure modes

  • Helpdesk API pagination is not fully walked, so tickets on later pages are silently skipped from the sweep.
  • SLA targets differ by plan tier or region and the org knowledge base is ambiguous or missing an entry, leading to a wrong or skipped escalation — always defer to a human when the policy is unclear.
  • Duplicate escalation tasks get created on every sweep because a ticket's breached state isn't checked against previously created tasks.
  • Time zone or business-hours handling (e.g. SLA clocks pausing outside support hours) is ignored, causing false breach alerts.

Done when

  • Every open ticket has been checked against its SLA target for the current sweep cycle.
  • Approaching-breach tickets have a send-message notification on record, and breached tickets have a corresponding create-task escalation.
  • No sweep run fails silently on an auth error without a human being alerted via send-message.