Skip to main content

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.

​
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.
SLA policies are managed under Configuration → SLA Policies in the web app.

​
Create an SLA Policy

1

Navigate to SLA Policies

Go to Configuration → SLA Policies and click + New SLA Policy.
2

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.
3

Assign a manager

The manager is the person responsible for ensuring follow-ups covered by this policy are completed on time. Choose one of:
​
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.
​
Specific User
A named user is always the manager, regardless of who holds any particular role on the incident.
You must set either a manager role or a specific user — not both.
4

Set deadlines

Configure the two deadlines Rootly tracks for each follow-up:
​
Assignment deadline
How many days after a given incident status the follow-up must be assigned to someone.
​
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.
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
If your team uses custom lifecycle sub-statuses, you can anchor deadlines to a specific sub-status instead of a top-level status.
5

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.
A policy can have up to 20 conditions.
6

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.
​
Before due
Send a notification X days before the deadline. Requires a minimum deadline of at least 2 days.
​
When due
Send a notification on the day the deadline falls.
​
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.
7

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.

​
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.
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.

​
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

Only follow-ups. Tasks are intended for work done during an incident and do not have SLA enforcement.
The first matching policy (in the order they appear in the SLA Policies list) is applied. Only one policy is applied per follow-up.
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.
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.
Yes. Create separate SLA policies with conditions scoped to each severity level, each with different deadline values.
In Triage, Started, Mitigated, Resolved, Closed, and Cancelled. If your team uses custom sub-statuses, you can also anchor to a specific sub-status.