48.9k Log in Get started
Metric · Support

What is SLA breach rate, and how do you measure it in Metabase?

SLA breach rate is the share of tickets that missed a service-level target — first response or resolution — divided by tickets that carried an SLA. It's the metric that turns response-time promises into a pass/fail score. Track it in Metabase from help desk SLA events synced into a database (Zendesk, Freshdesk, Intercom, or Jira Service Management).

TL;DR — breached ÷ tickets with an SLA per policy per month, on the clock the SLA was promised in (usually business hours, paused while pending on the customer). Report it broken down by policy and priority — the overall rate hides exactly the segments that matter.

What does an SLA breach rate chart look like in Metabase?

Chart breached SLA targets as a share of tickets carrying an SLA per month, per policy. The steady decline is staffing and routing work showing up in the number your contracts actually care about, while a spike like February's almost always means volume outran staffing for a stretch — read it against ticket volume before touching the targets.

SLA breach rate in Metabase: a line chart of monthly first-response breach percentage.
SLA breach rate as a Metabase card, built from synced help desk SLA events. Figures are illustrative.

What SLA breach rate measures

It measures kept promises. Unlike first-response time or resolution time, which describe the distribution of waits, breach rate scores each ticket against the specific target it was promised — 1 hour for urgent chat, 8 business hours for normal email — and reports the failure share. That makes it the right number for contracts, QBRs, and staffing decisions.

The distinction matters because averages hide tails. A team can post a perfectly acceptable mean response time while a stubborn slice of tickets blows through targets by days — and that slice is where escalations, churn, and credits come from. Breach rate puts the tail on the chart.

Always segment by policy and priority. Each SLA policy is a different promise to a different audience, and rolling them into one number lets a flood of easy low-priority passes bury the urgent-tier failures. A per-policy view alongside ticket volume also shows whether breaches track workload or process.

What data does it need?

  • An SLA events table with one row per ticket per target: policy_name, metric (first response or resolution), target_minutes, and outcome (achieved, breached, or still running).
  • Elapsed time on the SLA clock — business-hours minutes with pending-customer pauses already excluded, as help desks compute it. Deriving this from raw timestamps means rebuilding schedules and holiday calendars; avoid it if the source provides the number.
  • priority and ticket attributes (channel, plan tier) for breakdowns.
  • For early warning: elapsed time on open tickets, refreshed frequently enough to act on.

SQL patterns

Monthly breach rate by policy and priority PostgreSQL

Completed SLA cycles only — the share that ended in a breach, per promise.

-- Monthly breach rate by SLA policy and priority.
-- One row per ticket per SLA target in sla_events; breached is set
-- when the (business-hours) clock ran past the target.
SELECT
  date_trunc('month', s.applied_at) AS month,
  s.policy_name,
  s.priority,
  COUNT(*) AS tickets_with_sla,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE s.breached)
    / NULLIF(COUNT(*), 0), 1
  ) AS breach_rate_pct
FROM sla_events s
WHERE s.metric = 'first_response'
  AND s.status IN ('achieved', 'breached')
GROUP BY 1, 2, 3
ORDER BY 1, 2, 3;
Near-breach early warning PostgreSQL

Open tickets that have used 80% or more of their SLA budget — the queue to work next.

-- Early warning: open tickets that have burned 80%+ of their
-- SLA budget but haven't breached yet. Paused (pending-customer)
-- time is already excluded from elapsed_business_minutes.
SELECT
  s.ticket_id,
  s.policy_name,
  s.priority,
  s.metric,
  s.target_minutes,
  s.elapsed_business_minutes,
  ROUND(
    100.0 * s.elapsed_business_minutes
    / NULLIF(s.target_minutes, 0), 0
  ) AS budget_used_pct
FROM sla_events s
WHERE s.status = 'running'
  AND s.elapsed_business_minutes >= 0.8 * s.target_minutes
ORDER BY budget_used_pct DESC;

Pitfalls

Judging the SLA on the wrong clock. → A business-hours promise measured in calendar time turns every weekend ticket into a false breach, and the reverse under-reports. Use the elapsed time your help desk computes against the policy's own schedule.
Letting the clock run while waiting on the customer. → Resolution SLAs must pause in pending-customer and on-hold states, or slow customers read as agent failures. But audit pending usage — parking tickets there is the standard way to game this metric.
Reporting one blended breach rate. → A 3% overall rate can hide a 20% rate on urgent enterprise tickets. Break it down by policy and priority; the blended number is trivia, the breakdown is the metric.
Counting still-open tickets as passes. → A ticket that hasn't breached yet isn't an achievement. Compute the rate over completed SLA cycles, and track running tickets separately as the near-breach queue.

Where this metric applies

  • Zendesk + Metabase — ticket metric events carry per-target business-hours elapsed time and breach flags
  • Freshdesk + Metabase — SLA policies per group and priority, with pending states pausing the clock
  • Intercom + Metabase — conversation SLA states for first reply and next reply targets
  • Jira + Metabase — Jira Service Management SLA cycles with goal, elapsed, and breached fields

Metrics

First-response time Resolution time First contact resolution rate Ticket volume

Dashboards and analytics

Support analytics Overview SLA & response-time dashboard Support overview dashboard Agent performance dashboard

FAQ

Why track breach rate instead of average response time?
Because a fine average can hide a fat breach tail. A queue that answers most tickets in one hour but leaves 8% hanging for three days shows a healthy mean and a terrible breach rate — and those 8% are the customers who escalate. Averages also can't express the promise: an SLA is a threshold, so the honest metric is the share of tickets that crossed it. Keep first-response time percentiles for diagnosis, and report breach rate for accountability.
Business hours or calendar hours?
Measure with the same clock the SLA was promised in. A 4-business-hour target evaluated against calendar time makes every Friday-evening ticket a false breach; the reverse quietly under-reports on a 24/7 plan. Most help desks compute business-hours elapsed time for you — sync their SLA event tables rather than recomputing timestamp differences, because rebuilding holiday calendars and per-team schedules in SQL is where these numbers usually go wrong.
What about time waiting on the customer?
Pause the clock. Resolution SLAs should stop accruing while a ticket sits in a pending-customer or on-hold state and resume when the customer replies — otherwise slow customers show up as agent breaches. Help desk SLA engines handle this natively and expose the paused-adjusted elapsed time in their event data. If you must model it yourself, sum only the in-progress status intervals; and audit pending usage occasionally, since parking tickets in pending is the classic way to game the metric.
What's an acceptable SLA breach rate?
Whatever your contracts and support tiers say — many teams run at 2% to 5% overall, tighter on urgent priorities. The global number matters less than the breakdown: a 3% overall rate can hide a 20% rate on enterprise urgent tickets, which is where the money and the escalations are. Set a target per policy and priority, and watch the trend against ticket volume, since breach rates usually spike when volume outruns staffing.
How do you track SLA breach rate in Metabase?
Sync your help desk's SLA event data into a SQL database with a tool like Airbyte or Fivetran — Zendesk ticket metric events, Freshdesk SLA policies, or Jira Service Management SLA cycles all work. Model one row per ticket per SLA target with the policy, priority, target, elapsed business time, and outcome, then chart the monthly breach rate per policy and a near-breach list, and pin both to an SLA and response-time dashboard.