> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# SLAs, SLOs & SLIs

> Set remediation deadlines per severity, get notified when issues age past them, and track compliance over time

## Overview

SLA policies let your team hold remediation to measurable deadlines. You define how
many days an open issue of each severity may remain unresolved; ZeroPath then watches
your issues, **notifies the right people when an issue ages past its threshold**, and
tracks how well you are meeting those targets over time.

The feature has three layers:

| Layer               | Question it answers                                                | Where you see it               |
| ------------------- | ------------------------------------------------------------------ | ------------------------------ |
| **SLA** (policy)    | "How fast must we fix issues of each severity?"                    | Settings → SLA → Policies      |
| **SLO** (objective) | "What compliance % are we targeting, and are we on track?"         | Settings → SLA → SLO Dashboard |
| **SLI** (indicator) | "What is the measured compliance and time-to-resolve, day by day?" | SLO Dashboard charts           |

Open **Settings → SLA** to find four tabs: **Overview**, **Policies**, **SLO Dashboard**,
and **Audit Trail**.

<Info>
  SLA evaluation runs on open issues only. Resolved, archived, and ephemeral-repository
  issues are out of scope, so closing an issue stops its SLA clock.
</Info>

## Creating an SLA policy

<Steps>
  <Step title="Open the policy wizard">
    Go to **Settings → SLA → Policies** and choose **New policy** (or start from a
    **template** for common configurations).
  </Step>

  <Step title="Set severity thresholds">
    Give each severity a deadline in days — for example, Critical = 7, High = 14,
    Medium = 30. An issue breaches when it has been open longer than its severity's
    threshold. (Severities are derived from each issue's score/confidence; INFO is not
    eligible for SLA thresholds.)
  </Step>

  <Step title="Choose scope">
    Apply the policy to **all repositories** or scope it to specific **repositories**
    and/or **tags**.
  </Step>

  <Step title="Pick notification channels">
    Select **Slack** channels and/or **webhooks** to receive breach notifications.
  </Step>

  <Step title="(Optional) Add escalation steps and an SLO target">
    Add escalation steps that bring in additional channels at later day offsets, and
    set an SLO compliance target to track on the dashboard.
  </Step>
</Steps>

### Severity thresholds

A threshold is the maximum number of days (1–365) an open issue of that severity may
remain unresolved before it is considered breaching. The breach clock starts at the
issue's lifecycle start — the moment it (re)entered an open state — so a closed issue
that is later reopened starts a fresh clock.

### Scope: repositories and tags

A policy applies org-wide by default, or to a chosen set of repositories and tags. Tag
scope follows the repositories currently in each tag, so adding a repo to a tag
automatically brings it under any policy scoped to that tag.

### Policy hierarchy

Policies can be organized into a parent/child hierarchy (up to five levels deep). A
child policy may only **tighten** its parent's thresholds — never loosen them — so an
org-wide baseline can be made stricter for a critical team without letting any team
fall below the baseline.

<Note>
  When a parent's thresholds change, child policies are recomputed automatically and any
  newly tightened severities are backfilled, so the hierarchy stays consistent.
</Note>

### Templates

Templates pre-fill a policy with sensible thresholds and channels for common needs so
you can stand up a policy in one step and adjust from there.

## Notifications

Once a policy exists, ZeroPath sweeps your open issues **every hour** and sends one
**grouped digest** per `(policy, severity, threshold)` to the policy's channels — so a
batch of newly breached Critical issues produces a single "N issues breached" message
rather than one message per issue.

* **Slack** — posts a Block Kit digest to each configured channel.
* **Webhooks** — delivers an `ISSUE_AGED_PAST_THRESHOLD` event (see [Webhooks](/webhook/introduction)).

Delivery is idempotent and de-duplicated across deploys, and failed channels are
retried on later sweeps, so an outage delays a notification rather than dropping it.

### Escalation steps

Each policy can define escalation steps, each with a **day offset** and its own set of
Slack channels and webhooks. When an issue ages to a step's offset, that step's
channels are added to the notification — letting you widen the audience (for example,
looping in a manager at day 14) the longer an issue stays open.

