> ## 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. **Key capabilities:** * Automated monitoring that continuously checks SLA compliance in the background * Multiple target types for response, resolution, and closure times * Business schedules that limit SLA measurement to your team's working hours * Pause statuses that stop the timer while a ticket is waiting on someone else * Early warning alerts before SLA breaches occur * Flexible filtering to apply SLAs to specific ticket types * Visual indicators showing SLA health at a glance * Priority ordering when multiple SLAs could apply to the same ticket Learn more about [SLA analytics](/documentation/measure/analytics#prepackaged-dashboards) and [ticket priorities](/documentation/tickets/organize/priorities) *** ## SLA components SLAs consist of targets that define time-based commitments and alerts that provide early warnings before breaches occur. Each SLA can contain multiple targets that define different time-based commitments for ticket handling. **Time to first response** * Measures time from ticket creation to first team response * Ensures customers get timely acknowledgment * Maintains customer satisfaction with prompt initial contact **Time to resolution** * Measures time from ticket creation to resolution * Tracks overall issue resolution performance * Serves as a key metric for service quality **Time to close** * Measures time from ticket creation to final closure * Includes any follow-up or verification steps * Provides complete lifecycle tracking Configure targets using flexible time units including minutes, hours, and days. Alerts provide early warning before SLA breaches occur, giving your team time to take action. **Time to first response alerts** * Warn before response deadline is missed * Give your team time to provide initial customer contact **Time to resolution alerts** * Alert before resolution deadline * Allow for escalation or resource reallocation **Time to close alerts** * Notify before final closure deadline * Ensure proper ticket completion Configure alerts using the same flexible time units as targets (minutes, hours, days). **How alert time is interpreted** The alert time is the amount of time **before the breach deadline** that the alert fires — not the elapsed time from ticket creation. For example, take a Time to first response target of 4 hours with an alert configured for 1 hour. The alert fires 3 hours after the ticket is created, which is 1 hour before the 4-hour deadline. If the alert time is greater than or equal to the target time, no alert is scheduled — there is no window in which an early warning makes sense. Attach a business schedule to an SLA to measure time against your team's working hours instead of wall-clock time. Nights and weekends outside the schedule are excluded from response, resolution, and close calculations. **What a schedule defines** * **Timezone**: The IANA timezone the schedule is anchored in (for example, `America/New_York`). * **Weekly hours**: One or more working time ranges per day of the week, in 24-hour `HH:MM` format. A day with no ranges is treated as fully off. **How it works** * When an SLA has a schedule attached, its timers only advance during the schedule's working windows. * When a ticket is created or transitions outside working hours, the timer waits to start (or resume) until the next working window opens. * A ticket's SLA badge shows **Resumes at {time}** outside business hours, indicating when the timer will next pick up rather than ticking down. * An SLA without a schedule continues to use wall-clock time (24/7). Create and manage schedules under **Settings → Business Schedules**, then select one in the **Settings** tab of an SLA. The same schedule can be shared across multiple SLAs. Pause statuses stop the SLA timer while a ticket sits in a state your team is not actively working on, so waiting time does not count against your targets. **Common use cases** * Pause while waiting on the requester (for example, a "Waiting on customer" status) * Pause while a ticket is blocked by an external dependency * Pause during scheduled change windows or planned downtime **How it works** * Select one or more statuses that should pause the SLA timer * When a ticket enters a pause status, that SLA's timers stop * When the ticket leaves the pause status, timers resume from where they left off * Time spent in a pause status is excluded from response, resolution, and close calculations Terminal statuses in the **Done** and **Closed** status groups cannot be selected as pause statuses. Reaching a terminal status already stops the SLA timer for good — the target is either met or breached. The pause status picker hides them, and the API rejects them on save. *** ## How SLAs work By default, SLAs apply to all tickets in your workspace. To target only certain tickets, turn off the "Apply to all tickets" toggle and add filter criteria based on status, priority, channel, form, assignee, assignee group, or other attributes. ### SLA status indicators Ravenna uses a color-coded system to show SLA status at a glance on ticket cards and dashboards. Action completed within the SLA timeframe and target successfully achieved. SLA is active but no action taken yet. Still within the allowed timeframe with no alerts triggered. Alert threshold has been crossed and breach is imminent without action. Provides early warning to take preventive action. SLA deadline has passed and the service level target has been missed. Requires immediate attention. *** ## Creating SLAs Set up service level agreements to automatically monitor ticket response and resolution times. Go to **Settings** → **SLAs** to access SLA management. Click the **+ SLA** button to open the SLA creation form. Provide a descriptive name, description, and icon for your SLA, then click **Save**. Click your newly created SLA from the list to open the detailed configuration page. Set up your service level commitments by adding targets for Time to First Response, Time to Resolution, or Time to Close with specific time limits. Add alerts that warn before SLA breaches occur by setting alert timing for each target type. On the SLA's **Settings** tab, select a business schedule if you want SLA timers to honor your team's working hours instead of running 24/7. Leave this blank to keep wall-clock measurement. Business schedules are created under **Settings → Business Schedules**. Select any statuses that should pause the SLA timer, such as "Waiting on customer" or "Blocked". Time spent in a pause status is excluded from your SLA calculations. Terminal statuses in the **Done** and **Closed** groups are not selectable, since reaching them already stops the timer. By default, your SLA applies to all tickets. To target specific tickets, turn off the "Apply to all tickets" toggle and configure filter criteria based on status, priority, channel, form, assignee, assignee group, or other attributes. To target tickets by user group, use the **Assignee**, **Requestor**, or **Author** filter with the **is member of** or **is not member of** operator. Select one or more user groups to scope the SLA. Use this to define SLAs that follow a team rather than a specific user, for example, "Tier 1 Support" or "Security On-Call". Save your SLA configuration to activate monitoring for matching tickets. *** ## Managing multiple SLAs When multiple SLAs could apply to the same ticket, Ravenna uses priority ordering to determine which SLA is applied. ### Priority evaluation * SLAs are evaluated in the order they appear in your list * The first matching SLA is applied to each ticket * SLAs higher in the list take precedence over those lower in the list ### Best practices for ordering * Order SLAs from most specific to most general * Place urgent or critical SLAs at the top of the list * Use "Apply to all tickets" SLAs as fallbacks at the bottom * Review SLA order regularly to ensure proper precedence *** ## Notifications and alerts SLA notifications are automatically sent to relevant stakeholders when alerts trigger or breaches occur. ### Notification recipients Notifications are sent to the following recipients based on ticket assignments: * Ticket assignee (if assigned) * Ticket followers * Channel auto-assignees (if no specific assignee) * Workspace administrators ### Notification timing * **Alerts**: Sent when alert threshold is crossed, providing early warning before breach * **Breaches**: Sent when SLA deadline passes, requiring immediate attention Learn more about [configuring notifications](/documentation/platform/notifications) *** ## Monitoring SLA performance Track SLA compliance through visual indicators and comprehensive Analytics dashboards. ### Visual indicators SLA performance is displayed through: * Color-coded SLA badges on ticket cards * Progress indicators showing time remaining * Clear visual status at a glance in ticket lists ### Filter and export by SLA In any view, filter tickets by: * **SLA**: The SLA policy attached to the ticket * **Status**: SLA outcome — **Met** or **Breached** * **Target**: The SLA target type — **Time to First Response**, **Time to Resolution**, or **Time to Close** SLA filters are grouped under a single **SLA** entry in the filter menu. Exported CSVs include the assigned SLA name and its current status alongside other ticket data, so you can run compliance reporting offline. ### Dashboard metrics Analytics dashboards provide comprehensive SLA performance tracking: * **Compliance rate**: Percentage of tickets meeting SLA targets * **Average response time**: How quickly your team responds to new tickets * **Breach trends**: Patterns in SLA violations over time * **Performance by category**: SLA success broken down by priority, channel, or form Learn more about [SLA analytics dashboard](/documentation/measure/analytics#prepackaged-dashboards) ## 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 status 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 status 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 status. * 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.