SLA policies and business calendars
How SLA targets are defined, how business time is counted, and the regulatory milestone clocks that attach themselves.
SLA policies
Settings → Service desk → SLA policies (permission sla.definition.manage) defines named targets. A policy binds:
- Entity type — incident, request, or change (required).
- Priority —
P1–P4, or any. - Severity — SEV 1–5, or any.
- Target — the time allowed, in business time.
- Warning threshold — optional; when set, a breach imminent signal fires before the target is missed. Without it, no warning fires.
- Business calendar — required; defines what counts as business time.
A policy matches a ticket when every filter you set matches; filters left at any match everything. A ticket can carry several timers at once (say, response and resolution); lists collapse them into one worst-first SLA column you can sort and filter.
The timer statuses are: No SLA, On track, At risk, Breached, Met, and Paused. Deactivating a policy stops it applying to new tickets but keeps it queryable for historical reporting — prefer deactivating over deleting.
Business calendars
Settings → Service desk → Business calendars (permission sla.calendar.manage) defines working time: per-weekday on/off switches, a workday start and end, and a timezone. SLA elapsed time is computed in business seconds against the calendar — weekends and out-of-hours simply do not accumulate. An eight-business-hour target set on Friday afternoon breaches Monday, not Saturday.
Regulatory milestone clocks
When an incident is classified as DORA-major, NIS-2-significant, or an EU AI Act serious incident, the corresponding reporting clocks attach automatically — and they run on a 24/7 wall-clock calendar, not your business calendar, because the regulators' deadlines do:
| Milestone | Target | Warning |
|---|---|---|
| DORA major — initial notification | 4 h | 3 h |
| DORA major — intermediate report | 72 h | 60 h |
| DORA major — final report | 30 d | 28 d |
| NIS-2 significant — early warning | 24 h | 20 h |
| NIS-2 significant — incident notification | 72 h | 60 h |
| EU AI Act Art. 73 — serious incident report | 15 d | 13 d |
| EU AI Act Art. 73 — death of a person | 10 d | 8 d |
| EU AI Act Art. 73 — widespread / critical-infrastructure | 2 d | 1 d |
The Art. 73 clocks are selected, not attached blindly: the 15-day clock always applies on escalation, the 2-day clock attaches only when a linked AI system supports a critical function, and the 10-day clock only on explicit categorization — so you never see a false breach on a deadline that does not apply to you.
Reacting to SLA events
sla.breach_warning and sla.breached are business-rule triggers, so you can auto-escalate — reassign, raise priority, notify a role — when a timer runs hot. An active maintenance window pauses the SLA timers of tickets whose CIs are under maintenance, and resumes them when the window ends.