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:
Open Settings → Service levels to find four sections: Overview, Policies, Audit trail, and SLO / SLI.
The Overview tab provides a high-level snapshot of SLA activity across your organization. It shows two summary metrics:
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.An issue also only enters SLA scope once a scan of code that has landed has
detected it — a full scan, a standalone/scheduled SCA scan, or the scan of a pull
request that was merged into the repository’s default branch. Findings reported
solely by a pull request that is still open, that was closed without merging, or that
merged into some other branch describe what a proposed change would introduce, so they
carry no SLA deadline and never breach. A pull request merged into a non-default branch
behaves like an unmerged one here: its findings wait for a full scan.Merging controls scope, not the clock. A finding enters SLA scope the moment its
pull request merges into the default branch — you do not have to wait for the next full
scan — but the clock itself still runs from the issue’s lifecycle start, the same origin
every other finding uses (see Severity thresholds). A finding
raised on a pull request that stayed open for weeks is therefore already weeks old when
it merges, and can be past its deadline the moment it lands.The merged pull request’s own scan keeps the finding in scope until that repository’s
next successful full scan — one that both started at or after the merge and
completed without error. A full scan that was already running when the pull request
merged does not end the merged scan’s tenure, and neither does one that crashes or never
completes; the next successful full scan is what takes over. From that point the full
scan decides: if it still detects the finding, the finding stays in scope on its
original clock; if it does not, the finding leaves SLA scope. Any later scan of landed
code that detects it again puts it straight back in scope on its original clock.This is the one route into SLA scope that can expire, and it applies to SAST and SCA
findings alike. A finding that any full scan has ever detected stays in scope on that
basis permanently; a finding held in scope only by its merged pull request loses that
basis when a later successful full scan does not re-detect it.
Enabling and disabling policies
Each SLA policy has an enabled/disabled toggle on its policy card. Edit and delete controls on each policy card are gated by the corresponding alert permissions — you can only edit a policy if you have the edit alerts permission, and only delete a policy if you have the delete alerts permission. Users without these permissions can still view policy details. Disabling a policy suspends it: the policy stops driving breaches, SLI snapshots, and compliance reports until you re-enable it. This is useful when you want to pause enforcement temporarily — for example, during a migration — without deleting the policy and losing its configuration. When you re-enable a policy that has an SLO target, it is measured from the next nightly SLI snapshot. If you re-enable a policy that does not yet have an SLO target, you are prompted to add one to start measuring SLI. The SLO / SLI dashboard only considers enabled policies with an SLO target. If all of your policies with SLO targets are currently disabled, the dashboard shows how many disabled policies have targets and directs you to enable one.Creating an SLA policy
1
Open the policy wizard
Go to Settings → Service levels → 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
Choose the Slack schedule and message contents, then select Slack channels
and/or webhooks. You can leave channels empty when Slack delivery is Off.
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
ZeroPath evaluates open issues every hour. Each policy controls when its Slack summary is sent, independently of its remediation deadlines and SLO measurement.Control Slack frequency and contents
Edit a policy’s Slack notifications section to choose:
Existing Slack policies keep hourly delivery until you change them. Daily and weekly
schedules use an explicit IANA timezone, such as
America/New_York. During daylight
saving changes, a missing local time shifts forward and a repeated time sends once.
Delivery checks run every five minutes. Saving a policy never sends Slack immediately.
Child policies keep their own notification preferences.
Choose which information belongs in the summary:
- Newly eligible breaches: findings newly detected past a threshold, including those brought into scope by policy or repository changes.
- Still-overdue reminders: repeat the current backlog at each scheduled delivery. Turn this off to avoid repeating unchanged findings.
- Escalation milestones: include findings that reach an escalation step, only for that step’s destinations.
- Compliance risk changes: report a change in measured risk, rather than repeating the same HIGH state each day. Missing or insufficient data is not treated as recovery.
Slack preferences do not pause raw
ISSUE_AGED_PAST_THRESHOLD or SLA_BURN_RATE_HIGH
webhooks and Assistant automations. Disable the policy only when you also want to stop
SLA enforcement and measurement. See Webhooks.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. Slack
escalations follow the policy’s Slack schedule and content settings; they do not bypass
Off or trigger an immediate message.
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 / SLI section turns SLA activity into a trend. The Export report button on this dashboard is only shown to users who have the report generation permission; users without it can still view the dashboard metrics but cannot generate compliance exports. 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:
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 compares the measured breach proportion with the allowed proportion (100% − target compliance). A value above 1× means the measured breach level
exceeds the target allowance; it is not a count of new issues or a delivery frequency. ZeroPath surfaces two levels and, when configured, sends an
SLA_BURN_RATE_HIGH notification:
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. You can narrow the report to a subset of your codebase by selecting specific tags or repositories in the generation dialog. Leaving the scope unset covers your entire organization. See Reports for report generation and export.Audit Trail
The Audit trail tab records hourly sweep runs and raw event delivery attempts. Open a policy’s View overdue issues page and expand Slack delivery history to see the latest 25 Slack deliveries, including queued, delivered, retried, failed, muted, and superseded messages. Delivery records are retained for 90 days.Driving automations from SLA events
SLA events can trigger AI agent automations. Configure an agent event trigger for theISSUE_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.