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