> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SLA Policies for Follow-Ups

> Use SLA policies to set assignment and completion deadlines on follow-up action items, get notified before deadlines pass, and track violations.

## Overview

SLA policies let you define time-based expectations for follow-up action items. When a matching follow-up is created, Rootly automatically calculates its assignment and completion deadlines, sends notifications as those deadlines approach, and records a violation if the deadline is missed.

SLA policies apply exclusively to **follow-ups** — not to tasks. They are configured per team and evaluated against every follow-up that team creates.

<Info>
  SLA policies are managed under **Configuration → SLA Policies** in the web app.
</Info>

***

## Create an SLA Policy

<Steps>
  <Step title="Navigate to SLA Policies">
    Go to **Configuration → SLA Policies** and click **+ New SLA Policy**.
  </Step>

  <Step title="Name the policy">
    Give the policy a clear, descriptive name. Names must be unique within your team.

    Optionally add a description to explain when this policy applies or what it enforces.
  </Step>

  <Step title="Assign a manager">
    The manager is the person responsible for ensuring follow-ups covered by this policy are completed on time. Choose one of:

    <ParamField body="Incident Role">
      The policy is managed by whoever holds a specific role on the incident (for example, the Incident Commander or the assigned engineer). This is the recommended option for most teams since it adapts dynamically to each incident.
    </ParamField>

    <ParamField body="Specific User">
      A named user is always the manager, regardless of who holds any particular role on the incident.
    </ParamField>

    <Note>
      You must set either a manager role or a specific user — not both.
    </Note>
  </Step>

  <Step title="Set deadlines">
    Configure the two deadlines Rootly tracks for each follow-up:

    <ParamField body="Assignment deadline">
      How many days after a given incident status the follow-up must be assigned to someone.
    </ParamField>

    <ParamField body="Completion deadline">
      How many days after a given incident status the follow-up must be completed. When a policy applies, Rootly writes this computed date into the follow-up's **Due date** field — the same field you see when creating a follow-up manually. If a policy is applied, the Due date reflects the SLA deadline rather than a manually entered value.
    </ParamField>

    For each deadline, choose:

    * **Trigger status** — the incident status that starts the deadline clock. Options: `In Triage`, `Started`, `Mitigated`, `Resolved`, `Closed`, `Cancelled`
    * **Number of days** — 1, 2, 3, 4, 5, 6, 7, 14, 21, or 30 days

    <Tip>
      If your team uses custom lifecycle sub-statuses, you can anchor deadlines to a specific sub-status instead of a top-level status.
    </Tip>
  </Step>

  <Step title="Add conditions (optional)">
    By default, a policy applies to every follow-up the team creates. Add conditions to scope it to a subset.

    Conditions can be built on:

    * **Built-in incident fields** — severity, environment, service, functionality, incident type, team, cause, status, incident role, visibility, and timestamps
    * **Custom fields** — any select or multi-select custom field configured for your team

    Most conditions support the operators **is one of**, **is not one of**, **is set**, and **is not set**. Timestamp fields (such as `started_at` or `resolved_at`) only support **is set** and **is not set**, since specific datetime values cannot be selected from a list.

    Use the **Match** toggle to control whether the policy triggers when **Any** condition matches or when **All** conditions match.

    <Note>
      A policy can have up to 20 conditions.
    </Note>
  </Step>

  <Step title="Configure notifications">
    Add up to 5 notification rules that control when the policy's manager is notified about upcoming or overdue deadlines. Notifications are sent to the manager only — either the user in the configured incident role or the specific user assigned to the policy.

    Each rule fires independently for **both** the assignment deadline and the completion deadline. For example, a "1 day before due" rule will send one notification before the assignment deadline and another before the completion deadline.

    <ParamField body="Before due">
      Send a notification X days before the deadline. Requires a minimum deadline of at least 2 days.
    </ParamField>

    <ParamField body="When due">
      Send a notification on the day the deadline falls.
    </ParamField>

    <ParamField body="After due">
      Send a notification X days after the deadline has passed (1–99 days). Use this to escalate violations that have not been resolved.
    </ParamField>
  </Step>

  <Step title="Save the policy">
    Click **Save**. The policy will immediately start applying to new follow-ups that match its conditions. Existing follow-ups are not retroactively affected.
  </Step>
</Steps>

***

## How Deadlines Are Calculated

When a follow-up is created, Rootly scans all active SLA policies for the team and applies the first matching policy. The deadline clock starts when the incident reaches the configured trigger status.

For example, if a policy sets a **7-day completion deadline from Resolved** and the incident resolves on Tuesday the 1st, the follow-up completion deadline is Tuesday the 8th.

<Warning>
  Deadlines are calculated once when the trigger status is reached. If the incident moves back through statuses (for example, from Resolved back to Started), the deadline is not recalculated.
</Warning>

***

## Violations

A **violation** is recorded when a deadline passes without the required action being taken. Rootly tracks two violation types:

* **Assignment overdue** — the follow-up had no assignee when the assignment deadline passed
* **Completion overdue** — the follow-up was not marked done when the completion deadline passed

Violations remain open until the follow-up is assigned or completed. Once resolved, the violation is marked as resolved with a timestamp.

You can view open violations and historical SLA data on the SLA Policies page under **Configuration**.

***

## Best Practices

* **Set completion deadlines relative to Resolved** for most follow-ups — this aligns accountability with the natural end of the incident lifecycle.
* **Use assignment deadlines** to catch follow-ups that get created but never picked up, especially across team handoffs.
* **Use conditions to differentiate by severity** — a P1 incident may warrant a 2-day completion SLA while a P3 can tolerate 14 days.
* **Add a before-due notification** so managers have time to act, not just receive a violation notice after the fact.
* **Keep policies simple** — one or two policies per team covering the most common cases is easier to maintain than a complex matrix.

***

## FAQ

<AccordionGroup>
  <Accordion title="Do SLA policies apply to tasks or only follow-ups?" icon="list-check">
    Only follow-ups. Tasks are intended for work done during an incident and do not have SLA enforcement.
  </Accordion>

  <Accordion title="What happens if multiple policies match a follow-up?" icon="circle-info">
    The first matching policy (in the order they appear in the SLA Policies list) is applied. Only one policy is applied per follow-up.
  </Accordion>

  <Accordion title="Can I apply an SLA policy retroactively to existing follow-ups?" icon="circle-question">
    No. SLA policies are evaluated at follow-up creation time. Existing follow-ups are not affected when a new policy is created or an existing one is updated.
  </Accordion>

  <Accordion title="Who receives SLA notifications?" icon="bell">
    Notifications are sent only to the policy's configured manager — either the user currently holding the specified incident role on the incident, or the specific user assigned to the policy. No other users are notified.
  </Accordion>

  <Accordion title="Can I set different deadlines for different severities?" icon="list">
    Yes. Create separate SLA policies with conditions scoped to each severity level, each with different deadline values.
  </Accordion>

  <Accordion title="What statuses can trigger the deadline clock?" icon="bolt">
    In Triage, Started, Mitigated, Resolved, Closed, and Cancelled. If your team uses custom sub-statuses, you can also anchor to a specific sub-status.
  </Accordion>
</AccordionGroup>