<Info>
  Escalation steps deliver to their own channels regardless of the policy's base channel
  selection, so a step can introduce a channel the base policy didn't use.
</Info>

## Due dates on exported tickets

When a finding is exported to Jira or Linear, ZeroPath can stamp the ticket with the
finding's SLA deadline as its **due date**, so engineers see the remediation deadline
right in their tracker.

Turn on **Set due date from SLA** in the Jira or Linear auto-ticketing settings
(**Settings → Integrations → Jira/Linear → Auto-Ticketing**). When enabled, every ticket
that integration creates — automatically on scan completion, or manually from a finding —
gets a due date equal to the issue's **tightest in-scope SLA deadline**: the earliest
breach date across every policy that covers the issue, using the same breach definition as
the sweep and SLO dashboard.

* If no SLA policy covers the finding, no due date is set.
* The due date is stamped once, when the ticket is created; later policy edits don't move
  an existing ticket's due date.
* A finding already past its deadline at export time gets a due date in the past (shown as
  overdue), because the SLA clock starts when the issue opened.

<Note>
  For Jira, the due date is only applied when the selected issue type exposes a **Due date**
  field on its create screen. If it doesn't, ZeroPath warns you when you save the config and
  creates tickets without a due date rather than failing the export.
</Note>

## SLO Dashboard

The **SLO Dashboard** turns SLA activity into a trend. Set an SLO on a policy by giving
it a **target compliance percentage** (50–100%) and an **evaluation window** (1–730
days); the dashboard then shows, per policy:

| Metric                        | Meaning                                                                     |
| ----------------------------- | --------------------------------------------------------------------------- |
| **Compliance %**              | Share of in-scope issues currently within their SLA                         |
| **Breach count**              | Number of in-scope issues currently breaching                               |
| **P50 / P95 time-to-resolve** | Median and 95th-percentile days to resolve                                  |
| **Burn rate**                 | How fast the error budget (the allowed share of breaches) is being consumed |

These come from **SLI snapshots** — a point-in-time measurement ZeroPath records once a
day per policy (and per tag), so the charts build up a daily history of compliance,
breach counts, and resolution latency.

### Burn rate

Burn rate expresses how quickly you are using up your error budget — the slack between
100% and your target. A burn rate above **1×** means you are breaching faster than the
target allows. ZeroPath surfaces two levels and, when configured, sends an
`SLA_BURN_RATE_HIGH` notification:

| Level    | Meaning                                                               |
| -------- | --------------------------------------------------------------------- |
| **WARN** | The 7-day window is consuming budget faster than sustainable          |
| **HIGH** | The 14-day window is well over budget — the target is at serious risk |

<Note>
  Burn rate is suppressed for very low-volume policies, where a single breach would swing
  the percentage and produce noisy alerts.
</Note>

## Compliance reports

From a policy you can generate an **SLA compliance report** (PDF, CSV, or JSON) for an
audit or stakeholder review. The report uses the **same breach definition** as the live
sweep and dashboard, so the numbers always agree. See [Reports](/platform/reports) for
report generation and export.

## Audit Trail

The **Audit Trail** tab records each hourly sweep run and the individual dispatch
attempts it made — which channel, the outcome, and any error — so you can confirm a
notification was sent and diagnose a delivery problem.

## Driving automations from SLA events

SLA events can trigger AI agent automations. Configure an agent event trigger for the
`ISSUE_AGED_PAST_THRESHOLD` or `SLA_BURN_RATE_HIGH` event to, for example, automatically
open a remediation task or post a prioritized plan when a breach group fires. Triggers
scoped to specific repositories or tags match when any repository in a breach group is
in scope.

## How it runs

SLA evaluation is fully automated by background jobs — there is nothing to run yourself:

| Job                                             | Schedule |
| ----------------------------------------------- | -------- |
| Aged-issue sweep + notifications                | Hourly   |
| SLI snapshot + burn-rate evaluation             | Daily    |
| Retention cleanup of old sweep/dispatch records | Daily    |

<Warning>
  Because thresholds are measured in whole days, a policy change takes effect on the next
  hourly sweep, and new SLO compliance points appear after the next daily SLI snapshot.
</Warning>