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.

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.

Creating an SLA policy

1. Open the policy wizard

   Go to Settings → SLA → Policies and choose New policy (or start from a template for common configurations).

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

3. Choose scope

   Apply the policy to all repositories or scope it to specific repositories and/or tags.

4. Pick notification channels

   Select Slack channels and/or webhooks to receive breach notifications.

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

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.

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

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

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.

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.

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.

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.

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

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

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

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.