# 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`.