> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# SLAs
> Set service level agreements that automatically monitor ticket response, resolution, and closure deadlines with early warning alerts and reporting.
Service Level Agreements (SLAs) help your team maintain consistent service quality by automatically monitoring ticket response times, resolution times, and closure deadlines. Set time-based commitments, receive early warning alerts before breaches occur, and track performance through comprehensive reporting to ensure you never miss a commitment to your customers.
## Mental model
An SLA is a set of time-based targets applied to tickets. Each SLA defines deadlines for response, resolution, and/or closure. SLAs are workspace-scoped and evaluated against tickets based on filter criteria.
SLAs are passive monitoring, not active automation. They measure whether time targets are met and generate visual indicators and notifications. They do not change ticket status, reassign tickets, or trigger workflows on their own. To take automated action on SLA events (breach, alert), use workflows with SLA-related triggers or conditions.
***
## SLA target types
| Target | Measures | Timer starts | Timer stops |
| -------------------------- | ------------------------------------------ | --------------- | ------------------------------------------------------------------------------------------------------ |
| **Time to first response** | How quickly the team acknowledges a ticket | Ticket creation | First team response (non-requester message) |
| **Time to resolution** | How quickly the ticket is resolved | Ticket creation | Ticket status moves to a status in the **Done** group, or directly to a status in the **Closed** group |
| **Time to close** | How quickly the ticket is fully closed | Ticket creation | Ticket status moves to "Closed" |
Each SLA can have multiple targets. For example, a single SLA might require first response within 1 hour, resolution within 8 hours, and closure within 24 hours.
**Done and Closed are independent milestones for SLA targets.** When a ticket moves to a status in the **Done** group, **Time to resolution** is marked Met (or Breached) and **Time to first response** stops. **Time to close** keeps running. The close timer only stops when the ticket moves to a status in the **Closed** group, at which point it is marked Met (or Breached). A ticket that sits in Done for an extended period before being Closed can meet its resolution target and still breach its close target.
**Closing a ticket directly also completes resolution.** When a ticket transitions straight to a status in the **Closed** group without first passing through **Done**, both **Time to close** and **Time to resolution** are marked Met (or Breached) at the same moment, since closure implies the ticket is resolved.
***
## Business schedules
A business schedule is a workspace-scoped resource that defines when SLA timers should run.
A schedule has two configurable components in the UI:
* `timezone`: an IANA timezone string (for example, `America/New_York`).
* `weeklyHours`: per-day arrays of `{ start, end }` ranges in `HH:MM` 24-hour format. Days with no ranges are fully off. Overnight ranges (end ≤ start) wrap to the next day.
Schedules are managed under **Settings → Business Schedules**. Each SLA can optionally reference one schedule by `scheduleId`. Schedules can be shared across multiple SLAs. To archive or delete a schedule, first reassign every SLA that uses it — Ravenna blocks archive and delete actions while connected SLAs exist.
Behavior when a schedule is attached:
* SLA target timers (response, resolution, close) only advance during the schedule's working windows. Time outside those windows is excluded.
* Newly created tickets outside working hours wait to start the timer at the next window. The SLA badge displays **Resumes at {time}** during that wait, showing when the timer will next advance.
* Alert and breach scheduling are computed against business time as well — a 1-hour alert on a 4-hour business-hours target fires 1 working hour before the working-hours breach deadline.
If no schedule is attached, the SLA falls back to wall-clock measurement (24/7), which is the legacy behavior.
Example schedule payload:
```json theme={"system"}
{
"name": "US Business Hours",
"timezone": "America/New_York",
"weeklyHours": {
"mon": [{ "start": "09:00", "end": "17:00" }],
"tue": [{ "start": "09:00", "end": "17:00" }],
"wed": [{ "start": "09:00", "end": "17:00" }],
"thu": [{ "start": "09:00", "end": "17:00" }],
"fri": [{ "start": "09:00", "end": "17:00" }]
}
}
```
***
## Pause statuses
Each SLA can declare a list of pause statuses. While a ticket is in any of those statuses, all of the SLA's timers stop. When the ticket transitions out, the timers resume from the elapsed time at pause.
Example configuration:
```json theme={"system"}
{
"name": "Tier 1 Support",
"pauseOnStatusIds": ["status_waiting_on_customer", "status_blocked"]
}
```
Rules:
* Statuses in the **Done** and **Closed** status groups are terminal and cannot be used as pause statuses. The settings page filters them out of the picker, and the SLA create/update API responds with an `INVALID_PAUSE_STATUS` bad-action error if they are submitted.
* Pause behavior applies to every target on the SLA (response, resolution, close) — it is not per-target.
* Pausing does not change the SLA outcome badge color from On Track. The timer simply does not advance.
***
## SLA evaluation and priority
When multiple SLAs exist, the system evaluates them in list order (top to bottom). The first SLA whose filter criteria match the ticket is applied. Only one SLA applies per ticket.
Recommended ordering:
1. Most specific SLAs first (e.g., "Critical Priority Incidents" filtered to priority = Critical and channel = Incidents).
2. Medium-specificity SLAs next (e.g., "IT Support" filtered to a specific channel).
3. Catch-all SLA last with "Apply to all tickets" enabled as a default baseline.
If no SLA matches a ticket, the ticket has no SLA monitoring.
***
## SLA outcome lifecycle
| Status | Color | Meaning |
| ------------ | ------ | ------------------------------------------------------------------- |
| **On Track** | Blue | Target is active, deadline has not been reached, no alert triggered |
| **Alert** | Orange | Alert threshold crossed, breach is approaching |
| **Met** | Green | Action completed within the target timeframe |
| **Breached** | Red | Deadline passed without the required action |
***
## SLA notifications
SLA alerts and breaches generate notifications sent to:
1. The ticket assignee (if assigned).
2. Ticket followers.
3. Channel auto-assignees (if no specific assignee).
4. Workspace administrators.
Approval notifications in Slack are always delivered and cannot be disabled. SLA notifications follow standard notification preferences.
***
## SLAs in automation
SLAs themselves do not trigger workflow actions. To automate responses to SLA events:
* Use workflow triggers that fire on ticket property changes combined with conditions that check SLA outcome.
* Build escalation workflows that reassign or notify when tickets approach SLA deadlines.
* Use the "Due Date" workflow action to set deadlines that align with SLA targets.
SLA data is available in analytics dashboards for compliance reporting and performance tracking.
***
## Constraints and gotchas
* Only one SLA applies per ticket. The first matching SLA in list order wins.
* SLA timers run continuously from ticket creation unless you configure pause statuses. When a ticket enters a configured pause status, the SLA's timers stop and resume when it leaves. Snooze does not pause SLA timers — use pause statuses for that.
* Pause statuses cannot include any status in the **Done** or **Closed** status groups. The settings UI hides terminal statuses from the picker and the SLA create/update endpoints reject them with an `INVALID_PAUSE_STATUS` error.
* By default SLA targets use wall-clock time. A 4-hour response target includes nights and weekends unless a business schedule is attached. Attach a business schedule to the SLA to measure time only during the schedule's working windows.
* Moving a ticket to **Done** finalizes **Time to resolution** but does not stop **Time to close**. The close timer continues to run (or breach) until the ticket moves to a status in the **Closed** group. Treat Done and Closed as separate SLA milestones when configuring close targets.
* Closing a ticket directly (skipping **Done**) finalizes both **Time to close** and **Time to resolution** in the same transition, because reaching **Closed** implies the ticket is resolved. The resolution target is marked Met if the close happens before the resolution deadline, or Breached otherwise.
* Changing a ticket's properties (priority, channel, form) after creation does not re-evaluate which SLA applies. The SLA is locked at ticket creation.
* SLAs are workspace-scoped. There is no organization-level SLA that spans workspaces.
* SLA filter criteria support status, priority, channel, form, assignee, requestor, author, and other ticket attributes. Filters use AND logic.
* The **Assignee**, **Requestor**, and **Author** filters support the `is member of` and `is not member of` operators. These match tickets where that user belongs (or does not belong) to one of the selected user groups. Use them to scope an SLA to a team rather than a single user. Tickets where the user is unset never match `is member of` and always match `is not member of`.
* The legacy **Assignee Group** filter column is deprecated. Use **Assignee** with `is member of` / `is not member of` instead.
* Alerts are early warnings only. They do not take automated action. To automate escalation, build a workflow.
* Alert time is measured backward from the breach deadline, not forward from ticket creation. A 1-hour alert on a 4-hour target fires at the 3-hour mark. If the configured alert time is greater than or equal to the target time, no alert fires.
* SLA performance data is available in the prepackaged analytics dashboards.