> For the complete documentation index, see [llms.txt](https://help.zaapi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.zaapi.com/analytics/sla-breaches.md). # SLA breaches **Customer messages that didn't get a reply within your response-time target.** This page tracks how often you missed your response SLA over the selected period, and which agents the misses fell on. It's period-based like the rest of Analytics and follows the shared rules in How we calculate analytics — but it adds one control the other pages don't have: an **SLA target** you can set right on the page. *** ### The SLA target The **SLA target** (shown as *30 min* in the example) is your response-time goal: the longest a customer message should wait for a human reply before it counts as a breach. You can change it from the control at the top of the page, and every number recalculates against the new target. This is the same threshold concept behind the **Unreplied — SLA breach** card on the Live page. The difference is *when*: Live shows open tickets that are breaching **right now** (real-time triage), while this page reports breaches that happened **over a past period** (historical reporting). *** ### What counts as a breach A **breach** is a customer message that did **not** receive a **human agent** reply within the SLA target. Two things to note about that definition: * **It's about human replies.** Consistent with the rest of Analytics, response-time metrics measure your human team. A message the AI Agent answers in time isn't a breach. * **It looks at every customer message, not just the first.** This is broader than First Response Time (which only measures the opening reply). Here, any customer message that waits longer than the target for a human reply is a breach — so a single conversation can contain more than one. *** ### Message Response SLA Breaches The number of breaches in the period — the count of times a customer message went past the SLA target without a human reply. An increase versus the previous period is shown in red, because more breaches is worse. *** ### Message Response SLA Rate The **share of customer messages that breached** — in the example, 1.1% (23 of 2,113 messages over target). Lower is better, so the figure is green when low; the *change* versus last period is flagged red when it rises. Note this is the **breach rate** (misses), which is the inverse of the **Response Rate** column in the table below (hits). They're two views of the same thing and roughly sum to 100% — a 1.1% breach rate corresponds to a \~98.9% response rate. *** ### Breaches by Agent A per-agent table with a **Team total** row, showing two things for each agent: * **Breaches** — the number of breaches attributed to that agent. These sum to the team total (in the example, 4 + 4 + 2 + 2 + 2 + 0 = 14). * **Response Rate** — the agent's compliance: the share of customer messages they answered within the target. Higher is better; an agent with no breaches shows 100%. *** ### Good to know * **Breach rate vs response rate** — the headline shows breaches (lower is better); the table shows response rate (higher is better). They're inverses. * **This page vs Live** — Live shows tickets breaching *right now*; this page counts breaches over a *past period*. Same SLA target concept. * **Why don't breaches involve the AI Agent?** Breaches measure *human* response times — see *What counts as a breach* above. * **Changing the SLA target** recalculates the whole page against the new goal. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.zaapi.com/analytics/sla-breaches.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.