First-response and resolution targets per priority, business calendars that know about your holidays, pauses that stop an on-hold ticket burning its clock, and five breach actions that fire exactly once. Included at every tier.
Not a due-date field with a red badge. A clock with rules about when it runs.
Organisation policies are the inherited default. A project takes over only when it needs to.
A policy is owned by a project or by the organisation, and the organisation's policy is the inherited default for every project that has not taken over. SLA is one of the configuration areas a project can override wholesale and later revert to inheriting — the same mechanism that governs ticket types, priorities, incident flags and services.
Per-priority targets are what stop the usual compromise. Without them you either promise a four-hour resolution to everything, which you will not keep, or promise a five-day resolution to everything, which makes the critical ticket indistinguishable from the cosmetic one.
A four-hour target that expires at 3am on Sunday is not a target. It is a report of a failure.
SLA reporting is only believed if the mechanics underneath it are defensible.
Pause conditions are a set of status categories — typically ON_HOLD. Entering a status in that set pauses the clock; the ticket accrues parked minutes instead of elapsed ones.
Waiting on the customer, on a supplier, on a change window: none of it should count against a promise you made about your own response time.
Leaving a paused status accumulates the parked minutes and pushes out only the pending deadlines. A first-response target that was already met is not moved.
That asymmetry is the whole point: met deadlines are historical facts. A system that recalculates them retroactively is a system whose compliance figure means nothing.
The per-ticket timer holds first-response due, at, breached and breach-processed; the same four for resolution; paused-at and elapsed-paused-minutes — and the policy the ticket started under.
Deadlines are facts about what was promised. Storing the originating policy is what lets you answer "what were we actually committed to on this ticket, in March" a year later, without archaeology.
Editing a policy recomputes deadlines for still-open tickets from each ticket's own creation time, and clears breach flags on the pending side.
So a mistyped target is a five-minute correction rather than a permanent cohort of tickets measured against a number nobody meant. Closed tickets are untouched — their history stands.
Idempotent per side — first response and resolution are handled independently, and neither doubles up.
SLA_BREACHED entry is written to the ticket's activity feed, alongside every other change — so the breach sits in the same timeline as the work, queryable by ticket, user, project and organisation.SLA_BREACH notification to the assignee, the project lead and any named users — deduplicated, so the person who is all three gets one notification, not three.Four fields, available anywhere TQL is — which is everywhere.
slaStatus Where the ticket stands against its policyslaDue The next deadlinefirstResponseBreached Did we answer in timeresolutionBreached Did we finish in time# the standing "what is on fire" filter
firstResponseBreached = true AND statusCategory != DONE ORDER BY slaDue ASC
# about to breach, still unassigned — the ones worth interrupting someone for
slaDue < +2h AND assignee IS EMPTY ORDER BY priority DESC
# last quarter's misses on one service, for the review meeting
service = "Payments" AND resolutionBreached = true AND resolved > -1qBecause these are ordinary TQL fields, a query like the first one can be saved and shared organisation-wide, pinned to a dashboard widget, used as the selection filter for an automation rule, or scheduled as a report with its figures in the mail body.
Each exportable in five formats, and schedulable on the same engine as every other Trakr report.
Compliance rates overall and per project. This is the figure that goes in the board pack, which is exactly why the pause and resume semantics above have to be defensible.
A percentage tells you there is a problem. The breach list names the tickets, so the review meeting is about specific work rather than about the metric.
Response-time analytics across the period, alongside the resolution-metrics report's MTTR and trend, first-contact-resolution rate and reopen trend when you want the fuller picture.
A heatmap of volume and response time. It is the fastest way to see that Monday 09:00 is not a staffing problem in general — it is a staffing problem for ninety minutes.
Recipients are re-resolved on every run, so someone who left the company stops receiving your SLA figures. A scheduled run never calls AI — an unattended report that quietly costs money and varies between runs is not a report.
Per-organisation policy governs whether scheduling is enabled at all, whether external recipients are allowed, and how many there may be, with an organisation-wide view of every schedule and the ability to disable any of them.
Only if you say so. Every policy runs against a business calendar with a timezone (UTC by default), a work start of 09:00, a work end of 17:00, work days of Monday to Friday, and holidays given as a date and a name. Working-minute arithmetic skips non-work days and holidays entirely.
An always-on 24×7 calendar is available for desks that genuinely run around the clock, and calendars can be owned by the organisation or by a single project.
A policy carries pause conditions as a set of status categories — typically ON_HOLD. Entering a status in that set pauses the clock.
Leaving it accumulates the parked minutes and pushes out only the pending deadlines: a first-response target that was already met is a historical fact and is not moved. Waiting on the customer does not burn the time you promised to spend on them.
Editing a policy recomputes deadlines for still-open tickets from each ticket's own creation time, and clears breach flags on the pending side. The recomputation is self-healing: you fix the policy once and the queue corrects itself.
Each ticket's timer also records the policy it started under, because a deadline is a fact about what was promised at the time — not about what the policy says today.
Five things, each idempotent per side so a re-run never doubles them: an SLA_BREACHED entry is written to the activity feed; an in-app notification goes to the assignee, the project lead and any named users, deduplicated; those people are emailed through the SLA breach template; the ticket's priority is escalated; and the ticket is reassigned to the policy's backup assignee.
Which of the five apply is configured on the policy, and named recipients can include free-text addresses as well as real accounts.
Yes. SLA state is a first-class query target in TQL: slaStatus, slaDue, firstResponseBreached and resolutionBreached.
So firstResponseBreached = true AND slaDue < now() ORDER BY slaDue ASC is an ordinary query that can be saved, shared organisation-wide, pinned to a dashboard widget, used as an automation rule's selection filter, or scheduled as a report.
Compliance rates, a named breach list, response-time analytics, a volume and response-time heatmap, and per-project compliance.
Every one of them exports to PDF, CSV, JSON, XML or XLSX, and the SLA report can be scheduled daily, weekly or monthly with a rolling window. Scheduled mail carries the figures in the body rather than as an attachment, and never calls AI on a scheduled run.
SLA policies, calendars, breach actions and reporting are included at every Trakr tier. Self-hostable, made in Belgium.