SLA Tracking
SLA applies to Support projects. Support tickets get an automatic Service Level Agreement deadline computed from their creation time and priority. Consulting, Dev, and Epic projects don't use SLA — they plan work with explicit start/end windows and effort estimates instead (see Tickets).
Default SLA Hours
| Priority | Resolution Target |
|---|---|
| Critical | 4 hours |
| High | 8 hours |
| Medium | 24 hours |
| Low | 72 hours (3 days) |
The deadline is stored as the ticket's due date (creation time + SLA hours). Changing a ticket's priority recomputes the due date from the original creation time.
The SLA Bar
The ticket details panel shows a countdown bar:
- 🟢 Green — comfortably within the SLA window
- 🟡 Amber — deadline approaching
- 🔴 Red — SLA breached
On Hold pauses the work, and is tracked
When a ticket is put On Hold, the time it spends on hold is accumulated (onHoldMinutes) and recorded when it resumes. This lets on-hold time be separated from active working time for SLA reporting, so a ticket isn't penalized for time spent waiting on a third party.
Breach Notifications
A scheduled check runs continuously; when a Support ticket passes its due date without being resolved, the assignees and project stakeholders receive an SLA Breached notification.
Working hours & holidays
Admins define a tenant-wide Master Calendar — working hours per region, weekend rules (including alternate Saturdays), and holidays. This calendar is the foundation for business-hours-aware SLA.
:::info Current behavior Today the SLA deadline uses flat wall-clock hours from the table above. The master calendar is configured and displayed, and is the basis for making SLA business-hours-aware — see Known Issues for the current status. :::