# AI Meeting Bot
Source: https://docs.rootly.com/ai/ai-meeting-bot
Automatically record, transcribe, and summarize incident bridge calls to break down communication silos and support postmortem documentation.
Your AI Meeting Bot helps break down communication silos between incident bridges and the rest of your team.
### Configuration[](#yihQh)
To get started, integrate your Rootly instance into your virtual meeting room software of choice. Check out our [integration documentation](/integrations "integration documentation") for more information on how to do specific integrations.
Once Rootly is successfully integrated into your virtual meeting room software, click into your integration from the Integrations page and toggle on 'Meeting transcript and summary'.
During your incident bridges, allow your Rootly Meeting Bot into the meeting to begin recording and transcribing your call.
### On incident bridges[](#PAphj)
Once your Meeting Bot has been admitted to your incident bridge, it will immediately begin recording and transcribing the meeting.
Any new responders joining the incident can use [Incident Catchup](/ai/incident-catchup "Incident Catchup") to receive up-to-date information on the incident: Rootly AI will also include information from your incident bridge to give your responder a complete picture of the incident.
### After your incident[](#CMHSJ)
Once the call has ended and your incident is resolved, the Meeting Bot will update your incident with a call recording, transcription, and summary of what was discussed to support your postmortem rituals. This can be found in the Meeting tab of your incident.
# Ask Rootly AI
Source: https://docs.rootly.com/ai/ask-rootly-ai
Interactive AI assistant that answers questions about incidents, provides summaries, and helps with incident management tasks directly in Slack or the web interface.
Got a simple question to ask? Need a summary for your customer-facing teams? Ask Rootly AI can help answer questions and handle a variety of prompts in an incident channel in Slack or on the web.
**Via the web in an incident:**
**Via Slack in an incident channel: ask @rootly questions**
# Data Privacy for AI
Source: https://docs.rootly.com/ai/data-privacy-for-ai
Learn about Rootly's data privacy and security safeguards for AI features, including what data is shared with OpenAI and how your incident information is protected.
Rootly is dedicated to maintaining the highest standards of privacy and security. [Read more about our data philosophy](https://rootly.com/blog/building-a-privacy-first-ai-for-incident-management).
* Rootly AI, driven by OpenAI, incorporates multiple safeguards to ensure the security of your data, providing you with peace of mind.
* Data sent to OpenAI is solely used to provide Rootly AI services and is neither stored nor used for training purposes by OpenAI.
* We automatically redact the following PII before sending any data to OpenAI:
* email, addresses, phone numbers, credit card numbers, social security numbers (SSNs) and passwords in URLs
* Private incident data is **never** sent to OpenAI.
* Rootly AI never uses your data (even if anonymously) to improve results for other customers; it stays within the walls of your organization and is only used there.
* You may opt-out at any time via the [AI configuration page](https://rootly.com/account/ai/configurations). No future changes to how your data is used will change without your explicit approval.
* Optionally, organizations may [integrate their OpenAI account](https://rootly.com/account/integrations/open_ai_accounts/new) to take advantage of any organization specific data retention policies.
**Data from the incident that will be considered includes:**
* Built-in and custom fields
* Human-created timeline events
* Completed action items
* Timestamps
* Alert source
* Mitigated and resolved messages
* Slack messages from the incident channel (depending upon [Slack channel message visibility](https://rootly.com/account/ai/configurations))
**Data that is not considered includes:**
* Incident feedback
* Automated timeline events relating to action items, workflow runs and playbooks.
* Any data from private incidents
**Via Slack in an incident channel: trigger via the** `/rootly update` **command then clicking the 'Generate with AI' button**
# Incident Catchup
Source: https://docs.rootly.com/ai/incident-catchup
Quickly get up to speed on ongoing incidents using AI-generated summaries when joining an incident Slack channel as a responder.
Have you ever been pulled into an incident and you're not sure what's going on or where to begin? Well, Rootly AI can help with just that. As a responder joining an incident Slack channel, use a simple command and learn everything you need to know in seconds; use the Slack command `/rootly catchup`.
Summaries will be only visible to you, and you can generate a new summary by clicking on 'Update Summary.'
Via Slack in an incident channel: Run the command `/rootly catchup`.
# Incident Summarization
Source: https://docs.rootly.com/ai/incident-summarization
Generate AI-powered incident summaries that analyze historical incidents, suggest resolution steps, and invite previous responders to help resolve current incidents.
Generate incident summaries instantly with Rootly AI. Using historical incidents, our advanced AI models will detect key similarities. We’ll tell you how it was resolved in the past, suggest the best next steps, and optionally invite previous responders to help. You can do this whether you're on the web or on Slack by using the commands `/rootly summary` or `/rootly update`.
**Via web in an incident: click the genius pen**
**Via Slack in an incident channel: run the** `/rootly summary` **or** `/rootly update` **command and select the ‘Generate with AI’ button**
# Mitigation And Resolution Summary
Source: https://docs.rootly.com/ai/mitigation-and-resolution-summary
Generate AI-powered mitigation and resolution summaries for incidents using Rootly AI through the web interface or Slack commands.
Do you need to write-up mitigation and resolution summaries? Rootly AI has you covered! By pulling information on the current state of the incident, Rootly AI will give you a mitigation and resolution summary just like that, whether you are on the web or in Slack by using the commands `/rootly mitigate` or `/rootly resolve`.
**Via web in an incident: click the genius pen**
**Via Slack in an incident channel: run the** `/rootly mitigate` **or** `/rootly resolve` **commands and select the ‘Generate with AI’ button**
### Configuration[](#joai1)
Generated incident titles by Rootly AI are available for all customers. To enable, head to Rootly AI > Enable Rootly AI and opt in to Rootly AI capabilities. Note that only Admins can enable Rootly AI.
To ensure the best results, 'Slack channel message visibility' is set to 'All messages' by default. You can change this at any time.
# Rootly AI Editor
Source: https://docs.rootly.com/ai/rootly-ai-editor
Improve your writing across Rootly with AI-powered text editing that fixes spelling and grammar, adjusts length, and simplifies language.
Being an award-winning writer isn't for everyone, but don't worry, we got you covered. Rootly AI Editor is available across Rootly in our text inputs, and it's there to help fix spelling and grammar, shorten or lengthen sentences, and even simplify the language used.
**Via web trigger by highlighting any text in a text input**
### Configuration[](#IX4jj)
Generated incident titles by Rootly AI are available for all customers. To enable, head to Rootly AI > Enable Rootly AI and opt in to Rootly AI capabilities. Note that only Admins can enable Rootly AI.
To ensure the best results, 'Slack channel message visibility' is set to 'All messages' by default. You can change this at any time.
# Slack Scope Updates
Source: https://docs.rootly.com/ai/slack-scope-updates
Configure enhanced Slack permissions to enable Rootly AI features with customizable privacy levels for incident channel message ingestion.
Administrators will be prompted to update Slack Scopes to enable Rootly AI. These updated scopes enable the ingestion of the contents of incident slack channels providing a higher quality experience when generating AI responses.
These enhanced scopes are only used in the context of Rootly AI. They can be [configured to five varying levels of privacy](https://rootly.com/account/ai/configurations "configured to five varying levels of privacy") from fully permissive (ingesting every message in an incident channel), to only ingesting content from specific types of incidents (public or private) or completely off and ingesting no slack messages.
# Alert Fields
Source: https://docs.rootly.com/alerts/alert-fields
Use Alert Fields to extract, normalize, and store structured alert data for routing, enrichment, automation, and triage across Rootly.
Alert Fields allow you to extract key information from incoming alert payloads and store it in a normalized format that can be used consistently across Rootly. This removes the need to understand every alert provider’s unique payload structure—Rootly handles that translation automatically.
***
### Examples
**Route alerts by impacted product area**\
Map a `product_area` field using Liquid, then build routes that send alerts to the correct on-call team.
**Enrich alert details for responders**\
Extract severity, region, deployment ID, customer tier, or any custom metadata.
**Build better metrics and dashboards**\
Use normalized field values to track trends without parsing different payload structures.
**Simplify multi-tool environments**\
Create one `severity` field and map Datadog, PagerDuty, Opsgenie, and Sentry severities into it consistently.
***
### Configuring Alert Fields
To configure Alert Fields:
***
### What Is an Alert Route?
An **Alert Route** defines *when*, *how*, and *to whom* Rootly should send alerts. It supports evaluation against:
* Alert Sources
* Alert Fields (normalized metadata)
* Raw payload values (JSONPath)
* Teams, services, and escalation policies
***
### Routing Rule Conditions
Conditions define when a rule should trigger.
#### Select a Field
You may reference:
* **Alert Fields** (recommended)
* **Payload values via JSONPath**
#### Choose an Operator
Supported operators include:
* *is one of*
* *contains*
* *starts with*
* *matches regex*
* *is empty*
* and more
***
### Routing Rule Destinations
Each rule must specify **who receives the alert**. You may route alerts to:
* **Teams**
* **Services**
* **Escalation Policies**
Routing to a team or service automatically triggers its configured escalation policy.
This ensures responders understand *why* they were paged.
***
### Best Practices
* Prefer **Alert Fields** over JSONPath for stability.
* Start with broad routing categories and refine with specific rules.
* Keep rule names action-oriented and descriptive.
* Regularly check **Non-Paging Alerts** for routing gaps.
* Route to **teams/services**, not escalation policies, for better ownership.
* Combine routes thoughtfully when different teams own different tools.
***
### Troubleshooting
.png?fit=max&auto=format&n=usuFKS3869pMrird&q=85&s=b822f5cddb15db20f81a14f12421245d "Alert Status State Machine")
***
### Status Definitions
#### **open**
The alert has been created but **has not yet been assigned a notification target**.
Typical reasons for an `open` alert:
* The alert was ingested but did not match a Routing Rule
* The alert is a *non-paging alert*
* It was created manually without a destination
This status allows two transitions:
* `open → triggered` (once a notification target is assigned via routing or manual paging)
* `open → resolved`
For each rule:
* Choose whether to evaluate:
* **Payload (JSONPath)**
* **Alert Field** (recommended for long-term stability)
* Select an **operator**:
* `is`
* `is_not`
* `contains`
* `does_not_contain`
* Provide a comparison **value**
* Select which **Alert Urgency** to set when the rule matches
# Managing Built-In Fields
## Enable/Disable Field
Only enabled fields are considered to be live fields - meaning they can appear on UI screens and be updated during incidents. Disabled fields are NOT usable during incidents and cannot be updated by workflows either.
You can use the toggle switch next to the field name to enable/disable it.
## Edit Field
You can edit a specific field by clicking on the edit icon on the right-hand side of the field.
Once selected, you will see an Edit Form Field pane open. From here, you'll be able to edit how this particular field appears in the forms.
# Form Types
Get started with Rootly's custom lifecycle feature by reaching out to your account representative.
# **Edit Form**
To begin editing a form, select the Configure button under the form you'd like to edit.
You'll be navigated to the edit form page of the selected form. The **left side of the page is the edit pane** where you can edit what fields are displayed and how they are displayed. The **right side of the page is the preview** of the form.
Once these fields are added to your form, you can drag and drop them to reorder the form. Remove a field by selecting the **minus** button on the right hand side of the field.
## Editing fields on a form
Once a field is added to a form, you can edit how and when the field is filled out. Select the edit button on the field you want to make changes to.
### Conditionally display and require a field
Once a field is added to a form, you can control when the field is displayed and if it is required. Select the edit button on the field that you want to make changes to.
If you only want the field to display under certain conditions or be required under certain conditions, select the **Conditionally** option under \*\*\*\*Display this field \*\*\*\*or ****Require this field**** .
Form fields can be displayed or required conditionally depending on the value of any field set above the field that you're editing. For example, if the first field on your form called "Teams" is set to a certain value, your second field can be conditionally displayed depending on the team's value.
### Read-only fields
A field can be set to 'read-only', which means that the value cannot be overwritten by your users. This is particularly useful when you want to set a field value on an incident, but do not want it to be manually set by your team.
When this setting is turned on, the field value will always be set to the default value. You cannot turn this setting on unless the field has a default value: this can be editted in the Fields section of the dashboard.
# Overview
Source: https://docs.rootly.com/configuration/configuration
Configure incident properties, custom fields, and settings to characterize incidents, trigger workflows, and filter metrics across your organization.
Every incident created on Rootly can be marked with a set of properties. These properties can either be built-in or custom. Incident properties play a key role during incident management as they:
* help characterize each incident (e.g. kind = normal)
* can be used as trigger events (e.g. Status Updated)
* can help define run conditions (e.g. Severity is SEV0)
* can be used to filter metrics
* can be referenced using Liquid syntax
# Fixed Properties
Fixed properties cannot be customized. They are created as-is by Rootly and are restricted on purpose to enforce a certain level of standard across the platform.
## Incident Kind
The kind property is used by Rootly to identify the classification of incidents that are being created. This field cannot be customized and is determined at the time of incident creation.
| Kind | Description | Data Value |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------ |
| Incident | These are the most common incidents teams create. They are declared via the `/rootly new` Slack command. | `normal` |
| Sub Incident | These are child incidents that can be created under any normal incident. They are declared within an existing incident channel via the `/rootly sub` Slack command. | `normal_sub` |
| Test Incident | These are equivalent to a normal incident, but are used for testing purposes. Test incidents cannot be published on status pages. They are declared via the `/rootly test` Slack command. | `test` |
| Sub Test Incident | These are equivalent to a normal sub incident, but used for testing purposes. Sub test incidents also cannot be published on status pages. They are declared within an existing test incident channel via the `/rootly sub` Slack command. | `test_sub` |
| Backfill Incident | These are incidents that are added after an incident has already been resolved. When a backfill incident is declared, all workflows that trigger on Incident Created will not be run. They are declared via the `/rootly new` Slack command and with the Backfill Incident selected. | `backfilled` |
| Scheduled Maintenance | These are "incidents" that can be declared to planned maintenance cycles. They have their own unique statuses and other properties. They are declared via the `/rootly maintenance` Slack command. | `scheduled` |
## Incident Status
Incident status is a key component that drives incident response processes. As with the other properties in this section, status is also fixed and cannot be customized.
| Kind | Description | Data Value |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| Triage | The **triage** status is used for issues that have not been confirmed as an incident. To declare an incident in the triage status, simply check the *Mark as In Triage* checkbox when creating an incident. | `in_triage` |
| Started | This marks the official start of an incident. You can progress an incident from the triage status to started or declare an incident directly into the **started** status. | `started` |
| Mitigated | The **mitigated** status is used to signify that the incident impact has been halted. This is not the end of an incident. | `mitigated` |
| Resolved | The resolved status is used to signify the end of an incident. This is typically when retrospectives are created and active issue tickets are closed. | `resolved` |
| Cancelled | The **cancelled** status can be used at any point in the lifetime of an incident. It is typically used to mark a false-positive incident or close a duplicate incident. | `cancelled` |
| Scheduled | The \*\*scheduled \*\*status only applies to scheduled maintenance. It is used to indicate that the maintenance window has been planned and created. | `scheduled` |
| In Progress | The **in-progress** status only applies to scheduled maintenance. It is used to indicate that the maintenance window is currently active. | `in_progress` |
| Completed | The **completed** status only applies to scheduled maintenance. It is used to indicate that the planned maintenance has ended. | `completed` |
# Configurable Properties
Configurable properties are built-in, but they can be customized.
Go to the dedicated property article to learn how to configure each property and reference them using Liquid syntax.
| Property | Description |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Environments](/configuration/environments) | This property allows you to characterize incidents by the environment that they are impacting. For example, incidents impacting PROD should take priority over incidents only impacting DEV. |
| [Severities](/configuration/severities) | This property helps you categorize the impact level of incidents. For example, SEV0 incidents should take priority over SEV3 incidents. |
| [Incident Types](/configuration/incident-types) | This property is often confused with the *Kind* property. *Kind* is an internal categorization used by the Rootly platform, while *Type* can be customized to your company's incident categorization requirements. The usage of this property is very flexible. Some companies use this to distinguish UI bugs from API issues. Others use this property to distinguish internal outages from customer-facing incidents. |
| [Incident Roles](/configuration/incident-roles) | This property helps define your responders' responsibilities during an incident. For example, an *Incident Commander* will have different tasks from the *Communications Lead*. |
| [Teams](/configuration/teams) | This property lets you assign incidents to the responsible teams. For example, incidents relating to the product should go to the *Product* team. |
| [Services](/configuration/services) | This property lets you flag the service components that are impacted. Impacted services can be reflected on status pages. |
| [Functionalities](/configuration/functionalities) | This property lets you flag specific functional behaviors that are interrupted during incidents. For example, the ability to cart an item, or the ability to log in. Similar to *Services*, *Functionalities* can be displayed on status pages. |
| [Incident Causes](/configuration/incident-causes) | This property allows you to quickly categorize the root cause of incidents. This is particularly useful for identifying trends when analyzing historical incidents. |
## Property order
The order of items within each property is the order the items are displayed when the property is used as a form field. The order of items is global, meaning that it will impact every person who interacts with the field.
You can customize the order of items manually, by dragging and dropping the items into your preferred order, or by sorting alphabetically.
# Custom Properties
When the built-in properties are not enough to meet all your incident categorization requirements, teams can set up custom properties to further enhance their incident characterization.
Please see the [Custom Fields](/configuration/custom-fields) page to learn more about creating custom incident properties.
# Custom Fields
Source: https://docs.rootly.com/configuration/custom-fields
Create organization-specific incident fields with custom data types, validation rules, and integration mappings to meet unique incident management requirements.
# Overview
Rootly carefully selected the built-in properties based on common attributes used to characterize incidents. However, not all organizations are built the same and sometimes the built-in properties are not enough to meet everyone's requirements.
To enable a fully bespoke experience, Rootly introduced custom properties that can be set up to meet the exact specifications of your organization's incident management requirements.
# Managing Custom Fields
## Create Field
Select the Create New Form Field button to create a new custom field. The following details can be edited on a field:
A dialogue will appear requesting the following fields:
When you write the command in an incident Slack channel, you'll be prompted with the custom form.
## Prompt Form via Slack Block
A custom form can also be prompted in an incident Slack channel via a button in a custom block. The following demo will walk you through how to set this up.
## Prompt Form via Web UI
Lastly, a custom form can also be prompted from the Rootly web UI. First navigate to a specific incident and then select the Custom Form dropdown at the top. The dropdown will contain all custom forms that have been configured in the organization.
# Dynamic Forms
Source: https://docs.rootly.com/configuration/dynamic-forms
Configure form variations that adapt based on incident properties like type, team, or severity to collect contextually relevant information.
Rootly's dynamic forms allow for more granularity based on different incident types, different teams, or different severities that require different versions of the same forms. You can access the dynamic forms by navigating to **Configuration >** [**Forms**](https://rootly.com/account/forms).
The Dynamic Forms feature is not enabled out-of-box, but if you’d like to try it out, reach out to your Rootly point of contact or support team. [Video Example of Use Case](https://www.loom.com/share/11b9503c6bd94043bfafc6cdd5166021?sid=35cd9955-d742-45f3-b99f-b2840b3e0a74)
## Incident Property Field
The incident property is what is used to **base** the dynamic forms from. The options include Incident Type, Team, or Severity.
> This field is important as it drives the property in which you build your dynamic forms from
Once an incident property is selected, click `+ New Form Set` to create a dynamic form.
## **Creating Form Set**
* Name: Choose a unique name
* Use this form when \[incident type / team / severity]
* Then choose which default forms you would like to customize.
### Example Use Case
One of the main use cases for this is when you want to give more granularity on different teams, incident types, or severities, but you want them to have different versions of the same form. For example, when the information I want to collect for the `security teams` incidents is different than the information I want to collect for the `infrastructure teams` incidents. But within that, within the `security teams` forms, I actually want certain fields different based on if it’s a SEV0 incident.
Click 'Create Form Set'
Once created, you'll see the newly built 'Security Team Forms' on the left and the form types you wish to customize.
These new forms will only show when `Team` is `Security`
Next, we need to get more granular and only show these forms when the `Team` is `Security` **AND** the `Severity` is a `SEV0`. To do this, click 'Configure' on the form type you would like to edit.
The form will start empty, minus your incident property field, which in this case is `Teams`.
Add any custom or built-in fields by clicking 'Add Fields'
When the required fields are selected, click 'Add Fields'.
Edit each field and choose when to display and/or require this field, at this stage you can add conditions.
Set the field to only display when the incident is a `SEV0` , and **REQUIRE** the field. Click Save once the conditions are defined.
### To Test
Create a new incident and set the team to `Security`
Once `
### Removing An Existing Dynamic Form
Editing and deleting can be done by clicking on the ellipsis.
Only one property can be selected at a time. Removing the existing incident property selection will delete all existing dynamic forms. You will be prompted with a warning message prior.
### Want to use dynamic forms?
Yay! We can't wait! Please reach out to your Rootly point of contact or support team to request access.
# Environments
Source: https://docs.rootly.com/configuration/environments
Define and prioritize the environments (production, staging, development) affected by incidents to ensure proper response urgency and resource allocation.
## Overview
**Environments** allow you to characterize incidents by the environment that they are impacting. For example, incidents impacting PROD should take priority over incidents only impacting DEV.
## Field Type
**Environments** can be customized to be either a **select** or **multi-select** field type. This means you can configure it to allow only one environment value to be selected per incident or allow multiple environment values to be selected per incident.
## Attributes
**Environments** can be configured with the following attributes. Each environment attribute can be referenced via Liquid syntax.
# **Default Forms**
Rootly comes with a series of built-in forms that cannot be deleted. These forms are used to capture information about your incident at standard moments in your incident lifecycle, such as when the incident is created, updated, or cancelled.
The information captured on these forms can be completely customized by updating the form and adding or removing additional fields.
Learn about customizing these default forms on the [Built-In Forms](/configuration/built-in-forms) page.
# **Custom Forms**
Create a custom form to capture information outside of when your incident progresses or the lifecycle status changes. Custom forms can be opened and filled out through a Slack command or using a Slack block button.
To learn about how to create and manage custom forms, please see the [Custom Forms](/configuration/custom-forms) page.
# Sub-Status Forms
For our advanced customers that have access to Custom Lifecycles, Rootly creates a separate form for each custom substatus that you configure in the Lifecycle section of the application. These can be edited in the same way that default and custom forms can be under the substatus forms tab.
# **Built-In Fields**
Rootly comes with a series of built-in incident properties that are typically collected during incident responses. To learn about what can be customized and how to customize built-in fields, please see the [Built-In Fields](/configuration/built-in-fields) page.
# **Custom Fields**
If the built-in properties are not enough to address your requirements, Rootly offers the ability to create custom incident properties in various data types. To learn about how to create custom fields, please see the [Custom Fields](/configuration/custom-fields) page.
# Incident Roles
Source: https://docs.rootly.com/configuration/incident-roles
Define and manage incident response roles with clear responsibilities, tasks, and hierarchies to ensure effective team coordination during incidents.
When the next incident hits, your team should feel prepared. With Incident Roles, you can quickly and efficiently assign responsibilities to your team and define the hierarchy of command.
A swift response will help reduce the impact. By adding descriptions and tasks ahead of time, you can ensure your team knows exactly what to do.
### Built-in Roles
Rootly comes with four roles we consider essential for effective incident response.
**Commander**
The individual responsible for the overall management of the incident from start to finish. Delegation of tasks across the response team and final decision-making authority.
**Communications lead**
The individual responsible for managing internal and external communications to stakeholders outside of the response team.
**Executive Sponsor**
The individual responsible for complex decision making, often used for high-severity or sensitive incidents.
**Retrospective Owner**
The individual responsible for driving the post-incident retrospective process to completion.
### Add an Incident Role
# Field Type
*Type* can be customized to be either a **select** or **multi-select** field type. This means you can configure it to allow only one type value to be selected per incident or allow multiple type values to be selected for a single incident.
# Attributes
*Type* can be configured with the following attributes. Each type attribute can be referenced via Liquid syntax.
## Field Type
**Severity** is strictly a **select** field type. This means only one severity value can be assigned per incident.
## Attributes
**Severities** can be configured with the following attributes. Each severity attribute can be referenced via Liquid syntax.
### ID
This is the unique identifier of the severity. This field **cannot be customized**. Rootly will automatically assign the *ID* upon creation. It is typically used in Liquid references and API calls.
The following Liquid syntax will allow you to retrieve the severity *ID* that is selected for an incident:
`{{ incident.severity_id }}`
**OR**
`{{ incident.raw_severity | get: 'id'}}`
### Name
This is the value that is displayed on the UI for the severity. This field is customizable.
The following Liquid syntax will allow you to retrieve the severity *name* that is selected for an incident:
`{{ incident.severity }}`
**OR**
`{{ incident.raw_severity | get: 'name'}}`
### Slug
This is the string that is used to reference the severity in Liquid references. This field is automatically generated by lower-casing and hyphenating the severity *name*.
The following Liquid syntax will allow you to retrieve the severity *slug* that is selected for an incident:
`{{ incident.severity_slug }}`
**OR**
`{{ incident.raw_severity | get: 'slug'}}`
### Description
This value is displayed on the UI to further explain each severity. This field is customizable.
The following Liquid syntax will allow you to retrieve the severity *description* that is selected for an incident:
`{{ incident.raw_severity | get: 'description'}}`
### Color
Each severity can be assigned a color, which will be used for color-coding on metrics graphs.
## Field Type
**Teams** can be customized to be either a **select** or **multi-select** field type. This means you can configure it to allow only one team value to be selected per incident or allow multiple team values to be selected for a single incident.
## Attributes
**Teams** can be configured with the following attributes. Each team attribute can be referenced via Liquid syntax.
summary is present and enum fields (priority, status, kind) match allowed values. Check Jira fields if provided.
slack\_summary\_timestamp\
#### Follow-up creation
React with a 🔧 **wrench emoji** to convert the message into a follow-up.
Rootly will add a **white check mark emoji** on success.
***
### Creating Tasks and Follow-Ups from an Incident
Add a task or follow-up directly from the incident page.
During export, you may need to select:
* Which integration to use
* Project, board, team, or workspace
* Issue type or workflow state
* Whether to create a **subtask/sub-issue** when an incident already has a linked parent ticket
2. In the Create New Incident dialog, select the **Impacted Service**, which should be one of the services you integrated earlier with Rootly. Add a descriptive Title, and fill in any other fields as needed.
3. Click *Create Incident*. PagerDuty will create the incident and redirect you to its detail page, where you can view the incident’s status, responders, and associated alerts.
**Default Fields**
| Field | Description |
| :------------------ | :------------------------------------------------------------------- |
| **Title** | Title of the incident; also used to name the Slack incident channel. |
| **Summary** | A concise description of the issue. |
| **Severity** | Default levels SEV3 → SEV0. |
| **Type** | Default categories: Cloud, Security, Customer-Facing, Default. |
| **Mark as Private** | Restricts visibility to permitted users. |
**Additional Notes**
* Required fields are marked with a **\***
* Leaving **Title** blank triggers the **Automatic Incident Title Generator**
* Only privileged users can create or access **Private** incidents
* Private mode is ideal for sensitive or security-related issues
**Additional Notes**
* Required fields are marked with a **\***
* Leaving **Title** blank activates the **Automatic Incident Title Generator**
* Only owners, admins, or privileged users can create/view private incidents
* Private incidents are recommended for security-, privacy-, or customer-sensitive issues
You can optionally copy the structure from the Slack form using:
**Copy fields from Slack form**
* Left panel: current form structure
* Right panel: real-time preview
Configuration options include:
* **config\_adjectives** — list of allowed adjectives
* **config\_nouns** — list of allowed nouns
* Exclusion logic is automatic (based on 1 year of past incidents)
***
### What Is a Sub-Incident?
A sub-incident is a normal incident that is linked to a parent using `parent_incident_id`.\
Rootly automatically assigns the sub-incident a kind based on its parent:
* `normal_sub`
* `test_sub`
* `scheduled_sub`
When attaching an existing incident, Rootly updates its kind and sets its parent relationship.
***
### What Gets Inherited?
Depending on your configuration, sub-incidents may inherit:
* Severity
* Status
* Privacy settings
* Incident types
* Attached services, functionalities, environments
* Teams / groups
* Jira epic or Google Drive folder links
* Slack channel creation settings
* Parent → sub or sub → parent timeline syncing (feature-flag dependent)
The default *Maintenance Incident* form includes:
| Field | Content |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Title | Title of the incident. This will be used to create the channel name along with today's date. |
| Summary | A summary of the incident. |
| [Severity](https://docs.rootly.com/configuration/severities) | Defaults: Severity level from SEV3 to SEV0. |
| [Type](https://docs.rootly.com/configuration/incident-types) | The type of incident. Defaults: Cloud, Security, Customer facing, Default. |
| [Services](https://docs.rootly.com/configuration/services#services) | The service or services impacted. |
Most of the fields in the *maintenance incident* form can be customized and new fields can be added. If you want to gather more details, the form can be completely customized in the **Configuration** > **Forms** section of the web application.
The default *maintenance incident* form includes:
| Field | Content |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Title | Title of the incident. This will be used to create the channel name along with today's date. |
| Summary | A summary of the incident. |
| [Severity](https://docs.rootly.com/configuration/severities) | Defaults: Severity level from SEV3 to SEV0. |
| [Type](https://docs.rootly.com/configuration/incident-types) | The type of incident. Defaults: Cloud, Security, Customer facing, Default. |
| [Services](https://docs.rootly.com/configuration/services#services) | The service or services impacted. |
The maintenance incident is now available in the Rootly web app. To manage the incident in Slack, select *View in Rootly,* then click the Slack icon under the incident title.
Maintenance incidents can have the following statuses:
* Planning
* Scheduled
* In Progress
* Verifying
* Completed
* Cancelled
Change the status by clicking **Incident Status** in the top-right corner, or in Slack using the `/rootly status` command.
## **Update details**
Click **Edit** in the top-right corner to update the incident.
Default fields include:
| Field | Content |
| ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Scheduled start and end time | The planned time for the maintenance to take place. |
| Title | The title of the maintenance incident. This will only be visible in the Rootly web app or the incident Slack channel (if applicable). |
| [Severity](https://docs.rootly.com/configuration/severities) | Defaults: Severity level from SEV3 to SEV0. |
| [Type](https://docs.rootly.com/configuration/incident-types) | The type of incident. Defaults: Cloud, Security, Customer facing, Default. |
| [Services](https://docs.rootly.com/configuration/services#services) | The service or services impacted. |
| [Environments](https://docs.rootly.com/configuration/environments) | The environment the incident will impact. E.g. Dev or Production. |
| [Functionalities](https://docs.rootly.com/configuration/functionalities#functionalities) | Specific functionalities impacted. E.g. Checkout or Search. |
| [Teams](https://docs.rootly.com/configuration/teams#teams) | The relevant teams involved in this maintenance incident. |
The form can be edited from **Configuration** > **Forms & Fields** > **Update Maintenance Incident.**
## **Assign Roles**
Pre-assign roles to this maintenance incident by selecting "Assign Roles" under the incident title.
## **Create a Slack channel**
Select the Slack icon under the incident title to create a Slack channel for this maintenance incident.
# Publish your maintenance incident to a status page
Communicate your upcoming and active maintenance windows to your stakeholders through the Rootly Status Page.
Navigate to your maintenance window, select the **Status Page** tab, then **Publish Incident**.
Select the status page you'd like to publish an update to and fill in the subsequent information to include in the update.
Rootly will automatically surface any Maintenance Windows at the top of the status page.
Further, any services attached to your Maintenance Window will automatically be shown as \*\*In Maintenance \*\*if the update published to the status page is either **In Progress** or **Verifying.**
# Converting a maintenance incident
Sometimes, unexpected complexity might occur during your maintenance incident, and it requires a regular incident to be declared.
Rootly lets you convert an existing maintenance incident into a regular incident directly in Rootly Web, or via Slack.
## Converting to a regular incident on web
While viewing your Maintenance Incident on web, select (...), then**Convert to incident** .
Clicking on this button will trigger your Rootly **Create Incident** form, as well as a 'Reason for conversion' field for your commanders to fill out to give additional context for why the incident is being converted. The information provided in this field will be added to the incident's timeline.
## Converting to a regular incident on Slack
To convert your maintenance incident on Slack, in your maintenance incident's Slack channel use the `/rootly convert maintenance` command.
This will trigger your Rootly **Create Incident** form, as well as a 'Reason for conversion' field for your commanders to fill out to give additional context for why the incident is being converted. The information provided in this field will be added to the incident's timeline.
Once your maintenance incident is converted to a regular incident, all of your related automations and workflows will trigger much like they do when a new incident is created.
# Creating Sub-Incidents via Slack
Source: https://docs.rootly.com/incidents/incident-operations/slack-creating-a-sub-incident
Learn how to create sub-incidents directly from Slack incident channels using the /rootly sub command and interactive dialog.
### Overview
Create sub-incidents directly from an incident’s Slack channel using Rootly slash commands.\
Sub-incidents help teams split large or cross-functional incidents into focused workstreams while keeping everything tied back to the parent incident.
***
### Restrictions
Sub-incident creation is only available when:
* You run the command **inside an incident channel**
* The incident is **not already a sub-incident**
* You have **permission to create incidents**
* The incident has no restrictions (e.g., cannot split a sub-incident)
If these conditions are not met, Slack will show an appropriate error.
***
### How to Create a Sub-Incident in Slack
#### 1. Run the sub-incident command
In the parent incident channel, type **any** of the following:
```
/rootly sub
/rootly split
/rootly fork
/rootly swimlane
```
These commands all trigger the **Create Sub-Incident** dialog.
***
#### 2. Complete the creation dialog
Fill in the incident fields as you normally would.\
Rootly automatically links the new incident as a **sub-incident** of the channel you ran the command from.
After submitting, Slack will confirm that the sub-incident has been created:
You’ll then see a reference to the new sub-incident in the parent incident’s summary, Slack channel, and web interface.
***
### What Happens Behind the Scenes
Rootly automatically:
* Sets the new incident’s **parent\_incident\_id**
* Assigns a sub-incident kind (e.g., `normal_sub`, `scheduled_sub`)
* Attributes the creation to **Slack**
* Optionally creates a **Slack channel** for the sub-incident (team settings apply)
* Triggers any workflows conditioned on\
`Kind → is one of → normal_sub / scheduled_sub / test_sub`
A modal opens allowing you to select the original incident and configure cancellation options.
***
## Modal Fields
The Slack modal includes:
* **Assign to Incident** — search for the canonical incident
* **Auto Cancel Current Incident** — optional toggle (on by default)
* **Summary (reason for cancellation)** — optional free text, added to the timeline
***
### Step 2 — Complete the Sub-Incident Form
Selecting **Create Sub-Incident** opens the standard **New Incident** form.\
Rootly automatically injects a hidden `parent_incident_id`, ensuring the new incident is created as a sub-incident.
You can customize:
* Summary
* Severity
* Impacted services & functionalities
* Roles, assignees, and metadata
* Any fields defined in **Configuration → Forms & Fields**
Click **Create Incident** to finish.
***
### What Happens After Creation
Once saved:
* The new incident becomes a **sub-incident** of the parent
* Its **kind** is automatically derived (e.g., `normal_sub`, `scheduled_sub`)
* The parent incident displays a **Sub-Incidents** panel linking to all sub-incidents
**Option B: Use the slash command**
Run the command inside the incident channel:
```
/rootly assign
```
You may also use the aliases:
* `/rootly role`
* `/rootly roles`
## How to Publish Incidents
Rootly provides two main ways to publish incidents to status pages:
### Via Slack
Publish incidents directly from your incident channels using Slack commands and workflows.
[Learn how to publish incidents via Slack →](/configuration/publishing-incidents-via-slack)
### Via Web UI
Publish incidents through the Rootly web interface with full control over the incident details and status page presentation.
[Learn how to publish incidents via Web UI →](/configuration/publishing-incidents-via-web-ui)
# Adding Events to Timeline via Email
Source: https://docs.rootly.com/incidents/incident-timeline/adding-events-to-timeline-via-email
Learn how to add events to incident timelines by responding to incident emails through the Email integration.
### Overview
Using our [Email integration](/integrations/email), you can add timeline events simply by **replying to an incident email**.\
This makes it easy for stakeholders—especially those who don’t live in Slack or the web interface—to contribute updates directly to the incident record.
When you reply to an incident email, Rootly automatically logs that message as a timeline entry, preserving its content, sender information, and relevant metadata.
***
### How It Works
#### **Replying to an Existing Incident**
When you reply to an incident’s email thread:
* A new **Email** timeline event is automatically created
* The event includes:
* The parsed message body
* Sender information (matched to a Rootly user if possible)
* The To/From header values
* A permalink-style reference to the inbound message
* The event is timestamped using the time the email was received
* The event is **non-editable**, ensuring integrity
Rootly determines which incident the message belongs to by scanning the email’s **References** header, which preserves threading.
#### **Starting a New Incident by Email**
If an email is not part of an existing thread, Rootly can create a **new incident** using:
* The subject → incident title
* The body → summary
* Best-effort parsing to extract:
* Severity
* Services
* Functionalities
* Environments
* Incident types
The modal will auto-fill the message content and attach a permalink back to Slack.
You can configure which emoji should create events in **Slack Integration Settings**.
***
#### Option 2: Use the Slash Command
You can also open the integration editor by typing:
/incident integration
inside the incident channel.
Rootly will open a modal where you can update any of the available integration links.
***
### Available Timestamps[](#JSpOw)
Each Rootly incident comes default with the following timestamps:
| Name | Required? | Description | Liquid Variable |
| ------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
| In Triage | No | Before an incident starts, it can go through a triage state. This timestamp is automatically logged when the incident enters the `in_triage` state. | `{{ incident.in_triage_at }}` |
| Started | Yes | This marks the official start of an incident. This timestamp is automatically logged when the incident enters the `started` state. | `{{ incident.started_at }}` |
| Detected | No | This marks the time when the response team is informed. For many teams, the time in which the incident starts is also the time in which their responder team is informed. There is no "detected" state, so this timestamp is NOT automatically logged out of box. Teams can manually set it OR automatically set it through workflows. | `{{ incident.detected_at }}` |
| Acknowledged | No | This marks the time when the response team acknowledges that they are looking into the incident. For many teams, this timestamp is often tied to when the first responder acknowledges the page through an on-call solution (e.g. Rootly On-Call, PagerDuty, Opsgenie, etc.). There is no "acknowledged" state, so this timestamp is NOT automatically logged out of box. Teams can manually set it OR automatically set it through workflows. | `{{ incident.acknowledged_at }}` |
| Mitigated | Yes | This marks the time in which the impact of the incident is halted. This does NOT signify the end of an incident. This timestamp is automatically logged when the incident enters the `mitigated` state. | `{{ incident.mitigated_at }}` |
| Resolved | Yes | This marks the time in which the incident is resolved and all systems are running as normal. This timestamp is automatically logged when the incident enters the `resolved` state. | `{{ incident.resolved_at }}` |
| Cancelled | No | This marks the time in which the incident is cancelled. This timestamp is automatically logged when the incident enters the `cancelled` state. | `{{ incident.cancelled_at }}` |
***
### Updating Timestamps[](#h7GYn)
#### Manually Via Slack[](#CSRig)
Timestamps can be updated through the Rootly Slack bot by using the /incident timestamps Slack command.
#### Manually Via Web UI[](#gghbQ)
Timestamps can also be updated through the Rootly web UI from the Incident Details page.
Click on any timestamp at the top right hand corner of a specific incident.
A modal will pop up to allow you to edit each timestamp.
***
#### Automatically Via Workflow[](#-ha9q)
By default, Rootly will automatically log the *In Triage*, *Started*, *Mitigated*, and *Resolved* timestamps when the incident cycle enters those corresponding states. For the timestamps that Rootly do not automatically log out of box (*Detected* and *Acknowledged*), you can use a workflow to automate the logging. This method will work with all timestamps.
To automate via workflow, you'll want to trigger a workflow following a specific event that updates the the timestamp using the **Update Incident** workflow action
Then, use the following syntax in the Custom Field Mapping input textarea to systematically update the acknowledged timestamp.
```txt Custom Field Mapping theme={null}
{ "acknowledged_at": "
***
### Best Practices
* **Use the checkbox when cleaning up access**\
It ensures only users with the correct private incident permissions remain in the channel.
* **Be intentional about adding observers**\
Private incidents often involve sensitive operational or customer data.\
Grant access sparingly.
* **Review access during major incident transitions**\
For example, as roles shift or when incident severity changes.
* **Use workflows for structured access management**\
Workflows can automatically add on-call engineers, service owners, or leadership groups.
* **Keep private incidents small and focused**\
The fewer people involved, the faster and more aligned your response tends to be.
***
### Troubleshooting
## Pause a Schedule
In order to pause a Schedule, you will need to select the Escalation Policy from which the Schedule will be removed:
1. Navigate to On-Call --> Escalation Policies
2. Select the Escalation Policy from which you would like to remove the schedule.
3. Click 'Edit Escalation Policy'
4. Remove the User, Team or Channel under 'Who do we notify?'
5. Click 'Save Escalation Policy' to apply changes.
# Overview
Source: https://docs.rootly.com/on-call/escalation-policies
Learn how to get started with escalation policies.
## Create an Escalation Policy
Escalation policies are used to ensure timely and appropriate response by automatically notifying the right personnel when an incident exceeds predefined thresholds.
To create a new escalation policy in the web app:
1. Navigate to On-Call --> Escalation Policies and click + Add Escalation Policy.
2. Enter an Escalation Policy Name (required) and a Description (optional).
### Step 3: Choose Repeat Option
* Here you can choose if you want to repeat your escalation policy X amount of times if the first round of paging does not receive an acknowledgement
### Step 4: Save Escalation Policy
### Step 5: Assign Escalation Policy to a Service or Team
* In order for your escalation policy to be live, you will need to assign it to a Service or Team
1. Assigning to Team
* Find the Team you would like to assign the newly created escalation policy to and click Edit or create a new team
* Under On-Call tab while editing team, select desired escalation policy
1. Assigning to Service
* Find the Service you would like to assign the newly created escalation policy to and click Edit or + Add Service or Import Services
* Under On-Call tab while editing team, select desired escalation policy
## Edit an Escalation Policy
1. Navigate to On-Call --> Escalation Policies
2. Select an escalation policy to edit by clicking '...' and selecting Edit.
3. Enter an Escalation Policy Name (required) and a Description (optional).
## Delete an Escalation Policy
1. Navigate to On-Call --> Escalation Policies
2. Select an escalation policy to delete by clicking '...' and selecting Delete.
3. Confirm your selection in the dialog window.
## Working with holiday calendars
While previewing a holiday calendar, Rootly will highlight on-call shifts that have potential conflicts with your holiday calendar, such as a responder being on vacation.
Check out [Creating Overrides](https://docs.rootly.com/on-call/on-call-shifts#create-overrides-for-on-call-shifts) to learn how to update your schedule to ensure you have coverage when responders are not available to take their shift.
# Live Call Routing
Source: https://docs.rootly.com/on-call/live-call-routing
Learn how to set up live call routing!
### Overview
Live Call Routing offers two options for handling urgent incidents: calls can either be routed instantly to the on-call team member for immediate response, or directed to a voicemail where the message is logged and the team is alerted. This flexibility ensures that critical issues are managed effectively, whether they require immediate attention or can be addressed shortly after.
### Configuring Live Call Routing
To create a new routing number in the web app:
1. Navigate to On-Call tab --> Live Call Routing Tab and click + New Routing Number.
2. Choose between Route to Voicemail or Connect Live
### Route to Voicemail
Selecting route to voicemail will route calls directly to voicemail for message logging and reviewing
#### Number
* Give your new routing number a Name (required)
* Select a Country (required)
* Select a Number Type (required)
* Once saved you will see Your Number appear
#### Routing Rules
* Define Who do you want to page? (required)
* Sent an Alert Urgency (required)
You can use a single phone number to route callers to many different destinations: this is a great option if you only want your callers to use a single phone number to page any of your teams and services.
When you add more than one Paging target to your Live Call Routing number, Rootly will create an IVR calling tree automatically. This allows your callers to input their preferred paging destination with their dial pad.
Each paging target can be routed to based on the corresponding number in the left hand column: for example, `Security` will be paged when your caller selects 1, and `DB - Production Database` will be paged when your caller selects 2.
Make sure to add instructions to let your caller know which number to select to route to their preferred destination. Rootly reserves `*` if the caller wants to listen to the options again.
#### Greetings
Add a greeting message for how would you like to greet your caller. This will be the initial message Rootly will read to your callers.
### Connect Live
Selecting Connect Live will connect the caller live to an on-call team member for immediate response.
#### Number
* Give your new routing number a Name (required)
* Select a Country (required)
* Select a Number Type (required)
* Once saved you will see Your Number appear
#### Routing Rules
* Define Who do you want to page? (required)
* Sent an Alert Urgency (required)
You can use a single phone number to route callers to many different destinations: this is a great option if you only want your callers to use a single phone number to page any of your teams and services.
When you add more than one Paging target to your Live Call Routing number, Rootly will create an IVR calling tree automatically. This allows your callers to input their preferred paging destination with their dial pad.
Each paging target can be routed to based on the corresponding number in the left hand column: for example, `Security` will be paged when your caller selects 1, and `DB - Production Database` will be paged when your caller selects 2.
Make sure to add instructions to let your caller know which number to select to route to their preferred destination. Rootly reserves `*` if the caller wants to listen to the options again.
Under Advanced Settings in your Routing Rules tab:
* You can choose to Redirect the caller to voicemail if there has been no answer after X amount of time
* Choose how quickly you want to Escalate to the next Escalation Policy after X amount of time
* This will override the length of time between levels on your escalation policy since most users want a faster escalation since it is a live environment.
* Choose to Auto-resolve the alert when the call ends
#### Greetings
* Add a greeting message for How would you like to greet your caller?
* Set Waiting music
* Add a Voicemail prompt
* This will be the message that is played when the caller is sent to voicemail
* Click Create Routing Number
### Supported Countries
Live Call Routing is available in the following countries:
| Country | Code |
| -------------- | ---- |
| Australia | AU |
| Canada | CA |
| Germany | DE |
| Netherlands | NL |
| New Zealand | NZ |
| United Kingdom | GB |
| United States | US |
If your country is not listed above, please contact your Rootly representative to discuss availability in your region.
***
### Best Practices
* Use **Connect Live** for critical, urgent systems
* Use **Route to Voicemail** for low-severity or non-production services
* Create a **single company-wide routing number** using a calling tree to direct to all teams
* Keep prompts short and clear (⅔ callers hang up when IVR menus are confusing)
* Assign meaningful digits (e.g., 1 = Security, 2 = On-Call, 3 = Database)
* Prefer shorter **escalation delays** for live calls
***
### Troubleshooting
## 📊 Default Dashboard Metrics
Your On-Call Metrics dashboard includes these key performance indicators:
### Core Response Metrics
* **📈 Total Alerts**: Complete count of alerts triggered in your Rootly instance
* **⏱️ Mean Time to Acknowledge (MTTA)**: Average time from alert trigger to acknowledgment
* **🔧 Mean Time to Resolve (MTTR)**: Average time from alert trigger to resolution
* **📉 Mean Time Between Failures**: Average duration between alert triggers (indicates paging frequency)
* **✅ Acknowledge Rate**: Percentage of alerts acknowledged by responders
### Performance by Category
* **👤 MTTA by Responder**: Individual response times per team member
* **🔧 MTTR by Service**: Resolution times broken down by affected service
* **📊 Response Effort**: Total time invested in incident response (acknowledgment to resolution)
### Distribution Analytics
* **📍 Alerts by Source**: Alert volume per monitoring source
* **👥 Alerts by Responder**: Alert handling distribution across team members
* **🚨 Alerts by Urgency**: Alert breakdown by priority level
* **🔄 Alerts by Escalation Policy**: Alert volume per escalation workflow
* **🏢 Alerts by Service**: Alert distribution across your services
## 🎨 Customizing Your Dashboard
Your On-Call Metrics dashboard is fully customizable to match your team's specific needs:
**Modify Existing Panels**
* Hover over any panel and select **Settings** to customize chart configurations
* Adjust time ranges, filters, and visualization types
**Add New Panels**
* Click **"Add Panel"** to track additional metrics important to your team
* Choose from various chart types and data sources
## 📈 Comprehensive Incident Response Measurement
Rootly enables end-to-end measurement of your incident response lifecycle - from initial alert to post-incident analysis.
### Creating Custom Analytics Dashboards
1. **Navigate** to Rootly's **Metrics** tab
2. **Select** **"New Dashboard"**
3. **Click** **"Add Panel"** and configure your visualization
4. **Choose your data source**:
* **"Alerts"** collection → On-call response metrics
* **"Incidents"** collection → Incident response metrics
Add Step(s) for how and when you want to be notified. Use the Test Notifications button at the bottom of the page to test out your selected notification methods.
### Audible Notifications
Think of your Audible Notification settings for how you'll be paged for an urgent issue.
Rootly requires you to receive a Critical Alert (i.e. a push notification through our app that bypasses your Do Not Disturb settings), or a phone call if you haven't otherwise set up the Rootly Mobile App.
### Quiet Notifications
Think of your Quiet Notification settings for how you'll be paged for low criticality issues.
Quiet notifications can be delivered with minimal disruption, allowing on-call responders to receive important updates without the urgency of immediate action unless necessary.
## Configuration
Before generating your first pay report, you'll need to configure your **pay rules**. These settings determine how time is calculated and what information is included in your reports.
Each icon on the report indicates the methods the responder is able to receive alerts through: green icons indicate the responder has opted in to the notification, whereas grey indicates that it hasn't been configured.
## Define Active Hours
The Page shadow user during specific hours toggle allows you to set specific hours for which you want the shadow user to be paged. This is great for when you have a 24/7 schedule but you only want the shadow users to be paged during their business hours and not necessarily 24/7. You can also include weekends here if desired by checking the Include weekend check box.
## Add Shadow Users
A Shadow User can be set up to shadow an entire schedule OR only shadow a specific on-call user that's part of the given schedule.
Once ready to add shadow users, you will click Add shadow user.
### Shadow a User
To have a user shadow a team member, you would select Shadow a user mode. This will allow you to set a specific user to shadow, as well as the duration in which you would like the shadowing to occur.
### Shadow a Schedule
To have a user shadow and entire schedule, you would select Shadow a schedule mode.
You can have multiple shadow users shadowing at the same time(or different times), while allowing them to shadow specific users or schedules.
### View Shadow User on Calendar
You can quickly see who is shadowing by clicking on a shift that has the ghost icon. You will see shadow users listed below the on-call user.
Once shadowing duration has completed, shadow users will automatically be removed from the schedule. There is no need to manually remove them post shadow assignment.
# On-Call Shifts
Source: https://docs.rootly.com/on-call/on-call-shifts
Quickly see when you're on-call next by viewing your shifts.
On-Call Shifts allows users to view their current and upcoming on-call shifts and those of other users in a single, easy-to-use page.
## On-Call Shifts - Web App
To view on-call shifts, navigate to On-Call --> On-Call Shifts page.
Shifts will be grouped based on their status:
* Currently On-Call - User's current on-call shifts.
* Upcoming On-Call - User's upcoming on-call shifts.
* Inactive On-Call - User's inactive on-call shifts due to the schedule not having been assigned to any Escalation Policy.
## Shift Types
### Always on-call shifts
Always on-call shifts will appear under the Currently On-Call section. On the calendar, these will appear as a solid horizontal shift at the top of the calendar.
### Recuring on-call shifts
Recurring on-call shifts will appear under the Currently On-Call and Upcoming On-Call sections. On the calendar, these will appear on the calendar as a solid vertical colour shift
## View Shifts of Other Users
To view shifts of other users, select the User dropdown and search or scroll for the User.
## Viewing holiday conflicts
Upload a Holiday Calendar to preview your team's vacations and upcoming national holidays within the Rootly shift and schedule view.
While previewing a holiday calendar, Rootly will automatically identify shifts that may have conflicts with your scheduled holidays.
You can quickly create an override to address this conflict either by selecting the holiday event, or the conflicting shift.
## Create Overrides for On-Call Shifts
To create an override for on-call shifts, you can do so by:
1. Navigate to On-Call --> On-Call Shifts
2. Select the User you would like to create an override shift for.
3. Click the 'Create Override' button on the top-right corner or select shift, and in the popover, click the 'Create Override' button.
4. The User whose shifts are filtered in the side draw will appear by default.
5. Select which shifts that will be overridden during your selected timeframe.
6. Select the user who will be assigned to this override shift.
7. Click 'Create Override' to apply changes.
## Reassign or Revert an Override
1. Navigate to On-Call --> On-Call Shifts
2. Select the User from which you would like to reassign or revert the override shift.
* Shifts that are overrides will have an 'Override' tag on them
### Revert Override
1. Select the override shift you would like to Revert to the original assignee.
2. Click 'Revert to original' to assign the shift back to the original user.
# Opsgenie Migration
Source: https://docs.rootly.com/on-call/opsgenie-migration
Migrate users, schedules, escalation policies, and notification settings from Opsgenie to Rootly On-Call with API-based data transfer.
## Migration Attributes
The following attributes will be migrated from Opsgenie to Rootly during the data transfer process.
### 👥 Users
**User Matching & Creation**
* Users are matched between platforms based on email addresses
* If no match is found, new users are automatically created in Rootly
**Contact Methods**
* ✅ Email addresses
* ✅ Phone numbers
* ✅ SMS numbers
**Notification Rules**
* Notification rules are mapped when compatible between platforms
* Incompatible rules are skipped during migration
### 📅 Schedules
**Schedule Components**
* ✅ Schedule configurations
* ✅ Individual shifts
* ✅ Rotation patterns:
* Daily rotations
* Weekly rotations
* Custom rotation schedules
### 🚨 Escalation Policies
* Escalation policies are mapped with their associated schedules from Opsgenie
## Migration Process
### Step 1: Initial Consultation
During your onboarding experience, you'll be asked about Opsgenie migration. Your onboarding representative will gather:
* **Migration scope**: Which attributes you want to migrate from Opsgenie to Rootly
* **Timeline**: When you'd like the migration performed
### Step 2: API Access Setup
To enable the migration, you'll need to provide an Opsgenie API key:
1. Navigate to **Settings > App Settings > API key management** in Opsgenie
2. Click **"Add new API key"**
3. Name your API key and select **"Read"** permissions for necessary resources
4. Copy the generated API key
On the **Schedule** page, edit a schedule that you are actively on the rotation for. Then select the **Override & Coverage** tab and click the **Request Coverage** button.
Follow the steps in the modal to create your Coverage Request:
1. Add the start and end time in which you are not able to be on call for.
2. Rootly will retrieve all of the shifts that you were scheduled to be on call for during that period of time.
3. You can click the submit Coverage Request button to notify all of your other teammates that you were unable to be on call for those shifts.
### On Slack
You can submit a Coverage Request by running `/rootly override` in Slack. Enter the period of time in which you need a coverage request for, and hit **Next**. Rootly will fetch the shifts that you have scheduled during that period of time: you'll be able to review these in the next modal.
When you're ready to submit your coverage request, simply click **Request Coverage**.
### \[Coming Soon] On Mobile
## Managing Coverage Requests
You're able to see all of your existing coverage requests in the Rootly web application. Navigate to **On-Call >** **Shifts**, and then the **Coverage Request** tab to see any of your open coverage requests.
Once someone accepts your coverage request, the request will be removed from this view and your shift will be automatically reassigned to that person.
## Accepting Coverage Requests
Anyone on the schedule is able to accept the coverage request on Web, Slack, and (coming soon) Mobile.
Only one person can accept the coverage request: once it's accepted and the shift has been reassigned, Rootly will let anyone else who tries to accept the shift know that it's already been taken.
You can either accept the request from here, view the shift in the Rootly web app for more details, or simply ignore it.
### \[Coming Soon] On Mobile
# Round Robin Functionality
Source: https://docs.rootly.com/on-call/round-robin-functionality
Learn about the Round Robin functionalities.
## Overview
Rootly's round robin feature introduces a streamlined way to manage escalation policies by automatically rotating the paging responsibilities among on-call team members. This ensures that alerts are distributed evenly and efficiently, reducing the burden on any single individual.
This feature is included out-of the box and is available for use today.
## Key Features
### Paging Methods
#### Alert-Based Paging
This is the most common style of round robin paging. Incoming alerts are cycled through the rotation of users. For example, the first incoming will page User A, if User A doesn't respond, it will escalate to level 2. The next incoming alert will page User B to ensure even distribution of alerts.
#### Cycle-Based Paging
The cycle-based feature ensures each user in the escalation level is paged in sequential order before escalating to the next level.
### Dynamic Updates
Rootly's web UI dynamically updates to show the current pageable person and the order of escalation. Timeline events also indicate the strategy used for each page.
### Configuring Round Robin
1. Navigate to Escalation Policies:
* Go to the escalation policies section in your Rootly dashboard.
* On-Call --> Escalation Policies
2. Create/Select an Escalation Policy:
* Create a new escalation policy or choose an existing policy you want to configure for round robin.
3. Enable Round Robin:
* When the feature flag for round robin is enabled, toggle the round robin option in each escalation policy level.
4. Select either Alert-Based or Cycle-Based Paging:
* Set the levels to be alert-based, where each new alert pages the next person in line.
#### Example Scenario (Alert-based)
In this example, we have an escalation policy named "SRE - Round Robin EP" with one round robin alert-based level. The first pageable person is Alexandra. When alert A comes in, if Alexandra doesn't respond within five minutes, the alert moves to Andre, and then to Purvai.
* When alert B comes in, it will then go to Shadab and then escalate to the next level.
* When alert C comes in, it will then go to Andre and then escalate to the next level.
1. Initial Alert:
* Alexandra receives the first alert.
2. Escalation to Next Person:
* After five minutes without a response, the alert escalates to Andre.
3. Further Escalation:
If Andre also doesn’t respond, the alert moves to Purvai.
4. Repeat Cycle:
* The repeat feature cycles the alerts back to Alexandra after Purvai.
#### Example Scenario (Cycle-Based)
In this example, we have an escalation policy named "SRE - Round Robin EP" with one cycle-based level. The first pageable person is Alexandra. When alert A comes in, it will first go to Alexandra and if she does not respond, then the alert moves to Shadab, and then to Andre.
1. Initial Alert:
* Alexandra receives the first alert.
2. Escalation to Next Person:
* After one minute without a response, the alert escalates to Shadab.
3. Further Escalation:
* If Shadab also doesn’t respond, the alert moves to Andre.
4. Repeat Cycle:
* The repeat feature cycles the alerts back to Alexandra after Andre.
### Timeline Events
Timeline events will now show an indication of the strategy used for each page, providing clarity on how the alert was escalated and which strategy was employed.
# Overview
Source: https://docs.rootly.com/on-call/schedules
Learn how to get started with on-call schedules.
## Create a Schedule
Schedules are used to determine which user or team will be on-call and in what order.
# Supported Countries
Source: https://docs.rootly.com/on-call/supported-countries
Countries supported for SMS and phone call notifications in Rootly On-Call
Rootly On-Call uses Twilio to deliver SMS and phone call notifications to on-call responders. This page lists the countries where these notification methods are supported.
| Country | Code |
|---|---|
| Afghanistan | +93 |
| Albania | +355 |
| American Samoa | +1 |
| Andorra | +376 |
| Anguilla | +1264 |
| Antigua and Barbuda | +1268 |
| Argentina | +54 |
| Armenia | +374 |
| Aruba | +297 |
| Australia | +61 |
| Austria | +43 |
| Bahamas | +1242 |
| Bahrain | +973 |
| Barbados | +1246 |
| Belarus | +375 |
| Belgium | +32 |
| Belize | +501 |
| Benin | +229 |
| Bermuda | +1441 |
| Bhutan | +975 |
| Bolivia | +591 |
| Bosnia and Herzegovina | +387 |
| Botswana | +267 |
| Brazil | +55 |
| Brunei | +673 |
| Bulgaria | +359 |
| Burkina Faso | +226 |
| Cambodia | +855 |
| Cameroon | +237 |
| Canada | +1 |
| Cape Verde | +238 |
| Cayman Islands | +1345 |
| Central African Republic | +236 |
| Chad | +235 |
| Chile | +56 |
| China | +86 |
| Colombia | +57 |
| Comoros | +269 |
| Congo | +242 |
| Congo (DRC) | +243 |
| Cook Islands | +682 |
| Costa Rica | +506 |
| Croatia | +385 |
| Cuba | +53 |
| Cyprus | +357 |
| Czech Republic | +420 |
| Denmark | +45 |
| Djibouti | +253 |
| Dominica | +1767 |
| Dominican Republic | +1829 |
| Egypt | +20 |
| El Salvador | +503 |
| Equatorial Guinea | +240 |
| Eritrea | +291 |
| Estonia | +372 |
| Ethiopia | +251 |
| Faroe Islands | +298 |
| Fiji | +679 |
| Finland | +358 |
| France | +33 |
| French Guiana | +594 |
| French Polynesia | +689 |
| Gabon | +241 |
| Gambia | +220 |
| Georgia | +995 |
| Germany | +49 |
| Ghana | +233 |
| Gibraltar | +350 |
| Greece | +30 |
| Greenland | +299 |
| Grenada | +1473 |
| Guadeloupe | +590 |
| Guam | +1671 |
| Guatemala | +502 |
| Guinea | +224 |
| Guinea-Bissau | +245 |
| Guyana | +592 |
| Haiti | +509 |
| Honduras | +504 |
| Hong Kong | +852 |
| Hungary | +36 |
| Iceland | +354 |
| India | +91 |
| Indonesia | +62 |
| Iraq | +964 |
| Ireland | +353 |
| Israel | +972 |
| Italy | +39 |
| Ivory Coast | +225 |
| Jamaica | +1876 |
| Japan | +81 |
| Jordan | +962 |
| Kazakhstan | +7 |
| Kenya | +254 |
| Kiribati | +686 |
| Korea (South) | +82 |
| Kuwait | +965 |
| Kyrgyzstan | +996 |
| Laos | +856 |
| Latvia | +371 |
| Lebanon | +961 |
| Lesotho | +266 |
| Liberia | +231 |
| Libya | +218 |
| Liechtenstein | +423 |
| Lithuania | +370 |
| Luxembourg | +352 |
| Macao | +853 |
| Macedonia | +389 |
| Madagascar | +261 |
| Malawi | +265 |
| Malaysia | +60 |
| Maldives | +960 |
| Mali | +223 |
| Malta | +356 |
| Marshall Islands | +692 |
| Martinique | +596 |
| Mauritius | +230 |
| Mexico | +52 |
| Micronesia | +691 |
| Moldova | +373 |
| Monaco | +377 |
| Mongolia | +976 |
| Montenegro | +382 |
| Montserrat | +1664 |
| Morocco | +212 |
| Myanmar | +95 |
| Namibia | +264 |
| Nepal | +977 |
| Netherlands | +31 |
| Netherlands Antilles | +599 |
| New Caledonia | +687 |
| New Zealand | +64 |
| Nicaragua | +505 |
| Niger | +227 |
| Norway | +47 |
| Palau | +680 |
| Panama | +507 |
| Papua New Guinea | +675 |
| Paraguay | +595 |
| Peru | +51 |
| Philippines | +63 |
| Poland | +48 |
| Portugal | +351 |
| Puerto Rico | +1787 |
| Qatar | +974 |
| Reunion | +262 |
| Romania | +40 |
| Russia | +7 |
| Samoa | +685 |
| San Marino | +378 |
| Saudi Arabia | +966 |
| Serbia | +381 |
| Sierra Leone | +232 |
| Singapore | +65 |
| Solomon Islands | +677 |
| Spain | +34 |
| St Kitts and Nevis | +1869 |
| St Lucia | +1758 |
| St Pierre and Miquelon | +508 |
| St Vincent Grenadines | +1784 |
| Suriname | +597 |
| Swaziland | +268 |
| Sweden | +46 |
| Switzerland | +41 |
| Taiwan | +886 |
| Thailand | +66 |
| Tonga | +676 |
| Trinidad and Tobago | +1868 |
| Turkey | +90 |
| Turkmenistan | +993 |
| Turks and Caicos Islands | +1649 |
| Ukraine | +380 |
| United Arab Emirates | +971 |
| United Kingdom | +44 |
| United States | +1 |
| Uruguay | +598 |
| Vanuatu | +678 |
| Vietnam | +84 |
| Virgin Islands (British) | +1284 |
| Virgin Islands (U.S.) | +1340 |
| Yemen | +967 |
| Country | Code |
|---|---|
| Afghanistan | +93 |
| Albania | +355 |
| American Samoa | +1 |
| Andorra | +376 |
| Anguilla | +1264 |
| Antigua and Barbuda | +1268 |
| Argentina | +54 |
| Armenia | +374 |
| Aruba | +297 |
| Australia | +61 |
| Austria | +43 |
| Bahamas | +1242 |
| Bahrain | +973 |
| Barbados | +1246 |
| Belarus | +375 |
| Belgium | +32 |
| Belize | +501 |
| Benin | +229 |
| Bermuda | +1441 |
| Bhutan | +975 |
| Bolivia | +591 |
| Bosnia and Herzegovina | +387 |
| Botswana | +267 |
| Brazil | +55 |
| Brunei | +673 |
| Bulgaria | +359 |
| Burkina Faso | +226 |
| Cambodia | +855 |
| Cameroon | +237 |
| Canada | +1 |
| Cape Verde | +238 |
| Cayman Islands | +1345 |
| Central African Republic | +236 |
| Chad | +235 |
| Chile | +56 |
| China | +86 |
| Colombia | +57 |
| Comoros | +269 |
| Congo | +242 |
| Congo (DRC) | +243 |
| Cook Islands | +682 |
| Costa Rica | +506 |
| Croatia | +385 |
| Cuba | +53 |
| Cyprus | +357 |
| Czech Republic | +420 |
| Denmark | +45 |
| Djibouti | +253 |
| Dominica | +1767 |
| Dominican Republic | +1829 |
| Egypt | +20 |
| El Salvador | +503 |
| Equatorial Guinea | +240 |
| Eritrea | +291 |
| Estonia | +372 |
| Ethiopia | +251 |
| Faroe Islands | +298 |
| Fiji | +679 |
| Finland | +358 |
| France | +33 |
| French Guiana | +594 |
| French Polynesia | +689 |
| Gabon | +241 |
| Gambia | +220 |
| Georgia | +995 |
| Germany | +49 |
| Ghana | +233 |
| Gibraltar | +350 |
| Greece | +30 |
| Greenland | +299 |
| Grenada | +1473 |
| Guadeloupe | +590 |
| Guam | +1671 |
| Guatemala | +502 |
| Guinea | +224 |
| Guinea-Bissau | +245 |
| Guyana | +592 |
| Haiti | +509 |
| Honduras | +504 |
| Hong Kong | +852 |
| Hungary | +36 |
| Iceland | +354 |
| India | +91 |
| Indonesia | +62 |
| Iraq | +964 |
| Ireland | +353 |
| Israel | +972 |
| Italy | +39 |
| Ivory Coast | +225 |
| Jamaica | +1876 |
| Japan | +81 |
| Jordan | +962 |
| Kazakhstan | +7 |
| Kenya | +254 |
| Kiribati | +686 |
| Korea (South) | +82 |
| Kuwait | +965 |
| Kyrgyzstan | +996 |
| Laos | +856 |
| Latvia | +371 |
| Lebanon | +961 |
| Lesotho | +266 |
| Liberia | +231 |
| Libya | +218 |
| Liechtenstein | +423 |
| Lithuania | +370 |
| Luxembourg | +352 |
| Macao | +853 |
| Macedonia | +389 |
| Madagascar | +261 |
| Malawi | +265 |
| Malaysia | +60 |
| Maldives | +960 |
| Mali | +223 |
| Malta | +356 |
| Marshall Islands | +692 |
| Martinique | +596 |
| Mauritius | +230 |
| Mexico | +52 |
| Micronesia | +691 |
| Moldova | +373 |
| Monaco | +377 |
| Mongolia | +976 |
| Montenegro | +382 |
| Montserrat | +1664 |
| Morocco | +212 |
| Myanmar | +95 |
| Namibia | +264 |
| Nepal | +977 |
| Netherlands | +31 |
| Netherlands Antilles | +599 |
| New Caledonia | +687 |
| New Zealand | +64 |
| Nicaragua | +505 |
| Niger | +227 |
| Norway | +47 |
| Palau | +680 |
| Panama | +507 |
| Papua New Guinea | +675 |
| Paraguay | +595 |
| Peru | +51 |
| Philippines | +63 |
| Poland | +48 |
| Portugal | +351 |
| Puerto Rico | +1787 |
| Qatar | +974 |
| Reunion | +262 |
| Romania | +40 |
| Russia | +7 |
| Samoa | +685 |
| San Marino | +378 |
| Saudi Arabia | +966 |
| Serbia | +381 |
| Sierra Leone | +232 |
| Singapore | +65 |
| Solomon Islands | +677 |
| Spain | +34 |
| St Kitts and Nevis | +1869 |
| St Lucia | +1758 |
| St Pierre and Miquelon | +508 |
| St Vincent Grenadines | +1784 |
| Suriname | +597 |
| Swaziland | +268 |
| Sweden | +46 |
| Switzerland | +41 |
| Taiwan | +886 |
| Thailand | +66 |
| Tonga | +676 |
| Trinidad and Tobago | +1868 |
| Turkey | +90 |
| Turkmenistan | +993 |
| Turks and Caicos Islands | +1649 |
| Ukraine | +380 |
| United Arab Emirates | +971 |
| United Kingdom | +44 |
| United States | +1 |
| Uruguay | +598 |
| Vanuatu | +678 |
| Vietnam | +84 |
| Virgin Islands (British) | +1284 |
| Virgin Islands (U.S.) | +1340 |
| Yemen | +967 |
Once configured, anytime this Slack user group is mentioned in a message, the on-call responder will be notified.
You can sync a single Slack user group across multiple schedules. For example, if your team wants to be able to tag all on-call responders across schedules, use the same Slack user group when configuring each schedule. When this user group is mentioned, each responder will be notified.
# Live Demo
Source: https://docs.rootly.com/quick-start-guide
Get up and running with Rootly in about 15 minutes! This guide covers everything from signing up to creating your first incident, plus an introduction to Rootly's key features.
## Watch our Demo Video
Get familiar with Rootly's capabilities by watching our comprehensive demo:
## Up and running in less than 15 minutes!
This quick start guide will take you from signing up for an account to creating your first incident in about 15 minutes.
The process involves three key steps:
1. [**Sign up**](/signing-up) - Create your Rootly account
2. [**Connect Slack**](/integrating-with-slack) - Integrate with your workspace
3. [**Create your first incident**](/incidents/creating-incidents-via-slack) - Try it out!
Once you've completed these steps, you should explore our full documentation to continue configuring Rootly for an optimal incident management experience.
## Need Help?
Visit our [Help and Support](https://rootly.com/help) page for more resources and assistance when you need it.
# Signing Up
Source: https://docs.rootly.com/signing-up
To start using Rootly, you'll need to either sign up for an account or check your inbox for an invite your company has sent you.
Users can complete sign-up with Google, Slack, SSO, or by creating a password. Passwords must have at least 10 characters and include:
* One lowercase letter
* One uppercase letter
* One digit
* One special character
Check the box to accept the Terms of Service and Privacy Policy, then click **Sign Up**.
That's it! You're ready to start using Rootly to help manage your incidents.
# User Profile
Source: https://docs.rootly.com/user-profile
Set up your user profile with Contact Information, Notification Rules, User Settings and manage Passwords Your user profile is where you will configure important personal settings, such as contact information and notification rules to receive timely incident notifications.
To access your user profile settings:
From the Dashboard, click on your **profile icon** in the **top-left corner**
You can now configure the following items in the user profile:
## Reset Password
You can reset your password here by entering your current password and new password.
## Notifcations
Manage **Incident Notifications** such as email notifications and Slack notifications in this tab.
## Linked Accounts
Linked Accounts is where can see your connected accounts such as Slack.
## Subscriptions
In the **Subscriptions** tab, you can manage your **broadcast groups** and choose which types of incident updates or system notifications you want to receive.
# Action Item Workflows
Source: https://docs.rootly.com/workflows/action-item-workflows
Automate follow-up processes by creating workflows triggered by action item changes to manage Jira tickets and team notifications.
# **Overview**[](#xSZMd)
Action item workflows are triggered on changes to the action item data. Every incident created on the Rootly platform also contains an array of action items. You can leverage the power of workflows to auto create Jira tickets for follow-ups, assign Jira tasks , etc.
Action item workflows are particularly useful for...
* **Auto creating/updating Jira tickets** for follow-ups post incident resolution
* **Auto assigning Jira tickets** based on user/team assigned in Rootly
* **Notify teams** of assigned tasks
# **Configuring an** Action Item **Workflow**[](#9BnZw)
## Getting Started[](#mq2a7)
Follow the navigation below to begin configuring an action item workflow.
**Workflows** > **Create Workflow** > **Action Item**
## Set Trigger Event[](#4fJr9)
There are many trigger events to choose from. Check out what's available to you on [this page](/workflows/workflow-types).
In the example below, the workflow will initiate when a new action item is created for an incident.
## Set Run Conditions[](#RT_nK)
Since action items are tied to individual incidents, action item workflows can be configured to **check for both action item** and **incident properties**.
There are four action item conditions available.
### Type[](#F6ECv)
The type represents the type of action item. It can be either a task or follow up.
In the example above, the type condition will pass if the action item is a task or a follow-up.
### Status[](#9utEW)
The status represents the status of the action item. It can be Open, In Progress, Done, or Cancelled.
## Set Actions[](#LpNwF)
Available actions in action item workflows are dependent on the integrated applications. Actions relating to specific applications will become available once those applications are integrated.
In the example below, the workflow will create a Jira subtask in the integrated Jira instance.
# Alert Workflows
Source: https://docs.rootly.com/workflows/alert-workflows
Configure workflows triggered by incoming alerts to auto-declare incidents, update Jira tickets, and notify teams based on alert conditions.
# **Overview**
Alert workflows are triggered on changes to the alerts data. The Rootly platform is capable of receiving incoming events, known as alerts. These alerts are streamed in from a number of integrations (e.g. Jira, PagerDuty, Datadog, Grafana, etc.). You can leverage the power of workflows to auto declare incidents, send Slack notifications, etc. from these alerts.
Alert workflows are particularly useful for...
* **Auto declaring incidents** based on an incoming alert
* **Updating an incident or action item** based on changes to a corresponding Jira ticket
* **Alerting common team channels** (e.g. #alerts, #sre, #security) of critical events
# **Configuring an Alert Workflow**
## Ensure Alerts are Flowing In
In order to use an alert workflow, you must first ensure that you have alerts flowing into Rootly. See the [Alerts](/alerts) page to learn more.
## Getting Started
Follow the navigation below to begin configuring an alert workflow.
**Workflows** > **Create Workflow** > **Alert**
## Set Trigger Event
There are now two trigger events available for alert workflows in Rootly. You can choose either **Alert Created** or **Alert Status Updated** depending on when you want your workflow to run.
To set your trigger:
1. Go to the **Triggers** section.
2. Click the field under “Choose the events that will trigger this workflow."
3. Select either **Alert Created** or **Alert Status Updated** from the dropdown.
You can select one or both depending on your workflow’s needs.
The **Alert Created** trigger starts the workflow as soon as a new alert is received in your Rootly organization.
The **Alert Status Updated** trigger starts the workflow whenever an existing alert’s status changes, for example when it moves from *Open* to *Resolved*.
## Set Run Conditions
Alert workflows have three properties that you condition off of.
### Source
The source represents where the alert originated from.
In the example above, the source condition will only pass if the alert came from PagerDuty.
You can find the source of an alert on the main [Alerts page](https://rootly.com/account/alerts).
### Label
Each alert comes with a series of labels. The labels differ depending on the source (e.g an alert from Jira will have a different set of labels from an alert from Datadog). Alert labels are stored as an **array of values**.
In the example above, the label condition will only pass if the alert contains both the service\_id:PLVWMVW **AND** action:incident.triggered labels.
You can find the labels for each alert on the alert details page. **Alerts** > **select a specific alert**.
### Payload
Each alert comes with a payload. The payload also differs depending on the source. Alert payload is stored as a **JSON structure**. [JSONPath syntax](https://jsonpath.com/) can be used to filter for a specific value within the payload. [Ruby regular expression](https://rubular.com/) (regexp) can be used to match the value filtered via JSONPath.
In the example above, the payload condition will only pass if the type field (within the data object in the payload) equals to incident, irregardless of the case (e.g. Incident is okay, INCIDENT is also okay, InCiDeNt is okay as well).
As with the label, you can also find the payload for each alert on the alert details page. **Alerts** > **select a specific alert**.
## Set Actions
Unlike other types of workflows, the available actions in alert workflows are fixed and not dependent on the integrated applications.
In the example below, the workflow will declare an incident in Rootly.
## Set Trigger Event[](#k2309)
There are many trigger events to choose from. Check out what's available to you on [this page](/workflows/workflow-types).
In the example below, the workflow will initiate when the incident status changes or when a manual command is given in Slack.
## Set Run Conditions[](#TN1vR)
Any property of an incident can be used to condition incident workflows off of. The properties can be **default properties** such as services, severity, status, etc. or **custom properties** configured in [custom fields](https://rootly.com/account/forms?tab=fields "custom fields").
See the [Condition Checks](/workflows/workflows) section for details on how run conditions are configured and enforced.
## Set Actions[](#g96gc)
Available actions in incident workflows are dependent on the [integrated applications](https://rootly.com/account/integrations "integrated applications"). Actions relating to specific applications will become available once those applications are integrated.
In the example below, the workflow will create a Jira issue in the integrated Jira instance.
# Manually Running Workflows
Source: https://docs.rootly.com/workflows/manually-running-workflows
Learn how to trigger workflows manually through Slack commands, modals, and the web interface for on-demand automation.
# Overview[](#y1gQ0)
The most common way to run a workflow is automatically via trigger events. However, all workflows can also be triggered manually through Slack and web UI.
# Via Slack[](#evyMu)
There are 2 ways to manually trigger a workflow in Slack.
## Slack Command[](#bsjeB)
Each workflow can be run in Slack through a custom command. Simply key in the following command in an incident channel:
**/rootly workflow custom-command**
The custom command can be set for each workflow in the Slack Command field.
Ensure that you have the Slack Command as a trigger event as well.
## Slack Modal[](#2rr3S)
You can also run a workflow in Slack through our built-in modal.
# Via Web UI[](#bq8na)
Each workflow can also be run through the web UI.
First, you'll need to navigate into a specific incident and select the View Workflow Runs button on the right-hand pane.
That will prompt you with a list of workflows that have already run for the particular incident. You'll want to select the Trigger Workflow button.
You'll be presented with a list of workflows to select from. Selecting the Trigger Workflow button will trigger the workflow for the specific incident in reference.
# Pulse Workflows
Source: https://docs.rootly.com/workflows/pulse-workflows
Set up workflows triggered by code change events to auto pre-declare incidents and track deployments from Git repositories.
# **Overview**[](#0Y-3K)
Pulse workflows are triggered on changes to the pulses data. The Rootly platform is capable of receiving incoming code change events, known as pulses. These pulses are streamed in from a number of integrations (e.g. Github, Gitlab, etc.). You can leverage the power of workflows to auto pre-declare incidents, send Slack notifications, etc. from these pulses.
Pulse workflows are particularly useful for...
* **Auto pre-declaring incidents** to prepare for potential outages caused by new code changes
* **Tracking code deployments** in common team channels (e.g. #deployments, #infrastructure, #product)
# **Configuring an Pulse Workflow**[](#TpnOW)
## Ensure Pulse are Flowing In[](#M35Zr)
In order to use a pulse workflow, you must first ensure that you have pulses flowing into Rootly. See the [Pulses](/configuration/pulses) page to learn more.
## Getting Started[](#vg2Q8)
Follow the navigation below to begin configuring a pulse workflow.
**Workflows** > **Create Workflow** > **Pulse**
## Set Trigger Event[](#oyiY9)
There is only one trigger event available for pulse workflows. Select the Pulse Created option as the trigger event. This will cause the workflow to initiate as soon as a pulse is received in your Rootly organization.
## Set Run Conditions[](#TvRTR)
Pulse workflows have three properties that you condition off of.
### Source[](#2ADgL)
The source represents where the pulse originated from.
In the example above, the source condition will only pass if the pulse came from Github.
You can find the source of a pulse on the main [Pulses page](https://rootly.com/account/pulses "Pulses page").
### Label[](#mdcvC)
Each pulse comes with a series of labels. The labels differ depending on the source (e.g an pulse from Github will have a different set of labels from a pulse from Gitlab). Pulse labels are stored as an **array of values**.
In the example above, the label condition will only pass if the pulse contains both the ref:refs/heads/master **AND** action:push labels.
You can find the labels for each pulse on the pulse details page. **Configuration** > **Pulses** > **select a specific pulse**.
### Payload[](#m7Uz3)
Each pulse comes with a payload. The payload also differs depending on the source. Pulse payload is stored as a **JSON structure**. [JSONPath syntax](https://jsonpath.com/ "JSONPath syntax") can be used to filter for a specific value within the payload. [Ruby regular expression](https://rubular.com/ "Ruby regular expression") (regexp) can be used to match the value filtered via JSONPath.
In the example above, the payload condition will only pass if the id field (within the organization object in the payload) equals 12345678.
As with the label, you can also find the payload for each pulse on the pulse details page. **Configuration** > **Pulses** > **select a specific pulse**.
## Set Actions[](#2MQD7)
Unlike other types of workflows, the available actions in pulse workflows are fixed and not dependent on the integrated applications.
In the example below, the workflow will declare an incident in Rootly.
# Retrospective Workflows
Source: https://docs.rootly.com/workflows/retrospective-workflows
Automate retrospective processes by creating workflows that update documents, publish completed reviews, and notify leadership of incident learnings.
# **Overview**[](#4sQyZ)
Retrospective workflows are triggered on changes to the retrospective data. Every incident created on the Rootly platform also contains a retrospective object. You can leverage the power of workflows to auto update retrospective, publish retrospectives, etc.
Retrospective workflows are particularly useful for...
* **Auto updating draft retrospective** documents
* **Auto publish completed retrospective** documents
* **Notify leadership** of published retrospectives
# **Configuring a Retrospective Workflow**[](#UVFdW)
## Getting Started[](#s6fxx)
Follow the navigation below to begin configuring a retrospective workflow.
**Workflows** > **Create Workflow** > **Retrospective**
## Set Trigger Event[](#hAOEu)
There are many trigger events to choose from. Check out what's available to you on [this page](/workflows/workflow-types).
In the example below, the workflow will initiate when the retrospective status changes.
## Set Run Conditions[](#1IpUX)
Since retrospectives are tied to individual incidents, retrospective workflows can be configured to **check for both retrospective** and **incident properties**.
There are two retrospective conditions available.
### Status[](#BUmXc)
The status represents the status of the retrospective. It can be either draft or published.
## Set Actions[](#PjPro)
Available actions in retrospective workflows are dependent on the [integrated applications](https://rootly.com/account/integrations "integrated applications"). Actions relating to specific applications will become available once those applications are integrated.
In the example below, the workflow will send a Slack message in the integrated Slack workspace.
# Standalone Workflows
Source: https://docs.rootly.com/workflows/standalone-workflows
Create manual Slack command-triggered workflows for ad-hoc tasks like emailing dashboards, making calls, and fetching repository data.
# **Overview**[](#LRCtw)
Standalone workflows are triggered strictly on Slack command.
Standalone workflows are particularly useful for...
* **Emailing metrics dashboards** on a periodic schedule
* **Make ad-hoc phone calls** during an incident
* **Fetching ad-hoc Github commits** for an incident
# **Configuring a Standalone Workflow**[](#_h22W)
## Getting Started[](#NAkjO)
Follow the navigation below to begin configuring a standalone workflow.
**Workflows** > **Create Workflow** > **Standalone**
## Set Trigger Event[](#Et8Sr)
Standalone workflows can only be triggered via Slack command.
## Set Run Conditions[](#tDQJj)
There are **no run conditions for standalone workflows**, since it's intended to be triggered manually whenever the user sees a need to. Enforcing run conditions would be counterproductive.
## Set Actions[](#Y0N0h)
Available actions in standalone workflows are dependent on the [integrated applications](https://rootly.com/account/integrations "integrated applications"). Actions relating to specific applications will become available once those applications are integrated.
In the example below, the workflow will email a dashboard report to a specified set of recipients.
# Workflow Types
Source: https://docs.rootly.com/workflows/workflow-types
Understand the six workflow types (incident, retrospective, action item, alert, pulse, standalone) and their specific trigger events for automation.
# Overview[](#emAQ9)
Rootly currently supports **six different types of workflows**:
* Incident
* Retrospective
* Action Item
* Alert
* Pulse
* Standalone
The difference between these workflows is how they are triggered. For example, an incident workflow will only be triggered by changes to an incident (e.g. change in incident status, change in incident severity). While an action item workflow will only be triggered by changes to an action item (e.g. change in action item status, change in action item due date).
Standalone workflows are unique in that they aren't triggered by a particular Rootly object. Instead, they can only be triggered by a custom Slack command.
Workflows play a key part in the overall Rootly experience. They allow teams to automate manual actions based on a series of trigger events and run conditions. There are endless possibilities designed to fit your exact use cases. Some common automations are:
* Automatically **spin up a Slack channel** when new incident is declared
* Automatically **remind Slack channel** to update status page every 30 minutes
* Automatically **email** legal team whenever a SEV0 incident occurs
* Automatically **create Jira tickets** on the corresponding project boards based on the impacted teams
* Automatically spin up **Zoom or Google Meet** bridges for high severity incidents to enable high bandwidth conversations
* Automatically page the **on-call responders via PagerDuty or Opsgenie** whenever a certain service is down
* Automatically **create retrospectives** using different templates depending on the types of incidents
* ...thousands of other combinations to fit your exact incident process!
If you need help configuring a Workflow or don't see what you're looking for, reach out via Slack or [support@rootly.com](mailto:support@rootly.com).
# Workflows at Glance[](#SjnOl)
| **No.** | **Description** |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1) Name** | Give your workflow a name for easy identification. If you do not set a Slack Command (in field 5) for the workflow during initial creation, Rootly will hyphenate the Name field as the default command value. |
| **2) Description** | Add a detailed description to inform users what the workflow does. |
| **3) Workflow Folder** | Place the workflow in a specified folder. If a workflow is not in any folder, you will be able to find the workflow by filtering for All Workflow on the workflows page. |
| **4) Enabled** | When a workflow is disabled, it will not automatically run when trigger conditions are met. Disabled workflows can still be triggered by manual Slack command. |
| **5) Slack Command** | Every workflow can be triggered via Slack command. Choose an easy-to-remember command if your process calls for a workflow to be triggered in this fashion. If you do not set a value here, Rootly will hyphenate the Name field as the default command value. |
| **6) Command Feedback Enabled** | Selecting this field will result in a message output in Slack every time the workflow is run via manual Slack command. |
| **7) Repeat Every** | Each workflow can be run on a recurring schedule. This field must be used alongside the Repeat On field. The value set in this field indicates how often the workflow is initiated (e.g. 30min, 2h 30min, 1 day).
The workflow will initiate...
* when the status of the incident is updated,
* **OR** when the severity of the incident is updated,
* **OR** when the team of the incident is updated
## Phase 2: Condition Check[](#Mj-Fu)
Once a workflow is initiated, it must pass conditions before any action takes place. Conditions are dependent on the Workflow Type: Incident workflows will check for conditions on incident properties. While action item workflows will check for conditions on action item properties.
**Run conditions can be joined by the following operators:**
* `all of` - every condition must be true
* `any of` - if any condition is true
* `none of` - if every condition is false
The workflow will run if...
* Incident Kind is Incident,
* **AND** incident Status is Resolved **OR** Cancelled,
* **AND** incident Severity is SEV0 **OR** SEV1,
* **AND** incident **Team** is **anything but** Test
## Phase 3: Execution[](#j1Pqf)
Once a workflow has successfully met its run conditions, its configured actions will officially start. The available actions are dependent on the [Workflow Type](/workflows/workflow-types "Workflow Type") and [integrated applications](https://rootly.com/account/integrations "integrated applications").
A single workflow can have multiple actions. The **order in which the actions are placed will dictate the run order of actions**.
Each action can be **independently disabled**.
By default, **when a single action fails within a workflow, the entire workflow will be halted**. This behavior can be changed by turning on the Skip on Failure flag. This will result in the **workflow continuing, even if the action fails**.
For example if the following actions are configured for a workflow:
The workflow will attempt to...
1. **Send a Slack message**
2. Regardless of the result of step 1, **send an email**
3. IF the email fails to send, the workflow ENDs
4. IF the email successfully sends, the workflow continues to step 5
5. Skips adding a message to the incident timeline
6. **Adds an action item**
7. IF the action item is successfully added, workflow marked as SUCCESS
8. IF the action item fails to be added, workflow marked as FAILED
# Organizing Workflows[](#fSmOY)
Workflows will be the backbone of your automations. It is important to keep them organized, so it's easy to locate and manage. On the workflows page, you'll see the following sections:
| **No.** | **Description** |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1) All Workflows** | You can quickly view all of the workflows in your organization. |
| **2) Folders** | You can create folders to place your workflows in. Workflows are not impacted by which folder they are placed in. This is purely used for organization purposes. |
| **3) Enabled / Disabled** | This is an easy way to enable/disable each workflow. You don't have to click into the edit page for each workflow to do so. |
| **4) Expand / Collapse** | Expanding the tile will show a summary of the workflow - giving you a quick way to view them without having to click into each workflow. |
| **5) Workflow Summary** | It's not always easy to recognize what a workflow is configured to do purely based on its name. When expanded, you'll be able to see a summary of the workflow containing its trigger events, run conditions, and actions. |
| **6) Filter & Sort** | To quickly locate workflows, you can filter and sort workflows. |
# Create alert event
Source: https://docs.rootly.com/api-reference/alertevents/create-alert-event
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alerts/{alert_id}/events
Creates a new alert event
# Delete alert event
Source: https://docs.rootly.com/api-reference/alertevents/delete-alert-event
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json delete /v1/alert_events/{id}
Deletes a specific alert event. Only alert events with kind 'note' (user-created notes) can be deleted. System-generated events are immutable to maintain audit trail integrity.
# List alert events
Source: https://docs.rootly.com/api-reference/alertevents/list-alert-events
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alerts/{alert_id}/events
List alert_events
# Retrieve alert event
Source: https://docs.rootly.com/api-reference/alertevents/retrieve-alert-event
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_events/{id}
Retrieves a specific alert_event by id
# Update alert event
Source: https://docs.rootly.com/api-reference/alertevents/update-alert-event
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json patch /v1/alert_events/{id}
Updates a specific alert event. Only alert events with kind 'note' (user-created notes) can be updated. System-generated events are immutable to maintain audit trail integrity.
# Creates an alert field
Source: https://docs.rootly.com/api-reference/alertfields/creates-an-alert-field
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alert_fields
Creates a new alert field from provided data
# Delete an alert field
Source: https://docs.rootly.com/api-reference/alertfields/delete-an-alert-field
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json delete /v1/alert_fields/{id}
Delete a specific alert field by id
# List alert fields
Source: https://docs.rootly.com/api-reference/alertfields/list-alert-fields
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_fields
List alert fields
# Retrieves an alert field
Source: https://docs.rootly.com/api-reference/alertfields/retrieves-an-alert-field
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_fields/{id}
Retrieves a specific alert field by id
# Update an alert field
Source: https://docs.rootly.com/api-reference/alertfields/update-an-alert-field
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json put /v1/alert_fields/{id}
Update a specific alert field by id
# Creates an alert group
Source: https://docs.rootly.com/api-reference/alertgroups/creates-an-alert-group
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alert_groups
Creates a new alert group
# Delete an alert group
Source: https://docs.rootly.com/api-reference/alertgroups/delete-an-alert-group
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json delete /v1/alert_groups/{id}
Delete a specific alert group by id
# List alert groups
Source: https://docs.rootly.com/api-reference/alertgroups/list-alert-groups
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_groups
List alert groups
# Retrieves an alert group
Source: https://docs.rootly.com/api-reference/alertgroups/retrieves-an-alert-group
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_groups/{id}
Retrieves a specific alert group by id
# Update an alert group
Source: https://docs.rootly.com/api-reference/alertgroups/update-an-alert-group
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json patch /v1/alert_groups/{id}
Update a specific alert group by id
# Creates an alert route
Source: https://docs.rootly.com/api-reference/alertroutes/creates-an-alert-route
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alert_routes
Creates a new alert route from provided data. **Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.**
## Asynchronous Rule Creation
For organizations with large numbers of routing rules, Rootly supports asynchronous rule processing to improve performance. When enabled, rule creation happens in the background.
**Important**: When async processing is enabled, the rules list in the API response will not be up-to-date immediately after creation. You should refetch the alert route after a few minutes to get the updated rules.
If you experience slow operations when managing alert routes with many rules, contact Rootly customer support to enable asynchronous rule processing for your organization.
# Delete an alert route
Source: https://docs.rootly.com/api-reference/alertroutes/delete-an-alert-route
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json delete /v1/alert_routes/{id}
Delete a specific alert route by id. **Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.**
# Get an alert route
Source: https://docs.rootly.com/api-reference/alertroutes/get-an-alert-route
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_routes/{id}
Get a specific alert route by id. **Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.**
# List alert routes
Source: https://docs.rootly.com/api-reference/alertroutes/list-alert-routes
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_routes
List all alert routes for the current team with filtering and pagination. **Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.**
# Update an alert route
Source: https://docs.rootly.com/api-reference/alertroutes/update-an-alert-route
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json put /v1/alert_routes/{id}
Update a specific alert route by id. **Note: This endpoint requires access to Advanced Alert Routing. If you're unsure whether you have access to this feature, please contact Rootly customer support.**
## Asynchronous Rule Creation
For organizations with large numbers of routing rules, Rootly supports asynchronous rule processing to improve performance. When enabled, rule updates happen in the background.
**Important**: When async processing is enabled, the rules list in the API response will not be up-to-date immediately after update. You should refetch the alert route after a few minutes to get the updated rules.
If you experience slow operations when managing alert routes with many rules, contact Rootly customer support to enable asynchronous rule processing for your organization.
# Creates an alert routing rule
Source: https://docs.rootly.com/api-reference/alertroutingrules/creates-an-alert-routing-rule
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alert_routing_rules
Creates a new alert routing rule from provided data. **Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.**
# Delete an alert routing rule
Source: https://docs.rootly.com/api-reference/alertroutingrules/delete-an-alert-routing-rule
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json delete /v1/alert_routing_rules/{id}
Delete a specific alert routing rule by id. **Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.**
# List alert routing rules
Source: https://docs.rootly.com/api-reference/alertroutingrules/list-alert-routing-rules
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_routing_rules
List alert routing rules. **Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.**
# Retrieves an alert routing rule
Source: https://docs.rootly.com/api-reference/alertroutingrules/retrieves-an-alert-routing-rule
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_routing_rules/{id}
Retrieves a specific alert routing rule by id. **Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.**
# Update an alert routing rule
Source: https://docs.rootly.com/api-reference/alertroutingrules/update-an-alert-routing-rule
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json put /v1/alert_routing_rules/{id}
Update a specific alert routing rule by id. **Note: If you are an advanced alert routing user, you should use the Alert Routes endpoint instead of this endpoint. If you don't know whether you are an advanced user, please contact Rootly customer support.**
# Acknowledges an alert
Source: https://docs.rootly.com/api-reference/alerts/acknowledges-an-alert
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alerts/{id}/acknowledge
Acknowledges a specific alert by id
# Attach alerts to an incident
Source: https://docs.rootly.com/api-reference/alerts/attach-alerts-to-an-incident
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/incidents/{incident_id}/alerts
Attach alerts to an incident from provided data
# Creates an alert
Source: https://docs.rootly.com/api-reference/alerts/creates-an-alert
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alerts
Creates a new alert from provided data
# List alerts
Source: https://docs.rootly.com/api-reference/alerts/list-alerts
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alerts
List alerts
# List Incident alerts
Source: https://docs.rootly.com/api-reference/alerts/list-incident-alerts
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/incidents/{incident_id}/alerts
List incident alerts
# Resolves an alert
Source: https://docs.rootly.com/api-reference/alerts/resolves-an-alert
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alerts/{id}/resolve
Resolves a specific alert by id
# Retrieves an alert
Source: https://docs.rootly.com/api-reference/alerts/retrieves-an-alert
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alerts/{id}
Retrieves a specific alert by id
# Update alert
Source: https://docs.rootly.com/api-reference/alerts/update-alert
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json patch /v1/alerts/{id}
Updates an alert
# Creates an alert source
Source: https://docs.rootly.com/api-reference/alertsources/creates-an-alert-source
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alert_sources
Creates a new alert source from provided data
# Delete an alert source
Source: https://docs.rootly.com/api-reference/alertsources/delete-an-alert-source
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json delete /v1/alert_sources/{id}
Delete a specific alert source by id
# List alert sources
Source: https://docs.rootly.com/api-reference/alertsources/list-alert-sources
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_sources
List alert sources
# Retrieves an alert source
Source: https://docs.rootly.com/api-reference/alertsources/retrieves-an-alert-source
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_sources/{id}
Retrieves a specific alert source by id
# Update an alert source
Source: https://docs.rootly.com/api-reference/alertsources/update-an-alert-source
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json put /v1/alert_sources/{id}
Update a specific alert source by id
# Creates an alert urgency
Source: https://docs.rootly.com/api-reference/alerturgencies/creates-an-alert-urgency
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json post /v1/alert_urgencies
Creates a new alert urgency from provided data
# Delete an alert urgency
Source: https://docs.rootly.com/api-reference/alerturgencies/delete-an-alert-urgency
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json delete /v1/alert_urgencies/{id}
Delete a specific alert urgency by id
# List alert urgencies
Source: https://docs.rootly.com/api-reference/alerturgencies/list-alert-urgencies
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_urgencies
List alert urgencies
# Retrieves an alert urgency
Source: https://docs.rootly.com/api-reference/alerturgencies/retrieves-an-alert-urgency
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/alert_urgencies/{id}
Retrieves a specific alert urgency by id
# Update an alert urgency
Source: https://docs.rootly.com/api-reference/alerturgencies/update-an-alert-urgency
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json put /v1/alert_urgencies/{id}
Update a specific alert urgency by id
# List audits
Source: https://docs.rootly.com/api-reference/audits/list-audits
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/audits
List audits
# List authorizations
Source: https://docs.rootly.com/api-reference/authorizations/list-authorizations
https://rootly-heroku.s3.amazonaws.com/swagger/v1/swagger.json get /v1/authorizations
List authorizations
# API Changelog
Source: https://docs.rootly.com/api-reference/changelog
Track the latest changes and updates to the Rootly API
## Unreleased
* **fix:** pagination stability across 26 API v1 controllers by adding deterministic sorting tiebreakers (created\_at, id) to prevent duplicate records across pages
* **breaking:** default sort order changed from descending to ascending for 16 endpoints: causes, custom\_fields, environments, form\_fields, form\_field\_placements, form\_field\_placement\_conditions, functionalities, genius\_tasks, genius\_workflows, groups, incident\_roles, incident\_types, services, severities, catalog\_entities, catalog\_fields. Use `sort=-position` to restore previous behavior.
* **fix:** custom\_forms endpoint now defaults to `created_at` sort (previously used non-existent `position` column)
## December 2025
### December 5, 2025
* **feat:** add assignee to shifts include options and deprecate user field
* **feat:** add incident alerts to incident API response
### December 3, 2025
* **feat:** add created\_by field to Incident AI API
## November 2025
### November 26, 2025
* **feat:** add mitigation\_message, resolution\_message, and cancellation\_message to incident update API
### November 7, 2025
* **fix:** remove timestamps from routing rule target serializer
### November 6, 2025
* **feat:** make slack\_channel nullable in schedules API
### November 4, 2025
* **feat:** add slack\_channel field to schedule endpoint
## October 2025
### October 30, 2025
* **feat:** return UUID for custom\_field\_id in workflow custom field selections API
### October 29, 2025
* **feat:** make scheduled\_for and scheduled\_until fields not required, with auto defaults
### October 28, 2025
* **fix:** add rules back to alert routes API schema
* **feat:** support large position values in API
### October 14, 2025
* **feat:** add additional information fields to Users API
* **feat:** add auto\_add\_members\_when\_attached field to Teams API
### October 10, 2025
* **feat:** add project schedules support to schedules API
### October 7, 2025
* **feat:** add schedule rotation serializer with enhanced rotation details
* **fix:** alert sources API schema validation errors
### October 6, 2025
* **fix:** add alert deduplication fields to alert serializer
### October 3, 2025
* **fix:** missing shifts in API response due to duplicate shift IDs by generating deterministic UUIDs
### October 2, 2025
* **fix:** timezone handling in escalation policy business\_hours API
### October 1, 2025
* **feat:** include substatus name with ID for incidents API
* **feat:** update schedule rotations API to support schedule rotation members
* **fix:** shifts API to return all shifts including duplicates by ID
* **fix:** shift start time to respect API query time range
## September 2025
### September 30, 2025
* **feat:** implement SAML authentication API endpoints for status pages
* **feat:** add email-based heartbeat pinging support
* **fix:** postmortem template update from API
### September 26, 2025
* **fix:** correct turn start for hourly rotations crossing DST
### September 25, 2025
* **fix:** schedule members being null in API response
### September 16, 2025
* **feat:** add assignee\_id and assignee\_type to shift serializer
* **perf:** fix N+1 queries in API alerts index endpoint
### September 12, 2025
* **fix:** search filters not working in heartbeats API
### September 11, 2025
* **feat:** add content\_raw field for markdown type post\_mortem\_templates
* **fix:** missing rate limit headers in API responses
### September 10, 2025
* **feat:** add IANA timezone format support to User API serializer
* **fix:** alert acknowledge/resolve endpoints to validate status transitions
### September 9, 2025
* **feat:** add alert\_description field to heartbeats API
### September 6, 2025
* **feat:** add comprehensive API support for SAML authentication configuration
### September 5, 2025
* **fix:** schedule\_rotation\_users API uses shift rendering v2 if enabled
### September 4, 2025
* **feat:** add alert field values to alerts using API
### September 3, 2025
* **fix:** return 400 for ActionDispatch::Http::Parameters::ParseError
## August 2025
### August 27, 2025
* **feat:** added event sourcing for remote MCP source
### August 22, 2025
* **feat:** Alert Routes API endpoints
### August 12, 2025
* **feat:** add non editable form fields option in forms API
### August 7, 2025
* **fix:** undefined reference to current\_user.role in API responses
### August 6, 2025
* **feat:** allow owner/admin to manage UserNotificationRule for team members via API
### August 4, 2025
* **fix:** relax minimum escalation path restriction for Terraform
* **feat:** add alert events to alerts serializer
## July 2025
### July 31, 2025
* **feat:** add custom fields and incident roles as columns in Table metrics panel API
### July 28, 2025
* **feat:** alert deduplication configuration, timeline events, and API endpoints
### July 23, 2025
* **feat:** email verification API endpoints
### July 22, 2025
* **fix:** include destination in alert routing rule API response
* **fix:** rotation start/end timestamps now returned in UTC
* **feat:** add disable auto adding members to incident channel feature in groups API
## June 2025
### June 4, 2025
* **fix:** user\_ids\[] filtering on /v1/shifts endpoint
* **feat:** slug field to status pages API serializer and schema
### June 2, 2025
* **feat:** services API now accepts owner\_group\_ids parameter
* **refactor:** create reusable user response schema
* **fix:** action items schema for assigned\_to field
* **fix:** ensure user contact info is created for correct user
## May 2025
### May 30, 2025
* **fix:** delete prior sourceable when updating attributes from the API
### May 28, 2025
* **feat:** remove verification attributes from email/phone number APIs
* **feat:** remove primary attribute from user email addresses API
* **feat:** add case-insensitive target\_type normalization
### May 27, 2025
* **feat:** add RESTful API endpoints for user phone numbers and email addresses
### May 26, 2025
* **feat:** add API support for advanced conditions in alert grouping
### May 15, 2025
* **feat:** allow automated invite of external emails into Slack incident channels
* **docs:** update API schema
### May 5, 2025
* **feat:** add new escalate targets to public API schemas
## April 2025
### April 30, 2025
* **feat:** ability to filter alerts by status via API
### April 29, 2025
* **feat:** return API timestamps in seconds
### April 21, 2025
* **feat:** allow internal API endpoint to accept a user\_id parameter
### April 18, 2025
* **fix:** API issue with assigning multiple users to role
* **feat:** include initial\_delay in API serializer
### April 15, 2025
* **fix:** allow owner\_group\_ids parameter in API requests
* **perf:** updated pagination method to accept count for large collections
### April 14, 2025
* **perf:** updated API pagination method to avoid extra count call
### April 9, 2025
* **fix:** add missing urgency rules to alert source serializer
### April 8, 2025
* **feat:** add email source settings to disable threaded emails
### April 4, 2025
* **fix:** typo in alert routes API
### April 3, 2025
* **feat:** team and organization API keys
## March 2025
### March 31, 2025
* **refactor:** single paginate method for database queries and search
* **fix:** API key search in audit logs section
### March 28, 2025
* **feat:** support resolution rule in alert source API
### March 26, 2025
* **refactor:** consistent pagination for search and database queries
* **fix:** specify required fields in routing rule schema
* **fix:** change routing rule schema to conform to OpenAPI standards
* **fix:** prevent crash from invalid SQL queries
* **fix:** allow creating alert events with Rootly bot as user
### March 25, 2025
* **feat:** create/update/delete alert "note" events
* **feat:** specify whether field can be computed in API schema
### March 21, 2025
* **refactor:** updated alert params filtering for API controller
### March 20, 2025
* **fix:** alert routing API issues
### March 17, 2025
* **feat:** add API support for alert routes
* **docs:** fix incorrect paging strategy options
* **fix:** create cached Slack channel if necessary
* **feat:** filter schedules and escalation policies by name
* **fix:** validate and hydrate Slack channel targets
* **fix:** return 422 for invalid record exceptions
* **fix:** prevent duplicate active\_times when updating rotation
### March 14, 2025
* **feat:** add business hours support to escalation policy API
* **fix:** schedule rotation update should return errors
* **fix:** respect requested escalation level position (breaking change)
* **fix:** replace urgency rules when updating source (breaking change)
* **fix:** do not prevent deletion of schedule rotations (breaking change)
* **fix:** prevent duplicate schedule rotation active times
### March 13, 2025
* **fix:** support for escalation level paging strategy
### March 11, 2025
* **feat:** expose sub-status configuration on teams API
## February 2025
### February 26, 2025
* **fix:** API alert sources webhooks endpoint URL
### February 25, 2025
* **fix:** alert sources tags and operationId API schema
* **feat:** add API support to mark alerts as noise
### February 17, 2025
* **feat:** track last updated user for schedule rotations
* **feat:** track last updated user for schedule rotation users
### February 12, 2025
* **feat:** API support for new escalation policy target type "team"
## January 2025
### January 31, 2025
* **docs:** add note about admin\_ids to groups API schema
### January 30, 2025
* **feat:** API support for group admin\_ids
### January 17, 2025
* **fix:** schedules slack\_user\_group API schema
### January 10, 2025
* **feat:** API support for alert source urgency id and alert template
### January 7, 2025
* **feat:** API support for email alert creation
## December 2024
### December 13, 2024
* **refactor:** update escalation policy levels controller
### December 2, 2024
* **fix:** handle undocumented PagerDuty API schema
## October 2024
### October 23, 2024
* **feat:** on-call shift calendar subscription
### October 16, 2024
* **docs:** improve API documentation
### October 14, 2024
* **feat:** handle "mitigated" status for workflow tasks when sub-status enabled
* **feat:** add "Update Incident Status Timestamp" task to API schema
### October 10, 2024
* **feat:** allow sub\_status\_id for /v1/incidents/:id endpoint
### October 1, 2024
* **feat:** add missing API schema attribute for Terraform compatibility
### September 25, 2024
* **feat:** API support for sub-statuses
### September 16, 2024
* **feat:** expose alert urgency to POST api.rootly.com/v1/alerts
### September 10, 2024
* **feat:** add alert notification target on alert updates
### September 4, 2024
* **feat:** add API support for alert groups
### August 30, 2024
* **feat:** add API support for alert urgency
### August 29, 2024
* **feat:** add schedule rotation attributes to OpenAPI schema for Terraform compatibility
* **feat:** add escalation policy path API support
### August 26, 2024
* **docs:** fix /v1/incidents/{incident_id}/alerts documentation
### July 19, 2024
* **fix:** escalation policy OpenAPI schema and add service\_ids, group\_ids
### July 2, 2024
* **fix:** /api/v1/dashboards/:id returning 404 when shared publicly
***
# Overview
Source: https://docs.rootly.com/api-reference/overview
API Authentication and Request Examples
## **Customize**
Customize the default content and look-and-feel of your status page in the Customize tab. As you make changes to the settings in this tab, the right-hand preview of your status page will reflect your latest updates.
## **Components**
Use the Components section to add Services to your status page. You're able to add any Rootly Service, as well as any third party service your organization uses.
Anytime a selected Service is involved in an incident, it will be reflected on the status page under the 'System Status' section.
**Note**: You'll be able to add third party services to your status page after you've created the status page.
## **Templates**
Standardize the incident updates your teams share with Status Templates. When a commander publishes an incident update to a status page, they'll be able to use the templates defined in this section to help write their update.
# Custom Domain Names For Status Pages
Source: https://docs.rootly.com/configuration/custom-domain-names-for-status-pages
Configure custom domain names for your public status pages to maintain brand consistency and provide a seamless customer experience.
## Overview
You can attach one or multiple custom domain names such as status.acme.me using the custom domain names input. This allows you to brand your status page with your own domain while maintaining all the functionality of Rootly's status page system.
The CNAME can be found at the bottom of the screen on the right side, as shown here:
It provides the **Domain** you entered along with the **Value** needed for your DNS records.
## How Custom Domains Work
1. You set up the CNAME record in your DNS provider with:
* **Domain**: test.statuspage.net
* **Value**: (rootly-provided-value).external-sp.rootly.com
2. When someone visits test.statuspage.net:
* The DNS system looks up the CNAME record and directs the request to (rootly-provided-value).external-sp.rootly.com.
3. Rootly serves the corresponding status page associated with the unique identifier in the CNAME.
## DNS Configuration Steps
### Step 1: Configure CNAME Record
Set up the CNAME record in your DNS provider with the values obtained from Rootly:
* **Domain**: Your custom domain (e.g., status.your-domain.com)
* **Value**: The Rootly-provided CNAME target (e.g., unique-id.external-sp.rootly.com)
### Step 2: Add CAA Record (Required)
You must add a CAA (Certificate Authority Authorization) record to your DNS configuration for SSL certificate validation to work properly:
1. Add a CAA record to your **parent domain** (not the subdomain) with the following format:
```
0 issue "pki.goog; cansignhttpexchanges=yes"
```
For example, if your custom domain is `status.your-domain.com`, add the CAA record to `your-domain.com`.
If your Rootly instance requires incidents to progress through Active or Resolved in order, your responders will only be able to update the incident's status to the next status defined in your Lifecycle configuration.
**Note:** Responders are able to move an incident backward to any previous status. If they do so, they'll have to progress the incident through each status again.
Get started with Custom Statuses by reaching out to your Rootly account representative today.
# Event Payloads
Source: https://docs.rootly.com/configuration/event-payloads
Reference documentation for webhook event payload structures used in Rootly integrations and custom automations.
## alert.\*
```json JSON theme={null}
{
"event": {
"id": "9839c4ca-5e7b-416d-ad95-d09ae0c8eead",
"type": "alert.created",
"issued_at": "2022-11-27T19:15:29.546-08:00",
},
"data": {
"id": "13c82722-ec52-4eda-aaa2-771f7c81c01c",
"team_id": 1,
"source": "pagerduty",
"summary": "database-prod-002 Memory threshold over 85%",
"labels": [],
"data": {
"hello": "world"
},
"external_id": "Q1IC19Z6U7MIQB",
"external_url": "https://rootly.pagerduty.com/alerts/Q1IC19Z6U7MIQB",
"webhook_type": null,
"webhook_id": null,
"webhook_idempotency_key": null,
"started_at": "2022-11-27T19:15:29.546-08:00",
"ended_at": null,
"deleted_at": null,
"created_at": "2022-11-27T19:15:29.546-08:00",
"updated_at": "2022-11-27T19:15:29.546-08:00"
}
}
```
## genius\_workflow\_run.\*
Let's say this was a security related incident. Once I append "Security" to the types field that would then automatically attach the related playbooks that were associated with the "Security" types.
As you can see below the action items has increased from 3 to 6 as we have appended the Security type related action items. Clicking the Action Items button gives us a full list of all the item actions.
You can also modify incidents in the Rootly UI as well by navigating to the Incidents tab and clicking edit on the appropriate incident. Modifying incidents in the UI will also automatically attach any relevant playbooks associated with the changes.
# Functionalities
Source: https://docs.rootly.com/configuration/functionalities
Configure functionality categories to identify which product features are impacted by incidents and determine appropriate response teams and communication strategies.
## Overview
**Functionalities** allow you to specify the impacted features during an incident. This can help you identify which responders to bring in, which on-call to page, which customers to inform, etc. Individual functionalities can be mapped to your status pages.
## Field Type
**Functionalities** can be customized to be either a **select** or **multi-select** field type. This means you can configure it to allow only one functionality value to be selected per incident or allow multiple functionality values to be selected per incident.
## Attributes
**Functionalities** can be configured with the following attributes. Each functionality attribute can be referenced via Liquid syntax.
Ready to configure GitHub integration ? [https://docs.rootly.com/integrations/github](/integrations/github)
# Gitlab
Source: https://docs.rootly.com/configuration/gitlab
Configure GitLab integration to automatically track repository pushes and merge requests as contextual pulses for enhanced incident analysis.
Rootly will **automatically** add the following Gitlab events as pulses:
* Push to any repositories
* Merged pull requests
* More to come...
Ready to configure Gitlab integration ? [https://docs.rootly.com/integrations/gitlab](/integrations/gitlab)
# Heroku
Source: https://docs.rootly.com/configuration/heroku
Configure Heroku integration to automatically capture build events and release deployments as contextual pulses for incident correlation.
Heroku will **automatically** add the following Heroku events as pulses:
* A build starts
* A build ends ( Failed or succeeded )
* A release is deployed
* More to come...
Ready to configure Heroku integration ? [https://docs.rootly.com/integrations/heroku](/integrations/heroku)
# Incident Causes
Source: https://docs.rootly.com/configuration/incident-causes
Define and track root causes of incidents to identify patterns, prioritize improvements, and guide post-incident learning initiatives.
## Overview
**Incident causes** allow you to track the root cause of incidents. This is particularly helpful when identifying trends, allowing you to prioritize areas for post-incident improvement.
## Field Type
**Incident causes** is strictly a **multi-select** field type. This means you'll be able to select multiple cause values for a single incident.
## Attributes
**Incident causes** can be configured with the following attributes. Each cause attribute can be referenced via Liquid syntax.
Ready to configure Kubernetes integration ? [https://docs.rootly.com/integrations/kubernetes](/integrations/kubernetes)
# Overview
Source: https://docs.rootly.com/configuration/playbooks
Create and manage response playbooks that automatically attach to incidents based on conditions like severity, service, or team to guide resolution efforts.
## Overview
Playbooks are a great way to create a document that can help speed incident resolution. We can see them as a collection of simple instructions to empower someone to resolve a particular incident (even if they have minimal experience).
Playbooks are **automatically attached** to incidents when they **match a configured condition** (for example: severity, service, functionality, team impacted ). You can see these fields in the screenshot below. If you have Playbooks or supported documentation hosted internally, you can link to them in the "External URL" field and provide detailed instructions in the content field.
On the above example, the **Database outage playbook** will be attached to any incident with the **SEV2 severity or the** **customers-postgresql-db** **microservices.** Please note that this is all OR logic currently, meaning this playbook will be attached to an incident that has just one of those matching condition, such as SEV2 severity for example.
Additionally, at the bottom of the Playbook details page you have the ability to append any relevant tasking that needs to be done during the incident.
Playbooks are a great way to prevent a single person from becoming the de facto expert on how to resolve a particular problem. We don't want one person on the team to be the only one to know how to bring a critical system back online.
# Public And Private Status Pages
Source: https://docs.rootly.com/configuration/public-and-private-status-pages
Configure public status pages for customer communication and private status pages for internal team updates during incidents and maintenance.
Rootly has two types of status pages available: public status pages and private status pages. Both can be used to communicate relevant information about ongoing or past incidents and the status of incidents and services.
By default, you will have a public and private status page to customize and configure. You can add additional pages from the Status Page section in Rootly.
A dialog will be presented for you to choose the appropriate status pages where you want the incident published.
This will also be your chance to add a useful title and description your external users can better understand. Add the appropriate information in the title and event fields.
Select a status for the incident, and then click **Publish**.
# Publishing Incidents via Web UI
Source: https://docs.rootly.com/configuration/publishing-incidents-via-web-ui
Manually review and publish incident updates to status pages through Rootly's web interface to ensure accurate customer communication.
Incidents associated with services or functionalities attached to your status pages are not automatically published. Your incident teams need to craft and publish an update of the incident to your status page. This ensures that your teams are reviewing the update and ensuring all relevant information is included in the update.
## **Publishing incidents**
To publish an incident on a status page in Rootly's Web UI:
1. On the incident's details page, navigate to the **Status Page** tab.
2. Click 'Publish Incident', and fill out the form to write your incident update.
3. Use any templates provided to help craft and standardize your message.
4. Once you've provided all the details, the incident will be published to the status page.
Any Service attached to the incident that is also a component of that status page will be automatically updated to show that it is currently **Affected** by an incident. Once the status page is updated to indicate that the incident is resolved, the service will be updated to **Operational**.
## **Updating incidents**
As your incident progresses, you'll need to continually communicate progress to your customers and stakeholders via the status page. You can do so from the same tab in your incident's detail page.
1. Click 'Add to status page' and fill out the necessary information.
2. Rootly will pre-fill the title based on the previous update that was published to the status page.
## **Resolving incidents**
Once your incident has been resolved, publish your final update to the status page using the same flow above. Make sure to update the status in this form to 'Resolved' so that your stakeholders know the issue has been resolved, and all impacted services will return to operational.
# Overview
Source: https://docs.rootly.com/configuration/pulses
Configure and manage pulses to track service changes like deployments, builds, and configuration updates that provide critical context during incident response.
## Overview[](#jBD-a)
Pulses represent service changes such as deploys, build completion, configuration updates, etc., providing contextual information that is critical during incident triage or hypercare.
They can be sent via specific integrations or our cli, and they do not create alerts, incidents or notifications.
## API[](#Gopxz)
You can create pulses through our API directly with curl for example:
```bash Linux theme={null}
curl --header "Content-Type: application/json" \
-H "Authorization: Bearer 
# Adding Services in Rootly
To add a new Service via the Rootly Web UI, navigate to **Configuration > Services** then click **New Service**.
Assign your new Service with a description Title and Description to help the rest of your team know what the Service represents.
# Editing Services
Services are made up of a number of properties. Each property can be referenced via Liquid syntax and can be set in the Rootly Web UI, [API](https://docs.rootly.com/api-reference/services/list-services), or [imported from Opsgenie and PagerDuty](https://docs.rootly.com/configuration/services#import-services). This section outlines how to edit the Services in the Rootly Web UI.
## Basics
Configure the basic details of your Service here.
# Services in Fields
*Service* can be customized to be either a **select** or **multi-select** field type. This means you can configure it to allow only one service value to be selected per incident or allow multiple service values to be selected for a single incident.
It only takes about a minute to setup a status page, so we encourage you to do this soon after you've [signed up](/quick-start-guide).
# Overview
Source: https://docs.rootly.com/configuration/webhooks
Configure webhooks to receive real-time event notifications from Rootly for incidents, alerts, and other system events in external applications.
## Payload[](#ZdBIW)
Each event payload is a JSON object with properties event and data objects. The event object holds the event, and the data property holds a representation of the resource at the time the event was issued.
## Supported Events[](#Kdzlw)
[Event Payloads](/configuration/event-payloads)
```
incident.created
incident.updated
incident.mitigated
incident.resolved
incident.cancelled
incident.deleted
incident.scheduled.created
incident.scheduled.updated
incident.scheduled.in_progress
incident.scheduled.completed
incident.scheduled.deleted
incident_post_mortem.created
incident_post_mortem.updated
incident_post_mortem.published
incident_post_mortem.deleted
alert.created
pulse.created
```
## Verifying Webhooks[](#QlKAI)
Each webhook HTTP request includes a `X-Rootly-Signature` header, used to verify the request came from Rootly. The signature header contains a timestamp prefixed with t= and a signature prefixed with v= .
```txt Text theme={null}
X-Rootly-Signature:
t=1492774588,
v1=6657a869e8ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd
```
To verify the request, concatenate the timestamp with the request body and generate a SHA256 HMAC digest using the webhook secret available in the webhook configuration. The HMAC digest should match the provided signature.
```ruby Ruby theme={null}
require 'openssl'
# Assuming 'request' is an object representing the incoming HTTP request
header = request.headers['X-Rootly-Signature']
parts = header.split(',')
timestamp = parts[0].split('t=').last
signature = parts[1].split('v1=').last
secret = 'webhook secret'
# Reading the request body
request_body = request.body
# Create a signature using HMAC SHA256
expected_signature = OpenSSL::HMAC.hexdigest('SHA256', secret, timestamp + request_body)
# Compare the computed signature with the received signature
is_valid = expected_signature == signature
```
```py Python theme={null}
import hmac
import hashlib
header = request.headers['X-Rootly-Signature']
parts = header.split(',')
timestamp = parts[0].split('t=')[1]
signature = parts[1].split('v1=')[1]
secret = "webhook secret"
# Reading the request body
request_body = request.data # or request.body depending on the framework
# Create a signature using HMAC SHA256
expected_signature = hmac.new(
key=secret.encode(),
msg=(timestamp + request_body).encode(),
digestmod=hashlib.sha256
).hexdigest()
# Compare the computed signature with the received signature
is_valid = expected_signature == signature
```
```js JS theme={null}
const crypto = require('crypto');
// Assuming 'request' is an object representing the incoming request
const header = request.headers['x-rootly-signature'];
const parts = header.split(',');
const timestamp = parts[0].split('t=')[1];
const signature = parts[1].split('v1=')[1];
const secret = "webhook secret";
// Reading the request body
// Ensure that the request body is raw or a string
const request_body = request.body;
// Create a HMAC SHA256 signature
const expectedSignature = crypto.createHmac('sha256', secret)
.update(timestamp + request_body)
.digest('hex');
// Compare the computed signature with the received signature
const isValid = expectedSignature === signature;
```
# Contacting Support
Source: https://docs.rootly.com/contacting-support
Find all the ways to get help with Rootly, including email support, Slack commands, chat options, and demo booking.
Do you have a question, a feature request, or a concern? We’re here to help!
You can reach us via email at [support@rootly.com](mailto:support@rootly.com), with the slash command **/rootly support** in Slack, or visit [Getting Help](https://rootly.com/help) to start a chat.
Check our [Status Page](https://status.rootly.com/) for platform status and ongoing incidents.
# Action Item Liquid Variables
Source: https://docs.rootly.com/liquid/action-item-variables
Reference guide for action item variables available in Liquid templates for Genius workflows and integration formatting.
You can use action item variables with genius workflows:
# Variables[](#nHtHd)
This is bold text.
' | html_to_markdown }} // Output // # Title // // This is **bold** text. ``` ```js JS theme={null} {{ '| Date | #User | #Event | #
|---|---|---|
| December 8 2022 23:04:28 PST | #John D | #Event 1 | #
| December 8 2022 23:04:28 PST | #Dalyte K | #Event 2 | #
| Creation Date | #Due Date | #Kind | #Priority | #Status | #Assignee | #Summary | #
|---|---|---|---|---|---|---|
| December 7 2022 23:04:28 PST | #December 8 2022 00:00:00 PST | #Task | #Low | #Open | #John D | #Action Item 1 | #
| December 7 2022 23:04:28 PST | #December 8 2022 00:00:00 PST | #Follow Up | #High | #Done | #Dalyte K | #Action Item 2 | #
# Configuring Teams
Source: https://docs.rootly.com/managing-teams/configuring-teams
Learn how to create, configure, and manage teams in Rootly including member management, ownership settings, and Slack channel mappings.
To add a new team, navigate to **Configuration --> Teams --> Add New Team or Import Teams**
# Creating a team
### In Rootly
Give your new team a name and description to easily identify the team on any forms and relevant incidents. Set the team color if desired using the color palette.
Click Save to create your new team.
### Importing via PagerDuty or OpsGenie
You are able to migrate your existing PagerDuty and OpsGenie teams into Rootly with our native integrations. Read the instructions [here](/managing-teams/importing-teams).
# Editing teams
In your Configuration > Teams section, select the Edit button for the Team you want to configure.
## Members
The Members tab is where you can add and manage the members of your team. Team Members are granted additional permissions on top of their Rootly User Roles, which allow them to view the Schedules and Escalation Policies for their teams. Team Admins are also able to edit the Schedules and Escalation Policies.
Add new team members by:
1. Selecting 'Add Member' and searching for the Rootly User.
2. \[Optional] You can assign this individual an Incident Role: this team member will be automatically assigned this Incident Role anytime an incident is created and assigned to this team.
Once your team members are added, assign a team admin in the Team Admin field.
## Integrations
The Integrations tab allows you to map any PagerDuty or OpsGenie teams and services to your Rootly team.
# Importing Teams
Source: https://docs.rootly.com/managing-teams/importing-teams
Import existing team structures from PagerDuty and Opsgenie integrations to quickly populate your Rootly team configuration.
You have the option to import teams from third-party integrations such as [PagerDuty](/integrations/pagerduty) and [Opsgenie](/integrations/opsgenie).
If you've already configured these integrations, then you can save time and import your teams right away.
If not, we'd suggest going to the integrations page (linked above) for that service and configure it prior to continuing.
To import a team for a previously configured integration, do the following:
Navigate back to the team dashboard if you're not already there. Then locate the **Opsgenie** or **PagerDuty** buttons and click the desired service from which you want to import your teams.
You will see an interstitial listing the teams that are available to import via the integration. Select the teams you'd like to import, then click **Import**.
The teams you've chosen to import will be reflected in the teams dashboard.
# Incident Roles
Source: https://docs.rootly.com/managing-teams/incident-roles
Configure and manage incident roles to automatically assign team members specific responsibilities when incidents are assigned to their teams.
Incident roles determine which roles team members are assigned to when an incident occurs that is assigned to a given team. This helps to avoid manual intervention or confusion in the middle of an incident, and automate the process of assigning roles.
When a team is attached to an incident, the named team member will be automatically assigned to the chosen role.
To add a new team role, do the following:
Navigate to **Configuration --> Incident Roles --> Create Role** Fill in desired fields:
* Name (required)
* Description (optional)
* Responsibilities (optional): Add a responsibilities message to send to user when they are assigned the role.
* Ability to make the role optional or not
* Ability to allow multiple users to be assigned to a role
Once desired fields are completed, click **Create Role** in the bottom right-hand corner.
Once the new role is created, go back and edit it to **Add Default Tasks**. Adding a default task will automatically assign the task to a user when they are assigned the role during an incident.
Once the new incident role and default tasks have been added, the next step is to navigate back to your **Team(s)** and edit desired team. Once back under desired team, navigate to **Members** tab to add team members and set desired incident roles then click **Create**.
Additionally, you can automatically assign roles based on who is on-call for a schedule, team or escalation policy. This will automatically add that user to the incident channel if they are actively on-call and associated/assigned with a role. To automatically page them you can create a [Workflows](/workflows) and set the Conditions to match your specific teams.
# Overview
Source: https://docs.rootly.com/managing-teams/managing-teams
Create and manage teams in Rootly to organize on-call schedules, route alerts, configure Slack automation, and import team structures from PagerDuty or Opsgenie.
In Rootly, Teams are groups of users that should represent ownership over a specific department, function, or product within your company. Teams in Rootly can:
* Own Schedules and Escalation Policies as part of Rootly On-Call.
* Have Alerts routed to directly from Alert Sources and emails. This ensures that Teams will instantly be paged when an Alert from a relevant source comes in.
* Map to specific Slack channels and user groups, allowing for team-based Slack automation to be configured in Rootly.
You can create Teams and assign users via the Rootly web UI, or by importing them directly from third-party services such as PagerDuty, or Opsgenie. Other third-party integrations will follow soon.
# Viewing Teams
Source: https://docs.rootly.com/managing-teams/viewing-teams
Navigate and view your organization's teams in the Rootly dashboard, including pre-configured and imported team structures.
It's simple to configure teams for your organization, just follow the instructions below. By default, Rootly already pre-defines teams (Infrastructure, Security, and Search).
First, locate the **Configuration** menu in the Rootly navigation bar, then click **Teams**.
There, you will see the teams dashboard and the various options available to configure teams. If there are pre-existing teams that were previously created or imported, then they will already be populated in the dashboard.
# Delete or resend Invitations
Source: https://docs.rootly.com/managing-users/invitations
Manage pending user invitations by resending or deleting them from the organization settings dashboard.
Users will be assigned the default role in Organizational Settings.
Users can complete sign-up with Google, Slack, SSO, or by creating a password.
Passwords must have at least 10 characters and include:
* one lowercase letter
* one uppercase letter
* one digit
* one special character
# Inviting Users
Source: https://docs.rootly.com/managing-users/inviting-users-via-web-ui
Send email invitations to new users to join your Rootly organization with specified roles and permissions through the web interface.
Users can complete sign-up with Google, Slack, SSO, or by creating a password.
Passwords must have at least 10 characters and include:
* one lowercase letter
* one uppercase letter
* one digit
* one special character
# Manage Users
Source: https://docs.rootly.com/managing-users/managing-users
View and manage organization members, including their contact information, roles, and integration statuses in Rootly.
# Legacy Process[](#c5nNn)
For customers that prefer the legacy incident processes, the following configuration will align with the previous retrospective settings.
1. Navigate to the [Retrospective Processes configuration page](https://rootly.com/account/retrospective-processes "Retrospective Processes configuration page").
2. Modify the "When should the Retrospective be mandatory?" multi-select to choose all severities or types.
3. Edit the 'Default Retrospective' process
4\. Remove all steps from the default process with the exception of the 'Write The Retrospective Document' and the 'Gather Data' steps.
# Configuring Retrospective Processes
Source: https://docs.rootly.com/retrospectives/configuring-retrospective-processes
Retrospectives have configurable, customizable processes, made up of steps, to allow a right-sized retrospective based on severity, type, or teams involved in an incident.
# Process Defaults[](#DwoL5)
A retrospective process is a series of steps that will be applied to an incident and guide responders through a retrospective. Rootly provides a default retrospective process with generalized steps that will work for many use cases. No configuration is required, the [default steps](/retrospectives/configuring-process-steps) will be applied to all incidents.
# Customized Process[](#vmdSt)
For more opinionated incident practices, retrospective processes can be created, customized, and applied to incidents meeting specific requirements. The ability to scale retrospective processes based on the severity, team, or type of incident allows programs to right-size their retrospective process and support responders regardless of what kind of incident occurs.
The following incident attributes can be used to apply custom processes:
* Severity
* Type
* Team
Processes can also be configured to be required or auto skipped based upon the same incident attributes.
* Required retrospective processes are not able to be skipped by responders.
* Auto-skipped processes are skipped by default, but have the option to be reinstated at responder discretion.
### Receiving General Alerts
In order to send general (non-paging) alerts to Rootly, you'll need to modify the `alert-manager.yml` configuration file as shown below:
```YAML theme={null}
route:
receiver: default
group_by:
- job
routes:
- receiver: rootly
match:
alertname: Rootly
repeat_interval: 1m
receivers:
- name: rootly
webhook_configs:
- url: 'https://webhooks.rootly.com/webhooks/incoming/alertmanager_webhooks'
send_resolved: true
http_config:
authorization:
type: Bearer
credentials: a0b9fcad1aae0689cfa05c17df497b2bc5c56d26d3e253503438864dbd6697ee
```
Copy the *Webhook URL* field and *secret* from the pop-up above, and set it as the `url` and `credentials` parameters, respectively.
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Workflows
Source: https://docs.rootly.com/integrations/asana/workflows
Configure Asana workflow actions to create tasks and manage project items from Rootly incidents.
## Create an Asana Task
## Create an Asana Subtask
## Update an Asana Task
## Custom fields
```JSON theme={null}
"custom_fields": {
"4578152156": "Not Started", // For textfield type
"5678904321": "On Hold", // For textfield type
"5678904322": "1004598149" // For single enum type
"5678904322": ["459021796", "1004598149"] // For multi enum type
},
"custom_fields": {
"4578152156": "{{ incident.severity }}", // For textfield type
"5678904321": "{{ incident.status }}", // For textfield type
},
"custom_fields": {
"4578152156": "{{ incident.severity }}", // For textfield type
// For single enum type
{% if incident.severity == "sev0" %}
"5678904322": "1004598149" // Custom Field ID <=> Enum ID
{% elsif incident.severity == "sev1" %}
"5678904322": "1004598149" // Custom Field ID <=> Enum ID
{% endif %}
},
```
# Installation
Source: https://docs.rootly.com/integrations/clickup/installation
Install and configure the ClickUp integration to automatically create tasks from Rootly incidents and action items.
## Why
**ClickUp** Integration allows you to:
* Creating an incident in **Rootly** will create a task in **ClickUp** if you choose to.
* Creating an action item in **Rootly** will create a task in **ClickUp** if you choose to. Attached as **subtasks** if incident has been created in **ClickUp** as well.
* **Changing** task **title, description,** **status** in **Rootly** will update the task in **ClickUp.**
* **Changing** action item **title, description,** **status** in **Rootly** will update the task in **ClickUp.**
## Installation
Locate **ClickUp** on the [Integrations catalogue](https://rootly.com/account/integrations "Integrations catalogue") and select Setup.
You'll be presented with the following installation page. Please generate a [ClickUp Personal API Token (PAT)](https://clickup.com/api/developer-portal/authentication/#generate-your-personal-api-token "ClickUp API Token") and paste it into the API Key field before you confirm the installation by selecting `Connect`.
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Workflows
Source: https://docs.rootly.com/integrations/clickup/workflows
Configure ClickUp workflow actions to create tasks and manage project items from Rootly incidents.
### Create a ClickUp Subtask for Action Item
### Update a ClickUp Task
### Update a ClickUp Subtask
### Update a ClickUp Subtask
## ClickUp --> Rootly Workflows
### Data Mapping Syntax
```JSON theme={null}
{
{% if alert.data.history_items[0].field == 'name' %}
"title": "{{ alert.data.history_items[0].after }}"
{% endif %}
{% if alert.data.history_items[0].field == 'status' %}
{% if alert.data.history_items[0].after.status == 'complete' %}
"status":"done"
{% else %}
"status":"open"
{% endif %}
{% endif %}
{% if alert.data.history_items[0].field == 'priority' %}
{% if alert.data.history_items[0].after == null %}
"priority":"medium"
{% elsif alert.data.history_items[0].after.priority == 'urgent' %}
"priority":"high"
{% elsif alert.data.history_items[0].after.priority == 'high' %}
"priority":"high"
{% elsif alert.data.history_items[0].after.priority == 'normal' %}
"priority":"medium"
{% else %}
"priority":"low"
{% endif %}
{% endif %}
{% if alert.data.history_items[0].field == 'due_date' %}
{% if alert.data.history_items[0].after != null %}
{% assign date = alert.data.history_items[0].after %}
{% assign dateInSeconds = date | divided_by: 1000 %}
"due_date": "{{ dateInSeconds | date: "%Y-%m-%d" }}"
{%endif %}
{% endif %}
}
```
# Confluence
Source: https://docs.rootly.com/integrations/confluence/confluence
Streamline incident retrospectives with Confluence integration, featuring automated retrospective creation and pre-built templates.
## Overview
Rootly's Confluence integration helps streamline the process of completing incident retrospectives. By leveraging pre-built templates and workflows, teams can automate their retrospective creation - saving hours of manual work, per incident.
Some key features of this integration includes:
1. **Customizable templates**
* Rootly enables teams to pre-define retrospective templates in both Rootly and Confluence. If you're looking for a semi-custom retrospective that follows industry best practices, you can simply define the retrospective body in Rootly and we will take care of the rest. If you want a fully customized retrospective, you can build your template in Confluence and we will generate the retrospective accordingly.
2. **Liquid variable support**
* Liquid variables can be referenced in both templates created in Rootly or Confluence.
3. **Timeline Visualization:**
* Incident timelines are automatically generated for templates created in Rootly.
* [Custom Liquid syntax](/liquid/incident-variables) can be used to generate timelines for templates created in Confluence
4. **Action Item Tracking:**
* Follow-ups are automatically recorded when Rootly-hosted templates are used.
* [Custom Liquid syntax](/liquid/incident-variables "Custom Liquid syntax") can be used to list out follow-ups in templates hosted on Confluence.
## Installation
Please see the [**Installation** page](/integrations/confluence/installation "Installation") to get started with your Confluence integration.
## Workflows
Rootly relies on workflows to automate interactions with Confluence. The [**Workflows** page](/integrations/confluence/workflows "Workflows") will walk you through how to set up commonly used workflows involving Confluence.
# Installation
Source: https://docs.rootly.com/integrations/confluence/installation
Install and configure the Confluence integration with Rootly to enable automated retrospective creation and document management.
## Installing Confluence on Rootly
You'll be prompted to grant Rootly permission to integrate with your Confluence account. Once confirmed, the installation is considered complete!
## Setting Up Retro Templates in Confluence
Once logged into Confluence, select the ***Space*** in which you want to create the retrospective template in.
Select ***Space Settings***.
Select ***Templates*** under Look and Feel.
Click on `Create New Template`.
Now you can build out your custom template! Liquid syntax is supported.
# Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete.**
# Workflows
Source: https://docs.rootly.com/integrations/confluence/workflows
Configure Confluence workflows to automatically generate retrospective pages and manage document creation from Rootly incidents.
## Overview
Our Confluence Cloud integration leverages workflows to automatically generate retrospective pages in Confluence. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows "Workflows") documentation first.
## Available Workflow Actions
### Create a Confluence Page
This action allows you to create an incident retrospective into a Confluence Page.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Space Key
This field allows you to enter the Confluence `Space Key` in which the retrospective will be created into.
To find the key for your Confluence Space, you'll need to go to **Space Settings > Space Details** in your Confluence instance.
#### Ancestor
This field allows you to enter the Confluence `Page Key` in which the retrospective will be created under. To learn how to obtain a `Page Key`, please see instructions [here](https://confluence.atlassian.com/confkb/how-to-get-confluence-page-id-648380445.html "here").
#### Title
This field allows you to define the title of the Confluence page. You can use `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
# Alerts
Source: https://docs.rootly.com/integrations/datadog/alerts
Configure Datadog to send monitoring events to Rootly as alerts for Slack notifications and incident initiation.
## Overview
Datadog can be configured to send events into Rootly as alerts. The alerts received on Rootly can then be routed to a Slack channel or used to initiate incidents.
## Configure Webhook in Datadog
You'll be asked to configure a webhook. Now, select `+ New` in Webhooks section (lower left corner of the modal).
Once we have located the Webhook within Datadog, we would need to configure the Webhook to point to the following URL:
```txt URL theme={null}
https://webhooks.rootly.com/webhooks/incoming/datadog_webhooks
```
You'll be promoted to enter the following details for the webhook.
### Name
Give your webhook a representative name.
### URL
The webhook URL can be obtained from your Datadog integration page in Rootly (**Integrations** > **Datadog** > **Configure**).
### Payload
#### General Alert
Copy the following code and paste it into the `Payload` field. This will result in a regular (non-paging) alert.
```json theme={null}
{
"id":"$ID",
"body":"$EVENT_MSG",
"last_updated":"$LAST_UPDATED",
"event_type":"$EVENT_TYPE",
"title":"$EVENT_TITLE",
"alert_id":"$ALERT_ID",
"alert_metric":"$ALERT_METRIC",
"alert_priority":"$ALERT_PRIORITY",
"alert_query":"$ALERT_QUERY",
"alert_scope":"$ALERT_SCOPE",
"alert_status":"$ALERT_STATUS",
"alert_title":"$ALERT_TITLE",
"alert_transition":"$ALERT_TRANSITION",
"alert_type":"$ALERT_TYPE",
"date":"$DATE",
"org":{"id":"$ORG_ID","name":"$ORG_NAME"}
}
```
#### Paging Rootly On-Call
Paging through Rootly On-Call also relies on webhook alerts. The main difference being the inclusion of a `notification_target` object.
```json theme={null}
"rootly": {
"notification_target": {
"type": "Service",
"id": "00acba53-b07e-455d-add6-73263209a610"
}
}
```
* `type` - this defines the Rootly resource type that will be used for paging.
* The following are the available values: `User` | `Group` (Team) | `EscalationPolicy` | `Service`
* `id` - this specifies the exact resource that will be targeted for the page.
* The `id` of the resource can be found when editing each resource.
Copy the following code and paste it into the `Payload` field. This will result in both the alert appearing in Rootly and the targeted resource being paged.
```json theme={null}
{
"id":"$ID",
"body":"$EVENT_MSG",
"last_updated":"$LAST_UPDATED",
"event_type": "composite_monitor",
"title":"Datadog webhook alert",
"alert_id":"$ALERT_ID",
"alert_metric":"$ALERT_METRIC",
"alert_priority":"$ALERT_PRIORITY",
"alert_query":"$ALERT_QUERY",
"alert_scope":"$ALERT_SCOPE",
"alert_status":"$ALERT_STATUS",
"alert_title":"$ALERT_TITLE",
"alert_transition":"$ALERT_TRANSITION",
"alert_type":"$ALERT_TYPE",
"date":"$DATE",
"org":{"id":"$ORG_ID","name":"$ORG_NAME"},
"rootly": {
"notification_target": {
"type": "Service",
"id": "00acba53-b07e-455d-add6-73263209a610"
}
}
}
```
### Custom Header
Check the `Custom Header` checkbox and paste the following code into the text area.
```json theme={null}
{"secret":"a04d2feb4286150731a718acba564198605675ec191ef9ae7956c6e15af54edf"}
```
Replace the `secret` value with the one found in your Datadog integration in Rootly (**Integrations** > **Datadog** > **Configure**).
Once completed, go ahead and select `Save` to create your webhook.
## Attach Webhook to Monitor
Once your webhook is created, you need to attach it to a Datadog monitor. A monitor contains the firing logic that determines when alerts will be sent out.
Navigate to **Monitor** > **New Monitor** > **Event** to create a new monitor.
Now, you can configure your monitor to your desired firing logic. The main action to ensure that you do is **select your webhook** in the **Notify your team** section.
Once ready, you can select `Test Notifications` to test out your monitor and webhook. You should see a test alert appear from Datadog on your [Rootly Alerts page](https://rootly.com/account/alerts "Rootly Alerts page").
Finally, **save your monitor**. The resulting product should look something like this:
# Datadog
Source: https://docs.rootly.com/integrations/datadog/datadog
Create notebooks, retrieve snapshots and dashboards, and receive alerts from Datadog to auto-create incidents.
Datadog is a SaaS based monitoring tool for engineering teams.
Integrating with Datadog allows you to:
* **Create Datadog notebooks** through workflows.
* **Retrieve Datadog graph snapshots** through workflows.
* **Retrieve Datadog dashboards** through workflows.
* **Receive Datadog alerts** to auto create incidents.
### **Requirements**
* Datadog Admin role
* Rootly Owner or Admin
### Installation
Please see the [Installation page](/integrations/datadog/installation) to get started with your Datadog integration.
### Alerts
Rootly can ingest alerts from Datadog webhooks. The [**Alerts page**](/integrations/datadog/alerts) will walk you through how to set up Datadog to send alerts to Rootly and commonly used workflows involving Datadog alerts.
# Installation
Source: https://docs.rootly.com/integrations/datadog/installation
Install and configure the Datadog integration with Rootly to enable monitoring alerts and notebook creation.
## Installing Datadog on Rootly
Now, you will be asked to enter your Datadog API Key and Application Key.
### Create API Key in Datadog
To obtain the API Key, you'll need to log into your Datadog account and select: **Your user (lower left corner) > Organization Settings > API Keys >** `**+ New Key**`
Give your API Key a representative name and select `Create Key`.
Copy the newly created API Key.
Paste API Key into the Rootly Datadog setup modal.
### Create Application Key in Datadog
To obtain the Application Key, navigate to **> Application Keys >** `**+ New Key**`
Give your Application Key a representative name and select `Create Key`.
Edit the permission to only grant `dashboard_read`.
Copy the newly created Application Key.
Paste Application Key into the Rootly Datadog setup modal.
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**.
# Installation
Source: https://docs.rootly.com/integrations/dropbox-paper/installation
Install and configure the Dropbox Paper integration with Rootly to enable automated retrospective document creation.
## Installing Dropbox Paper on Rootly
You'll be prompted to grant Rootly permission to integrate with your Dropbox Paper account. Once confirmed, the installation is considered complete!
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Workflows
Source: https://docs.rootly.com/integrations/dropbox-paper/workflows
Configure Dropbox Paper workflows to automatically generate retrospective documents from Rootly incidents.
## Overview
Our Dropbox Paper integration leverages workflows to automatically generate retrospective documents in Dropbox Paper. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows "Workflows") documentation first.
## Available Workflow Actions
### Create a Dropbox Paper
This action allows you to create a retrospective document into a Dropbox Paper folder.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Namespace
This field is **only available if you integrated with Dropbox Paper Business**. This field allows you to select the team folder in which the `Parent Folder` will be selected from.
#### Parent Folder
This field allows you to define which folder to create the Paper document in. The list of folders shown in the dropdown are determined by whether if you integrated with Dropbox Paper or Dropbox Paper Business.
* If you integrated with **Dropbox Paper**, then the list of folders will be restricted to your personal folders.
* If you integrated with **Dropbox Paper Business**, then the list of folders will be dependent on the folder selected in the `Namespace` field.
#### Title
This field allows you to define the title of the Paper document. It is defaulted to match the title ( `{{ incident.title }}` ) of your incident. This field supports Liquid syntax.
You can specify the **api key** and which **domain** you want to create tasks in
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Workflows
Source: https://docs.rootly.com/integrations/freshdesk/workflows
Configure Freshdesk workflow actions to create and update tickets and tasks from Rootly incidents.
You'll be **prompted to name your source**.
Follow the instructions present on the Generic webhook creation page to complete setup.
### Note on setting the team, escalation policy or service
There are several options for specifying how an alert can be associated with a service, escalation policy or team.
#### Using the webhook URL
This is the most simple option, allowing for a single service, team or escalation policy to be associated with an alert.
1. Set the `type` and `id` in the webhook url following the default instructions in 'Step 1' to indicate on a per webhook basis what type (`service`, `group` (team) or `escalationPolicy`) and the correct id of service, team or escalation policy.
2.
3. Set the required field 'notification name' in Step 2.
4. Click 'save' then 'I finished this step' buttons
**Note**: *if `type` and `id` are set in the url of Step 1, indicating the `type` and `id` can be skipped in Step 2.*
#### Using the response payload
Alternatively, the `type` and `id` can be set after the call is made, by parsing the response payload from your observability provider. *This is a more flexible option allowing multiple types and id's to be set with a single webhook but requires modification of the observability providers payload*.
1. Follow Step 1 instructions, but do not include the type and id in the webhook url ([https://webhooks.rootly.com/webhooks/incoming/generic\_webhooks/notify/](https://webhooks.rootly.com/webhooks/incoming/generic_webhooks/notify/))
2. In your observability provider, update the response payload to include the type (`service`, `group` (team) or `escalationPolicy`) and id (found on each respective objects rootly index page).
1. Example: `{... type: service, type: 
# Google Cloud Monitoring
Source: https://docs.rootly.com/integrations/google-cloud-monitoring
Receive alerts from Google Cloud Monitoring to trigger incidents, route to Slack, or page on-call teams.
Google Cloud Monitoring can be configured as an alert source to send events into Rootly as alerts. The alerts received on Rootly can then be routed to a Slack channel, used to initiate incidents, or used to page Rootly On-Call targets.
## Configure Webhook in GCP
Navigate to Google Cloud Console and click on the VIEW ALL PRODUCTS button in the left pane to access the complete list of products.
In the left pane, find and select the **Observability** category, then choose **Monitoring**.
In the **Monitoring** section, select **Alerting** from the left pane and click on the **EDIT NOTIFICATION CHANNELS** button at the top.
Find the **Webhooks** channel and click on the **ADD NEW** button next to it.
Fill in the form with the required details:
`**Display Name**` - give your webhook a description name
Check the `**Use HTTP Basic Auth**` checkbox.
Enter the following URL into the `**Endpoint URL**` field.
Copy your organization-specific `**Auth Password**` from the 5th step.
Click on the **TEST CONNECTION** button to verify the webhook configuration. A successful test will enable the **SAVE** button.
Once the connection test is successful, click the **SAVE** button to finalize the webhook setup.
# Installation
Source: https://docs.rootly.com/integrations/google-docs/installation
Install and configure the Google Docs integration with Rootly to enable automated document creation for incident management.
## Installing Google Docs on Rootly
You'll be prompted to choose a connection method to your Google account: `Connect through OAuth credentials` or `Connect through JSON file credentials`.
### Integrating via OAuth (non-GCP service account)
Click on `Setup` to start the integration process. You'll be prompted to select a Google account.
After selecting a Google account, you'll be prompted to grant Rootly permission to integrate with your Google account.
Once confirmed, you'll be redirected back to Rootly and the installation is considered complete!
### Integrating via GCP service account
Navigate to your [Google Cloud](https://console.cloud.google.com/ "Google Cloud") Console, and click on `IAM & Admin`.
Next, navigate to `Service Accounts` and create a new service account by clicking on `Create Service Account`.
Fill in the Service account details, your `Service Account ID` will be automatically generated. Click on `Done` when you have completed the form.
Next, Navigate to the `Keys` tab and click on `Add a Key`.
Create a key and download the JSON format.
Next, go back to the Rootly integration page and upload the JSON key.
Finally, navigate to [https://admin.google.com](https://admin.google.com/ "https://admin.google.com") > Security > [Api Controls](https://admin.google.com/ac/owl "Api Controls") > [Domain Wide Delegation](https://admin.google.com/ac/owl/domainwidedelegation "Domain Wide Delegation") and select your service account.
Add the following scopes and click on Authorize:
* [https://www.googleapis.com/auth/drive.file](https://www.googleapis.com/auth/drive.file), [https://www.googleapis.com/auth/drive.appdata](https://www.googleapis.com/auth/drive.appdata)
The integration process is now complete!
## Setting Up Retro Template in Google Docs
Retrospective templates can be set up in Rootly or Google Docs. For details on how to create templates in Rootly, please refer to [this page](/retrospectives/configuring-templates "this page").
To set up templates in Google Doc, simply open a new Doc in Google Drive and built out the document as you would with any document. For any incident values that you'd like to dynamically reference, you can do so using [Liquid syntax](/liquid "Liquid syntax").
## Available Workflow Actions
### Create a Google Doc
This action allows you to create an incident retrospective into a Google Doc.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Parent Folder
This field allows you to select a folder in your Google Drive in which your Google Doc will be created into. If you don't specify a folder, we will use the folder path specified in the `Title` field.
#### Title
This field allows you to define the title of the retrospective document. Liquid syntax is supported in this field.
If you wish to dynamically create folders to nest your document in, you can do so by separating each folder with a `/`. For example, if you enter the following text as the title:
`{{ incident.created_at | date: '%Y' }}/{{ incident.created_at | date: '%B' }}/{{ incident.title }}`
The storage path will be:
**\[Folder] year of incident creation > \[Folder] month of incident creation > \[Doc] Incident Title**
#### Custom Retrospective Template
This field allows you to define the body content of the retrospective. Liquid syntax is supported in this field.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### File
This field allows you to specify the id of the document in your Google Drive that you want to update. The default is set to `{{ incident.google_drive_id }}`. Liquid syntax is supported in this field.
#### Title
This field allows you to update the title of the Google Doc. Liquid syntax is supported in this field.
#### Custom Retrospective Template
This field allows you to update the body content of the Google Doc. Liquid syntax is supported in this field.
#### Retrospective Template
This field allows you to use a predefined retrospective template to update the body content of the Google Doc.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### File
This field allows you to specify the id of the file in your Google Drive that you want to create permissions for. The default is set to `{{ incident.google_drive_id }}`. Liquid syntax is supported in this field.
#### Define Sharing Permissions
You can customize permissions like shown below:
```json theme={null}
[
{
"type": "user",
"role": "writer",
"email_address": "user@example.com"
},
{
"type": "user",
"role": "owner",
"transferOwnership": true,
"email_address": "user@example.com"
},
{
"type": "domain",
"role": "writer",
"domain": "example.com"
}
]
```
#### Send Email Notification
You can optionally notify the users who are granted permission by email.
#### Email Message
You can optionally provide a message to be sent with the email notification. The message will be sent only if the `Send Email Notification` box is checked.
### Remove Google Doc Permissions
This action allows you to revoke existing user permissions to a retrospective document.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### File
This filed allows you to specify the id of the file in your Google Drive that you want to revoke permissions from. The default is set to `{{ incident.google_drive_id }}`. Liquid syntax is supported in this field.
#### Attribute to Query By
This field allows you to select an attribute by which you want to revoke permissions for. There are three options:
1. `Type`: Can be `user`, `group`, `domain`, or `anyone`.
2. `Role`: Can be `owner`, `organizer`, `fileOrganizer`, `writer`, `commenter`, or `reader`.
3. `Email Address` (default): The email address of the user from whom you want to revoke permissions.
#### Value
This field allows you to specify the value of the attribute that was selected in the previous field, `Attribute to Query By`. Liquid syntax is supported in this field.
Example 1:
* If,
* `Attribute to Query By` = `Role`
* `Value` = `Writer`
* Then,
* Every user with the `Writer` role will have their permissions revoked
Example 2:
Select `+ Add contact point`.
You'll be prompted to enter the following details for the contact point.
### Name
Give your contact point a representative name.
### Integration
Select Webhook.
### URL
#### For General Alert
Grafana requires the *webhook URL* and *secret* to be included in the `URL` field. This will result in a regular (non-paging) alert.
The webhook URL and secret can be obtained from your Grafana integration page in Rootly (**Integrations** > **Grafana** > **Configure**). Enter the webhook URL and secret in the following format in the URL field:
`https://webhooks.rootly.com/webhooks/incoming/grafana_webhooks/?secret=
#### To Page Rootly On-Call
Paging through Rootly On-Call also relies on webhook alerts. The main difference being the inclusion of a notification target in the query parameter.
The notification target consists of the following:
* `resource_type` - this defines the Rootly resource type that will be used for paging.
* The following are the available values: `User` | `Group` (Team) | `EscalationPolicy` | `Service`
* `resource_id` - this specifies the exact resource that will be targeted for the page.
* The id of the resource can be found when editing each resource.
Enter the webhook URL and secret in the following format in the URL field:
`https://webhooks.rootly.com/webhooks/incoming/grafana_webhooks/notify/
### HTTP Method
Select `POST`.
Once ready, you can select the `Test` button to test out your contact point. You should see a test alert appear from Grafana on your [Rootly Alerts page](https://rootly.com/account/alerts "Rootly Alerts page").
Finally, **save contact point**.
## Attach Contact Point to Alert Rules
Once your contact point is created, you need to attach it to a Grafana alert rule. An alert rule contains the firing logic that determines when alerts will be sent out.
Navigate to **Alert rules** and select `+ New Alert rule`.
You'll be prompted to define a rule set. The key is to set the `Contact point` to the one you created above. ***Note:*** *You can also add the contact point to your existing alert rules.*
# Grafana
Source: https://docs.rootly.com/integrations/grafana/grafana
Capture Grafana dashboard snapshots through Genius workflows for incident analysis and documentation.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
Go in your Grafana instance and let's create an **Api Key**:
Copy your **instance url** and **api key** into Rootly:
All set!
## Snapshot dashboards
Now a new task is available in your **Genius workflows.**
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Honeycomb
Source: https://docs.rootly.com/integrations/honeycomb
Receive alerts from Honeycomb's observability platform to trigger incidents, route to Slack, or page on-call teams.
Honeycomb can be configured to send events into Rootly as alerts. The alerts received on Rootly can then be routed to a Slack channel, used to initiate incidents, or used to page Rootly On-Call targets.
## Installation
### Establish Authentication
To set up Honeycomb, you will need to first log into Honeycomb as an **admin user.**
Once logged in, make sure you are on the **environment** that you're looking to integrate with Rootly and select the **settings icon** ⚙️.
Then, select the **API Keys** tab > **Configuration** > **Create Configuration API Key**.
In the **Create API Key** modal, enter a description `Name` and check **any of the permissions**. Once complete, go ahead and save the API key.
Now, copy your newly generated API key from Honeycomb and **paste it into the Honeycomb integration modal in Rootly** and select **Connect**.
A successful integration will give you the **webhook URL** + **secret** combination needed to configure webhooks in your Honeycomb account.
### Create a Webhook
Now that you have your organization specific **webhook URL** + **secret** combination, let's go to your Honeycomb account to create a webhook.
Once logged in, navigate to the **Team settings** page.
Then select the **Integrations** tab and click on **Add Integration**.
In the Add Integration modal, set the `Provider` to `Webhook` and give it a description `Name` (e.g. Page Engineering On-Call, Page Infrastructure Team, Rootly Alerts, etc.).
The value you put in the `Webhook URL` field will depend on what type of alert you want this particular webhook to send to Rootly.
**For General Alert (aka. Non-Paging Alert)**
Non-paging alerts will arrive in Rootly's [Alerts page](https://rootly.com/account/alerts "Alerts page") but will not page anyone.
Honeycomb requires the *Webhook URL* and *secret* from Rootly to be included in the Webhook URL field in the following format:
```txt Webhook URL theme={null}
https://webhooks.rootly.com/webhooks/incoming/honeycomb_webhooks?secret=
Ensure that you delete your webhooks in Honeycomb as well. Deleting the integration in Rootly will NOT stop Honeycomb from sending Rootly alert events.
# IP Whitelist
Source: https://docs.rootly.com/integrations/ip-whitelist
Configure IP whitelisting for Rootly integrations to ensure secure network communication with your infrastructure and third-party services.
## Overview
When configuring integrations with Rootly, you may need to whitelist specific IP addresses to allow secure communication between Rootly and your internal systems or third-party services.
## 🛡️ Security Considerations
IP whitelisting provides an additional layer of security by:
* **Restricting access** to only trusted IP addresses
* **Preventing unauthorized connections** from unknown sources
* **Ensuring compliance** with your organization's security policies
* **Protecting sensitive data** during integration communication
## 📍 Rootly Outbound IP Addresses
All Rootly integrations use the following outbound IP addresses for external communication:
You'll be presented with the following installation page. Double check that you're installing the correct instance before you confirm the installation by selecting `Accept`.
That's it! You're all set to begin automating Jira workflows now.
## Installing Additional Instances
If your organization leverages multiple Jira Cloud instances, you can install additional instances using the same procedure above.
The ensuing steps are the same as installing the first instance.
Give the webhook an easy to identify `Name` (e.g. Rootly Webhook Listener) and copy the webhook URL from your Rootly platform.
Ensure the webhook's `Status` is `Enabled`.
Copy the webhook URL from the Rootly integrations page into the `URL` field in Jira.
If you do not want all your Jira projects to send events to Rootly, you can filter for them in the Issue related events JQL query.
Select the specific events you'd like to listen for.
Finally, ensure that you DO NOT check the `Exclude body` checkbox. Sometimes, Jira webhooks will have this checked by default.
Once all of the above fields are entered, select `Create` to save the webhook configuration.
Now you'll be able to see Jira events appear in the [Alerts page](https://rootly.com/account/alerts "Alerts page") on your Rootly platform. You can test this by creating or update a test ticket in Jira. If the event appears on the Alerts page then you'll know the webhook is working.
## Uninstall
You can uninstall your Jira Cloud instance on Rootly by can navigating to **Integrations > Jira** on and selecting `Delete`.
# Jira
Source: https://docs.rootly.com/integrations/jira/jira
Bidirectionally sync incidents and action items between Rootly and Jira with automatic issue creation and updates.
Integrating with Jira allows you to:
* Automatically **create a Jira issue** for each incident declared on Rootly.
* Automatically **update a Jira issue** for each update made to an incident on Rootly.
* Automatically **create a Jira issue or subtask** in Jira when an action item is created on Rootly.
* Automatically **declare an incident on Rootly** when an issue is created in Jira. Webhook setup required in Jira.
* Automatically **update an incident on Rootly** when an issue is updated in Jira. Webhook setup required in Jira.
## Smart Defaults
Rootly's Jira integration comes with a set of commonly used default settings. See [Smart Defaults](/integrations/jira/smart-defaults) page for details.
## Rootly to Jira Sync
Rootly to Jira workflows allow you to automatically create/update a Jira issue whenever an incident or action item in Rootly is created/updated.
See [Rootly to Jira Sync](/integrations/jira/rootly-to-jira-sync "Rootly to Jira Sync") page for detailed configuration instructions.
## Jira to Rootly Sync
Jira to Rootly workflows allow you to automatically create/update an incident or action item in Rootly whenever a Jira issue or subtask is created/updated.
See [Jira to Rootly Sync](/integrations/jira/jira-to-rootly-sync "Jira to Rootly Sync") page for detailed configuration instructions.
# Jira to Rootly Sync
Source: https://docs.rootly.com/integrations/jira/jira-to-rootly-sync
Select workflow **triggers**. `Alert Created` will be the only option to select here. This means the workflow will initialize whenever a new alert is created in Rootly.
Configure **run conditions**. Set up your workflow to only run if...
* The alert `source` is from `Jira`
* The alert `labels`:
* **Option 1:** `contains all of` the following `labels` (this is if you want to respond to a new Jira issue being created)
* `event:jira:issue_created`
* `project_key:RD1` (this label is optional - only include this if you want to respond to issues from a specific Jira project)
* **Option 2:** `contains all of` the following `labels` (this is if you want to respond to an existing Jira issue being updated)
* `event:jira:issue_updated`
* `project_key:RD1` (this label is optional - only include this if you want to respond to issues from a specific Jira project)
* The alert `payload` has the `$.object.specific_field` equals to `/specific_value/i`
* **JSON path syntax** is used to filter for a specific field from the alert payload (e.g. \$.issue.fields.issuetype.name). You can preview your syntax on [JSON Path Explorer](https://rootly.com/account/help/json-path-explorer "JSON Path Explorer").
* **Ruby regular expression** can be used to specify what value to match to. You can test your regexp on this [Rubular tool](https://rubular.com/ "Rubular tool").
Currently, only a **single payload field** can be filtered on. So, try to configure your run conditions to filter by Label as much as you can before resorting to filtering by `Payload`.
We will be exploring the possibility of supporting filtering by multiple payload fields in the future.
### Create Incident[](#DW5Rk)
The **Create Incident** action is used to declare an incident in Rootly. Since this action will be referencing alert data, the dynamic fields will be `{{ alert.properties }}`.
Rootly does NOT automatically link alerts to the incident. You'll need to include the following custom mapping in order to link the Jira ticket to the newly declared Rootly incident.
```json theme={null}
{
"jira_issue_id": "{{ alert.data.issue.id }}",
"jira_issue_url": "https://your-jira-instance.atlassian.net/browse/{{alert.data.issue.key}}"
}
```
### Update Incident
The **Update Incident** action is used to update an existing incident in Rootly. Ensure that you set Attribute to Match field to `jira_issue_id` and `Attribute Value` to `{{ alert.data.issue.id }}`. These fields are required for Rootly to know which incident to update.
### Custom Fields Mapping
If you require more dynamic mapping of Rootly incident properties, you can input the following syntax into the `Custom Fields Mapping` field.
Dynamically set Rootly incident **severity**.
```json theme={null}
{
{% if alert.data.issue.fields.priority.name == 'Highest' %}
"severity_id": "SEV0"
{% elsif alert.data.issue.fields.priority.name == 'High' %}
"severity_id": "SEV1"
{% elsif alert.data.issue.fields.priority.name == 'Medium' %}
"severity_id": "SEV2"
{% else %}
"severity_id": "SEV3"
{% endif %}
}
```
Dynamically set Rootly incident **status**.
```json theme={null}
{
{% if alert.data.issue.fields.status.name == '
### Update Jira Issue
The **Update Jira Issue** action is used to update an existing ticket in Jira. In order to update an existing issue in Jira, you must reference it in the `Jira Issue to Update` field using the `{{ incident.jira_issue_id }}` variable.
### Create Jira Subtask
The **Create Jira Subtask** action is used to create a subtask under an existing Jira issue. In order to create a subtask for an existing Jira issue, you must you must reference the original Jira issue in the `Parent Jira Issue` field using the `{{ incident.jira_issue_id }}` variable. The `Project Key` entered here must be the same as the one used in the original Create Jira Issue action.
This workflow action is intended to be used for **action items** or **sub-incidents**.
### Jira Native Field Mapping
#### Labels
Jira has a native field called Labels. The syntax to set this field is different than the one used to set a custom field of the labels type.
```json theme={null}
//Rootly native multi-select to Jira native Labels
"customfield_12345": {{ incident.service_slugs | join: ","}}
//Rootly custom multi-select to Jira native Labels
"customfield_10033": {{ incident.custom_fields | find: 'custom_field.slug', 'your_custom_field_slug' | get: 'selected_options' | map: 'value' | join: "," }}
//Rootly custom labels to Jira labels
//Coming soon!
```
#### Team
Jira has a native field called `Team`, but it's stored as a "custom field". In addition, it only allows a single team to be selected. To map to this field in Jira, you'll need to use the following syntax format:
```json theme={null}
//Format to map to Jira native Team field
{
"customfield_10001": "
#### Custom Fields Mapping
It is highly likely that your Jira projects contain custom fields. The default tab in the above workflow actions will not be sufficient in mapping to these custom fields. You will need to input the custom syntax in the `Custom Fields Mapping` field in the `Advance` configuration tab.
In order to map to custom fields in Jira you would need to know the following information:
* The **custom field id** in Jira
* The **field type** in Jira
* The **incident property** that you would like to map from
## Jira Ticket for Incidents
This section is for configuring the creation of Jira tickets from Rootly.
### Create Jira ticket for all new incidents
This flag will allow Rootly to automatically create a Jira ticket into the specified project as soon as an incident is declared on Rootly.
### Project Key
This field allows you to select which project to create the Jira ticket into. If you need to create Jira tickets to different projects, you can disable this and configure through [workflows](/integrations/jira/rootly-to-jira-sync "workflows").
### Issue Type
This field allows you to select an issue type for your Jira ticket. The options are pulled directly from the project you've specified in the previous `Project Key` field.
### Issue Status
This field allows you to select the status to create the ticket into.The options are pulled directly from the project and issue type you've specified in the previous `Project Key` and `Issue Type` fields.
### Title / Summary
This field allows you to define the `Summary` field of your Jira ticket. By default it is set to `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
### Description
This field allows you to define the Description field of your Jira ticket. By default it is set to `{{ incident.summary }}` to match the summary of your incident. This field supports Liquid syntax.
### Default Assignee
This flag allows you to assign the Jira ticket to someone by providing an email address. If no email address is provided, the ticket will be assigned to the creator of the incident. This field supports Liquid syntax.
### Auto-bookmark Jira ticket in Slack
This flag allows you to enable automatic creation of a bookmark to the Jira ticket in the incident Slack channel. Slack’s channel bookmarks let you save and highlight your most important information in a project, letting you quickly find and interact with key information.
### Update Jira ticket when incident is updated
This flag allows you to enable automatic update of the matching Jira ticket whenever an incident is updated. This is a one-way update, meaning only updates from incidents flow into Jira and not the other way around.
## Jira Ticket For Action Items
This section is for configuring the creation of Jira subtasks for action items created on Rootly.
### Create Jira subtask ticket for action items
This flag will allow Rootly to automatically create a Jira subtask under the parent Jira ticket every time a new action item is created in Rootly.
### Subtask Type
Follow the on-screen prompts to connect to your Linear account. Once you are redirected back to Rootly, click **Save Settings**.
## Configuration
To set up the appropriate Workflows as described in About, please follow: [/integrations/linear/workflows](/integrations/linear/workflows "/integrations/linear/workflows")
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Linear > Configure > Delete**
# Workflows
Source: https://docs.rootly.com/integrations/linear/workflows
Configure Linear workflow actions to create issues and manage project tasks from Rootly incidents.
Fill in the following fields
* **Name** - Create a Linear Issue
* **Team** - Select your corresponding team in Linear you'd like this issue created for
* **State** - Select from Linear states
* **Title** - Name of the Linear issue, using `{{ incident.title }}` will default to the title of the incident
* **Description** - By default your description will be a summary of the incident `{{ incident.summary }}`
* **Priority** - The priority of your Linear issue, select from:
* Auto - This will automatically convert your incident severity to a corresponding Linear severity
## Update a Linear Issue
`https://rootly.com/auth/mattermost/callback`
`https://rootly.com/auth/sign_in_mattermost/callback`
And finally copy `client_id` and `client_secret` into Rootly configuration
## Configuration
Rootly allows you to customize your Mattermost integration. To do so, navigate to the configuration modal (**Configuration** > **Integrations** > **Mattermost** > **Configure**)
You can customize how you want the incident channels to be named, what data to collect on incident creation, etc.
## Connect to Rootly
Click on `Allow` to authortize access.
Now you're ready to manage incidents on Rootly through Mattermost!
## Manage Incidents
### Declaring an Incident
To declare a new incident, use the `/incident new` command. You can make execute this command in any channel.
You'll be prompted on create a new incident.
This will result in an incident being created in Rootly and a designated channel created in Mattermost.
### Mitigating an Incident
To mark an incident as `mitigated`, use the `/incident mitigate` command.
### Resolving an Incident
To mark an incident as resolved, use the `/incident resolve` command.
### List of Commands
If you ever forget what commands are available, you can run `/incident help` to get a reminder of the available commands. As Rootly adds more commands, this list will grow.
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Microsoft Teams
Source: https://docs.rootly.com/integrations/microsoft-teams
Create dedicated channels and tabs for incidents in Microsoft Teams to centralize communication and collaboration.
## Installation in Rootly ( required)
You can setup this integration as a **logged in admin user** in the integrations page.
## Oauth Permissions
Your selected workspace needs the following oauth permissions:
* **offline\_access**
* This permission is needed for to perform OAuth authentication.
* **User.Read**
* Allows Rootly to have user information about who integrated the account. This permission is needed for our OAuth strategy.
* **Team.ReadBasic.All**
* Read the names and descriptions of teams, on behalf of the signed-in user.
* **ChatMessage.Send**
* Allows an app to send channel messages in Microsoft Teams, on behalf of the signed-in user.
* **Channel.Create**
* Create channels in any team, on behalf of the signed-in user.
* **Channel.ReadBasic.All**
* Read channel names and channel descriptions, on behalf of the signed-in user.
* **ChannelMessage.Send**
* Allows an app to send channel messages in Microsoft Teams, on behalf of the signed-in user.
* **ChannelMessage.ReadWrite**
* Allows the app to read and write channel messages, on behalf of the signed-in user.
* **ChannelSettings.ReadWrite.All**
* Add and remove members from channels, on behalf of the signed-in user.
* **ChannelMember.ReadWrite.All**
* Read and write the names, descriptions, and settings of all channels, on behalf of the signed-in user.
* **TeamsTab.ReadWriteSelfForChat**
* Allows a Teams app to read, install, upgrade, and uninstall its own tabs in chats the signed-in user can access.
* **TeamsTab.ReadWriteSelfForTeam**
* Allows a Teams app to read, install, upgrade, and uninstall its own tabs to teams the signed-in user can access.
* **TeamsAppInstallation.ReadWriteSelfForTeam**
* Allows a Teams app to read, install, upgrade, and uninstall itself to teams the signed-in user can access.
## Installation in Microsoft Teams ( required )
1. After authorizing the integration on Rootly, switch to Microsoft Teams. On the left-hand side, go to "+ Apps" search for Rootly in the store and click "Add".
2. On this screen. click the dropdown next to "Add" and choose a primary channel for the Team you'd like to install the bot
1. Click the dropdown next to "Add" and choose "Add to a team." Select a team and a primary channel (we recommend the General channel) to install both the bot and the Rootly tab. Then, click "Set Up." Note: You will need to install the bot for each team that requires access to the Rootly tab for tasks such as creating and managing incidents.
2. After clicking "Set Up," a confirmation modal will appear, guiding you to press "Save" to finalize the app installation. Optionally, you can also post a message to the channel announcing the new Rootly tab.
## Uninstall
1. Login to your **Microsoft Teams** account.
2. Click **Manage > Installed Apps** or search for the **Rootly** App.
3. Click the **Rootly** app.
4. Click **Uninstall**.
# Microsoft Teams Meeting
Source: https://docs.rootly.com/integrations/microsoft-teams-meeting
Create or join Microsoft Teams meetings directly from incidents and get meeting links in notifications.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page.
Create a rootly webhook like shown below with
url: [https://rootly.com/webhooks/incoming/new\_relic\_webhooks](https://rootly.com/webhooks/incoming/new_relic_webhooks "https://rootly.com/webhooks/incoming/new_relic_webhooks"). With Bearer token the token shown in your integration page:
That's how the configuration should look end to end:
## Test
Click `Test Notification` to test your webhook and you should see something similar to the image below in [https://rootly.com/account/alerts](https://rootly.com/account/alerts "https://rootly.com/account/alerts")
All set!
# Installation
Source: https://docs.rootly.com/integrations/new-relic/installation
Capture New Relic dashboard and metrics snapshots through Genius workflows for incident response and analysis.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
Let's now go in New Relic website to enter api keys:
Generate and copy the **Api Key:**
## Snapshot graphs
Now a new task is available in your **Genius workflows:**
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Workflows
Source: https://docs.rootly.com/integrations/notion/workflows
Automate Notion page creation and updates for incident retrospectives using workflows with customizable templates and permissions.
Rootly's Notion integration leverages workflows to automatically generate and update Notion docs and their permissions. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows) documentation first.
## Available Workflow Actions
### Create Notion Page
This action allows you to create an incident retrospective into a Notion page.
| Fields | Description |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Name | This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves. |
| Page | This field allows you to select the parent Notion page in which the retrospective page will be created under. |
| Title | This field allows you to define the title of the Notion page. You can use `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax. |
| Post Mortem Template | This field allows you to use a predefined retrospective template to create the body content of the Notion page. The list of selectable templates can be defined in the [**Retrospective Templates page**](https://rootly.com/account/retrospective-steps?tab=documents). |
| Mark post mortem as published | This field allows you to define the status of the retrospective. A retrospective can be in either a `draft` or `published` status. This is typically used if you have automated notification workflows that are only triggered when the retrospective status is `published`. |
| Show timeline as table | Rootly will include the incident timeline in the retrospective. This allows you to determine if the timeline is rendered in a table or inline.
| Fields | Description |
| :------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves. |
| File | This field references which specific Notion page to update. Leave this field as `{{ incident.notion_page_id }}`. |
| Title | This field allows you to update the title of the Notion page. Leave this field empty to make no changes to the page title. |
| Post Mortem Template | This field allows you to overwrite the existing retrospective with a predefined retrospective template. The list of selectable templates can be defined in the [**Retrospective Templates page**](https://rootly.com/account/retrospective-steps?tab=documents). |
| Show timeline as table | Rootly will include the incident timeline in the retrospective. This allows you to determine if the timeline is rendered in a table or inline.
## Configuration
Log into your Opsgenie account then navigate to Settings > Integrations > New Integration
Select the API integration tile
**Access Rights** needs to be: **Read, Create and Update, Configuration Access**
**Note:** The API Key would need to be a **Global** key and can not be scoped to a Team.
Copy the API integration key back into Rootly
Let's now configure webhooks:
Add webhook as below:
All done !
## Auto Assign On-calls to Incident Roles
If you'd like to automatically assign on-calls of a given Opsgenie Schedule to an Incident Role (e.g. Commander), please follow the instructions on the [PagerDuty integration page](/integrations/pagerduty).
## Paging Automatically via Genius Workflows
Set up automated workflows to page various on-call schedules and escalation policies based on the condition of an incident (e.g SEV1 or greater pages Infrastructure).
## Paging
You can page Opsgenie teams right from Slack using our integration.
# Overview
Source: https://docs.rootly.com/integrations/overview
An integration is either a third-party software service, or custom tooling and software built in-house by your organization that integrates with Rootly to extend the functionality and features of both.
## What's an Integration?
Rootly has dozens of integrations available, including popular SaaS products like [PagerDuty](https://rootly.com/docs/pagerduty-integration "PagerDuty"), [Jira](https://rootly.com/docs/jira-integration "Jira"), [Zoom](https://rootly.com/docs/zoom-integration "Zoom"), [Kubernetes](https://rootly.com/docs/kubernetes-integration "Kubernetes"), and [Github](https://rootly.com/docs/github-integration "Github"). To see all of the integrations currently available when using Rootly, check out the nav bar on the left of this documentation screen.
If you have a custom integration you'd like to create using your own in-house software, see our [API Documentation](https://rootly.com/api "API Documentation") for full information on all the details you'll need to create your own.
## Security
* Integration keys are encrypted at rest using AES 256-bit encryption and protected by TLS in transit.
* Key management is in place for encryption keys for production services
# PagerTree
Source: https://docs.rootly.com/integrations/pager-tree
Integrate Rootly with PagerTree for enhanced incident alerting and notification management using webhook integration.
## Webhooks
[https://pagertree.com/docs/integration-guides/outgoing-webhook](https://pagertree.com/docs/integration-guides/outgoing-webhook)
# Alerts
Source: https://docs.rootly.com/integrations/pagerduty/alerts
Configure Rootly to respond to PagerDuty events and automatically create incidents from PagerDuty alerts.
Select workflow **triggers**. `Alert Created` will be the only option to select here. This means the workflow will initialize whenever a new alert is created in Rootly.
Configure run conditions. Set up your workflow to only run if...
* The alert `source` is from `Pagerduty`
* The alert `labels`:
* **Option 1:** `contains all of` the following `labels` (this is if you want to respond to a new PagerDuty incident being triggered)
* `action:incident.triggered`
* `service_id:PLVWMVW` (this label is optional - only include this if you want to respond to alerts from a specific PagerDuty service)
* **Option 2:** `contains all of` the following `labels` (this is if you want to respond to an existing PagerDuty incident being acknowledged)
* `action:incident.acknowledged`
* `service_id:PLVWMVW` (this label is optional - only include this if you want to respond to alerts from a specific PagerDuty service)
* **Option 3:** `contains all of` the following `labels` (this is if you want to respond to an existing PagerDuty incident being resolved)
* `action:incident.resolved`
* `service_id:PLVWMVW` (this label is optional - only include this if you want to respond to alerts from a specific PagerDuty service)
* **Option 4:** `contains all of` the following `labels` (this is if you want to respond to a responder being added to an existing PagerDuty incident)
* action:incident.responder.added
* The alert `payload` has the `$.object.specific_field` equals to `/specific_value/i`
* **JSON path syntax** is used to filter for a specific field from the alert payload (e.g. \$.issue.fields.issuetype.name). You can preview your syntax on [JSON Path Explorer](https://rootly.com/account/help/json-path-explorer).
* **Ruby regular expression** can be used to specify what value to match to. You can test your regexp on this [Rubular tool](https://rubular.com/).
### Create Incident
The **Create Incident** action is used to declare an incident in Rootly. Since this action will be referencing alert data, the dynamic fields will be `{{ alert.
### Update Incident
The **Update Incident** action is used to update an existing incident in Rootly. Ensure that you set `Attribute to Match` field to `pagerduty_incident_id` and `Attribute Value` to `{{ alert.data.data.id }}`. These fields are required for Rootly to know which incident to update.
### Custom Fields Mapping
If you require more dynamic mapping of Rootly incident properties, you can input the following syntax into the `Custom Fields Mapping` field.
Automatically **log acknowledgement time**.
## Installing PagerDuty on Rootly
Locate **PagerDuty** on the [Integrations catalog](https://rootly.com/account/integrations " Integrations catalog") and select *Setup*.
You'll be **prompted to sign in or create a new PagerDuty account**.
After signing in, you'll be prompted to **grant Rootly permission** to integrate with your PagerDuty account.
Once confirmed, the **installation is complete**!
## Setting Up PagerDuty Webhook[](#_Eh5w)
### Via PagerDuty Web UI[](#MNXlh)
Select **+ New Webhook** to open up the creation form.
Enter the following information into the **New Webhook form**.
**Webhook URL:** `https://webhooks.rootly.com/webhooks/incoming/pagerduty_webhooks`
**Scope Type:** You can select from any of the following 3 options:
* `Service` - Selecting this option will result in only events relating the selected service to be sent to Rootly.
* `Team` - Selecting this option will result in only events relating to the selected team to be sent to Rootly.
* `Account` - Selecting this option will result in events across the entire PagerDuty account to be sent to Rootly.
**Description:** Give your webhook a description. This field is optional.
**Event Subscription:** Select the events you'd like PagerDuty to send to Rootly. We recommend you select all available options.
**Custom Header Name:** `secret`
**Custom Header Value:** `
The Webhook URL is universal across all Rootly accounts. The Secret is unique to each Rootly account.
Once the form is completed, select **Add Webhook**. You'll be prompted with a confirmation message containing a PagerDuty-generated webhook secret. You will not need this value for your Rootly integration. Simply click **OK** to complete setup.
### Via PagerDuty API[](#imU7u)
PagerDuty webhooks can also be set via API ([https://developer.pagerduty.com/api-reference/ec247c8767c6d-create-a-webhook-subscription)](https://developer.pagerduty.com/api-reference/ec247c8767c6d-create-a-webhook-subscription "https://developer.pagerduty.com/api-reference/ec247c8767c6d-create-a-webhook-subscription)").
**URL**: `https://rootly.com/webhooks/incoming/pagerduty_webhooks`
**Header**: `secret: 
# Installation
Please see the [Installation page](/integrations/pagerduty/installation) to get started with your PageDuty integration.
# Smart Defaults
Rootly's PagerDuty integration comes with a set of commonly used default settings. See [Smart Defaults](/integrations/pagerduty/smart-defaults) page for details.
# Workflows
Rootly relies on workflows to automate interactions with PagerDuty. The [Workflows page](/integrations/pagerduty/workflows) will walk you through how to set up commonly used workflows involving PagerDuty.
# Alerts
Rootly can ingest incoming PagerDuty events as alerts to automate auto incident creation and updates. The [Alerts page](/integrations/pagerduty/alerts) will walk you through how to set up
# FAQs
**Q: PagerDuty has some incident management capabilities, how is this different?**
A: When it comes to incident management capabilities, there is some overlap between Rootly and PagerDuty. However, Rootly provides a more complete and centralized incident management platform and [on call solution](https://rootly.com/on-call "on call solution").
**Q: Should I keep paying for PagerDuty or does Rootly replace it?**
A: With the release of Rootly On-Call, Rootly can serve as a wholesale replacement for PagerDuty. [Check out how they compare](https://rootly.com/comparisons/pagerduty-vs-rootly-on-call "Check out how they compare").
*Note: Rootly will continue to support integrated paging solutions like PagerDuty.*
**Q: I don't use PagerDuty, is that okay?**
A: Robust incident management practices generally leverage an on-call provider. Rootly does not require an on-call provider if your use case does not require it.
**Q: I'm getting a** ***Failed to authenticate. Reason: Invalid Credentials*** **message when I try to authenticate my PagerDuty account. What is happening?**
A: Chances are you are trying to authenticate with a Trial PagerDuty account that has expired. Check your PD account to make sure it is still active. If that's not the case, contact us at [support@rootly.com](mailto:support@rootly.com) or start a chat by navigating to **Help > Chat with Us**.
# Smart Defaults
Source: https://docs.rootly.com/integrations/pagerduty/smart-defaults
Simplify PagerDuty integration setup with Smart Defaults that automatically enable incident management without complex workflow configuration.
## Overview
Traditionally, Rootly has strictly relied on [workflow](/integrations/slack/workflows) configurations to automate PagerDuty actions. While it offered the flexibility required to meet complex incident response procedures, it did require some initial effort to set up. Understanding that not all customers adopt super complex procedures, we've introduced Smart Defaults to our PagerDuty integration to help simplify the configuration process.
New customers on Rootly will have Smart Defaults automatically turned on as soon as they install PagerDuty. They will be able to start managing incidents out-of-box.
Existing customers will have Smart Defaults turned off to avoid interrupting the workflows that have already been set up.
To get started with PagerDuty Smart Defaults, you'll want to first navigate to **Integrations > PagerDuty (Configuration).**
## Rootly to PagerDuty
The first section of Smart Defaults covers quicksets for actions going from Rootly to PagerDuty.
### Auto-page on-call responder when an incident is created
This flag allows you to notify on-call responders on PagerDuty when an incident is created in Rootly. The on-call is determined based on the selected PagerDuty Services or Escalation Policy. Any selected Escalation Policy will override the Escalation Policy linked to the selected Service.
The Services and Escalation Policies available in the dropdowns are imported from your PagerDuty workspace.
### Auto-invite on-call responder to new incident Slack channel
This flag allows you to invite on-call responders on PagerDuty to a slack channel when an incident is created in Rootly. The responders are determined based on the selected PagerDuty Services or Escalation Policies. Any selected Escalation Policy will override the Escalation Policy linked to the selected Service.
The Services and Escalation Policies available in the dropdowns are imported from your PagerDuty workspace.
### Auto-resolve PagerDuty incident
This flag allows you to auto resolve the linked PagerDuty incident whenever the Rootly incident is resolved. This is a one-way synchronization only, meaning incident resolutions on Rootly will cause the PagerDuty incident to resolve, but not the other way around. If you are looking to enable the reverse, where resolution on PagerDuty results in incident resolution on Rootly, please see the [PagerDuty > Alerts](/integrations/pagerduty/alerts) page to find out how.
## PagerDuty to Rootly
The second section of Smart Defaults covers quicksets for actions going from PagerDuty to Rootly.
### Send PagerDuty alerts to Rootly
This flag allows you to automatically create alerts in Rootly whenever a PagerDuty event occurs. This process is enabled through webhooks, which are user-defined HTTP callbacks that are triggered by specific events and allow you to automate the sending of PagerDuty events to a destination URL. To complete the setup of this flag, you'll need to configure a webhook in PagerDuty as instructed on the [PagerDuty > Installation](/integrations/pagerduty/installation) page.
### Notify Slack channel of new PagerDuty alerts
This flag allows you to send PagerDuty alert messages to a selected Slack channel from your Slack Workspace. You can test if this integration is set up correctly by clicking on the `Send Test` button.
Rootly refreshes channels on a daily basis. If you don't see your channel in the dropdown, click on the `Refresh channels` button to force a refresh.
If the channel you're attempting to set is a **private channel**, please ensure that the Rootly Slack Bot is added to the channel first. To add the bot to a channel, simply send *@Rootly* as a message in the channel. That will prompt you to add the Rootly Slack Bot to the channel.
### Automatically create incidents in Rootly from PagerDuty alerts
This flag allows you to automatically create corresponding incidents in Rootly whenever a PagerDuty incident is created.
# Workflows
Source: https://docs.rootly.com/integrations/pagerduty/workflows
Configure PagerDuty workflows to automatically create/update incidents and manage on-call assignments in Rootly.
## Overview
Rootly's PagerDuty integration leverages workflows to automatically create/update PagerDuty incidents and invite/assign on-calls to incidents. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows) documentation first.
## Available Workflow Actions
### Page PagerDuty On-Call
This action allows you to page an on-call via PagerDuty. This results in the creation of a PagerDuty incident.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Service
This field is used to specify the PagerDuty service you'd like to page. If you have **imported your PagerDuty services** into Rootly, you can dynamically reference them by selecting the `{{ incident.service }}` option from this dropdown.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Incident Role
This field is used to specify which incident role to assign. Click [here](/managing-teams/incident-roles) to learn more about incident roles.
#### Service
If this field is set, the on-call schedule associated with the selected PagerDuty service will be used to assign the incident role. If you have **imported your PagerDuty services** into Rootly, you can dynamically reference them by selecting the `{{ incident.service }}` option from this dropdown.
The value set in this field will override the escalation policy & schedule selected below.
#### Escalation Policy
This field allows you to specify an existing Escalation Policy from PagerDuty. You do not need to set any value in this field if you'd like the role assignment to follow the default escalation policy for the selected `service`. This field is only used if you'd like the role assignment to follow a different escalation policy from the default that's associated with the service.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Service
If this field is set, the on-call schedule associated with the selected PagerDuty service will be invited to the Slack channels. If you have **imported your PagerDuty services** into Rootly, you can dynamically reference them by selecting the `{{ incident.service }}` option from this dropdown.
The value set in this field will override the escalation policy & schedule selected below.
#### Channels
This field allows you to select one or more Slack channels from your Slack Workspace, where PagerDuty on-call users will be invited to.
You can use `{{ incident.slack_channel_id }}` or `{{ parent_incident.slack_channel_id }}` to specify your incident channel or the parent incident channel, respectively.
#### Escalation Policy
This field allows you to specify an existing escalation policy from PagerDuty. You do not need to set any value in this field if you'd like the invitation to follow the default escalation policy for the selected service. This field is only used if you'd like the invitation to follow a different escalation policy from the default that's associated with the service.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### PagerDuty Incident ID
This field allows you to specify the ID of the PagerDuty incident that you want to update. This field supports Liquid syntax.
Set this field to `{{ incident.pagerduty_incident_id }}` to reference the existing PagerDuty incident that is linked to the Rootly incident.
#### Title
This field allows you to update the title of the PagerDuty incident. This field supports Liquid syntax.
Set this field to `{{ incident.title }}` if you want the PagerDuty incident title to match the title of your Rootly incident.
#### Status
This field allows you to update the status of the PagerDuty incident.
#### Resolution Message
This field allows you to add a resolution message when resolving a PagerDuty incident. This field supports Liquid syntax.
#### Escalation Level
This field allows you to update the escalation level of the PagerDuty incident.
#### Urgency
This field allows you to update the urgency level of the PagerDuty incident.
### Create PagerDuty Status Update
This field allows you to add a message to the Notes section in the PagerDuty incident.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Pagerduty Incident ID
This field allows you to specify the ID of the PagerDuty incident that you want to add a message to. This field supports Liquid syntax.
Set this field to `{{ incident.pagerduty_incident_id }}` to reference the existing PagerDuty incident that is linked to the Rootly incident.
#### Message
This field allows you to set the message to be added to the Notes section of the PagerDuty incident. This field supports Liquid syntax.
Set this field to `{{ incident.events | where: 'kind', 'event' | last | get: 'event' }}` to log the latest event that happened to the Rootly incident.
# Quip
Source: https://docs.rootly.com/integrations/quip
Integrate Rootly with Quip to automatically create postmortem pages for incident documentation and retrospective analysis.
## Why
**Quip** Integration allows you to:
* Create a Quip page postmortem
## Installation
You can setup this integration as a **logged in admin user** in the integrations page
## Create an API KEY
Visit [admin.quip.com](https://admin.quip.com "admin.quip.com") and go to **Settings > Integrations**
Create an API KEY with the following parameters:
* Permissions `USER_READ` and `USER_WRITE`
* Redirect URI: [https://rootly.com/auth/quip/callback](https://rootly.com/auth/quip/callback "https://rootly.com/auth/quip/callback")
Enter Client ID and Client Secret generated into Rootly:
You are all set! Go under workflow to configure your new task!
# Rollbar
Source: https://docs.rootly.com/integrations/rollbar
Connect Rootly with Rollbar for error monitoring and automated incident creation from application errors and exceptions.
## Why
**Rollbar** Integration allows you to:
* Ingest issues as alerts
* Create an incident if alerts > count ( you can specify )
## Installation
As an admin, go to `https://rollbar.com/
Select Webhook
Configure URL you see in Rootly
Configure rules you want to enabled ( We support all of them except deploys ) and you are good to go!
## Alerts
Now everytime a new issue is declared, they will be ingested as alerts as shown below. Use it in workflow with fetch alerts task to automatically linked recent alerts to your incident.
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Sentry
Source: https://docs.rootly.com/integrations/sentry
Connect Rootly with Sentry to ingest error monitoring issues as alerts and automatically create incidents based on configurable thresholds.
## Why
**Sentry** Integration allows you to:
* Ingest issues as alerts
* Create an incident if alerts > count ( you can specify )
## Installation
As an admin, go to [https://sentry.io/orgredirect/settings/:orgslug/sentry-apps/rootly/](https://sentry.io/orgredirect/settings/:orgslug/sentry-apps/rootly/ "https://sentry.io/orgredirect/settings/:orgslug/sentry-apps/rootly/")
Make sure you are logged in as an admin in Rootly and click on the Rootly app.
## Alerts
Create an Sentry alert and select Rootly as destination.
Now your alerts conditions matched, they will be ingested as alerts as shown below. Use it in workflow with fetch alerts task to automatically linked recent alerts to your incident.
[/alert-workflows](/workflows/alert-workflows "/alert-workflows")
**Configure Alert Rules in Sentry:**
* Go to your project in Sentry.
* Navigate to **Alerts** > **Rules**.
* Create a new alert rule or edit an existing one.
* Set the conditions that should trigger an alert (e.g., when a new issue is created or an error frequency increases).
* In the **Actions** section, select **Send a notification via the Rootly integration**.
* Save the alert rule.
**Set Up Alert Workflows in Rootly:**
* In Rootly, navigate to **Workflows** > **Create Workflow**.
* Choose the **Alert** workflow type.
* **Trigger Event:** Select **Alert Created**.
* **Run Conditions:** Define conditions to filter alerts from Sentry, such as:
* **Source:** Set to **Sentry**.
* **Labels:** Specify any relevant labels.
* **Payload:** Use JSON Path to filter specific fields if necessary.
* **Actions:** Add the **Create Incident** action to automatically declare an incident in Rootly when the workflow conditions are met.
* Save the workflow.
**Test the Integration:**
* Trigger an alert in Sentry that meets the conditions you've set.
* Verify that an incident is automatically created in Rootly as configured.
By following these steps, Sentry alerts will seamlessly initiate incidents in Rootly, ensuring prompt attention to critical issues.
[https://docs.sentry.io/organization/integrations/notification-incidents/rootly/](https://docs.sentry.io/organization/integrations/notification-incidents/rootly/ "https://docs.sentry.io/organization/integrations/notification-incidents/rootly/")
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# SharePoint
Source: https://docs.rootly.com/integrations/sharepoint
Integrate Rootly with Microsoft SharePoint for document management and collaboration during incident response.
You'll be presented with the following installation page. Double check that you're installing the correct workspace (dropdown in the upper right hand corner) before you confirm the installation by selecting `Allow`.
## Installing Slack Enterprise Grid on Rootly
## Notifications
There are two categories of settings you can set up Smart Defaults for. The first one being **notifications**.
### Team Notifications
Team notifications will help notify Slack *users*, *groups*, and/or *channels* of new incidents and alerts.
#### Set up a default announcement channel
This flag will allow you to announce every new incident in a specified channel. The available channels are pulled from the workspace specified above.
### Smart Reminder
Smart reminders will send out reminder messages in the specific incident channel when the conditions are met.
#### Reminder if incident role is unassigned
This flag allows you to notify the incident channel if no incident roles are assigned for x amount of time. It is important to assign incident roles to ensure ownership of the incident.
#### Reminder to cancel incident in Triage state
This flag allows you to notify the incident channel if the incident remains in the Triage state for x amount of time. Issues should be triaged as soon as they are detected to ensure prompt response. Click [here](/incidents/incidents) to learn more about different states of an incident.
#### Reminder if incident is inactive
This flag allows you to notify the incident channel if the incident remains inactive for x amount of time. Incident activity is tracked by interactions with the Rootly Slack Bot within the specific incident channel. For example:
* Sending a message in the incident channel does NOT count as an activity as it does not interact with the Rootly Slack Bot
* Setting the incident `summary` DOES count as an activity as it instructs the Rootly Slack Bot to update the incident properties.
* Using the 📌 emoji to log a message in the incident timeline DOES count as an activity as it instructs the Rootly Slack Bot to update the incident timeline.
#### Reminder if incident summary is empty
This flag allows you to notify the incident channel if the incident `summary` field is left empty for x amount of time. It is important to update the incident summary so subscribers added to the incident knows where the incident currently stands.
#### Reminder to update status page
This flag allows you to notify the incident channel every x amount of time to remind users to update the status page. It is good practice to keep status pages up-to-date so your audience knows the status of certain incidents or services.
#### Reminder to leave feedback
This flag allows you to notify the incident channel to log feedback once the incident is resolved. The feedback collected is to help your incident management team identify any opportunities for procedure improvement.
### Updates
Updates will send out notification messages in the specific incident channel when the incident properties change.
#### Notify incident Slack channel when incident status is updated
This flag allows you to notify the incident channel whenever the incident `status` changes.
#### Notify incident Slack channel when Status Page is updated
This flag allows you to notify the incident channel whenever a publication is made to a status page for the specific incident.
#### Pin added event to Slack channel
🚧 **Under Construction** 🚧
### Advanced settings
Some additional settings can be applied to the notifications so you can further customize the way your team is notified.
#### Broadcast incident events to channel
This flag allows you to announce each timeline update as a broadcasted message. Timeline updates are threaded messages by default. Although it keeps the channel quiet, it has a higher potential to get missed. By broadcasting each update, the incident channel will light up to notify users of a new update.
#### Mention and tag @user in incident Slack channel
This flag allows you to tag each user that is mentioned by Rootly on each timeline update. Teams often like to keep this flag turned off to avoid notification fatigue.
## Incident Channel
The second category of settings you can set up Smart Defaults for is **incident channel** settings.
### Incident Slack Channel
Incident Slack channel settings will determine how each incident Slack channel will behave in response to an incident.
#### Create incident channel for new incident
This flag allows you to automatically create an incident Slack channel for each new incident declared on Rootly. We highly recommend that you create a designated channel for each declared incident. Working through incidents via a single thread is highly inefficient and difficult to track.
#### Channel naming convention
This setting allows you to select from a list of channel naming formats.
#### Emoji Shortcuts
Rootly supports the following emoji-triggered actions:
* Adding a Slack message to the incident timeline
* Creating a follow-up
* Creating a task
Each action can be triggered by one or more emojis. Please select emojis that are not commonly used in day-to-day Slack conversations (e.g. 👍, 😄, etc.) to avoid mistriggers.
### Archive Channels
Archive channels settings will allow you to define when each incident Slack channel is archived.
#### Auto-archive incident channel
This flag allows you to auto archive an incident channel once the incident resolves. Archiving dormant channels is highly recommended to keep your workspace clean and clutter-free. You might want to set the duration to 1-2 days to allow your team time to clean up any content in the channel before archiving it.
#### Auto-archive tutorial and test
This flag allows you to auto archive any `test` or `tutorial` incidents created during gamedays, trial runs, or learning sessions after 24 hours from creation.
### Members
Members settings are miscellaneous flags relating to how your Slack users are handled by Rootly.
#### Require Rootly users to connect Slack accounts
This flag enforces that each member in your Rootly organization must go through the initial step of establishing a connection with their Slack account. In the rare case where users don't need to use Rootly via Slack, you can turn off this flag to allow them to skip the connection step.
#### Track users joining incident Slack channel
This flag allows you to log any user that joins an incident Slack channel as part of the incident timeline. Turn this flag off to reduce your incident timeline to only incident events.
#### Track users leaving incident Slack channel
This flag allows you to log any user that leaves an incident Slack channel as part of the incident timeline. Turn this flag off to reduce your incident timeline to only incident events.
# Add Slack Bookmark
Source: https://docs.rootly.com/integrations/slack/workflows/add-slack-bookmark
## Description
This action adds a bookmark to a specified Slack channel. Bookmarks are particularly useful for keeping track of important links. Links that are bookmarked will appear at the top of your channels.
## Action Attributes
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Channel
This field specifies which Slack channel to add the bookmark in.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will set the bookmark in the Slack channel of the triggering incident.
* The Liquid snytax `{{ parent_incident.slack_channel_id }}` can be used for sub incidents and it will set the bookmark in the Slack channel of the parent incident.
* You can also set the bookmark in other static channel (e.g. `#gernal`, `#alerts`)
### Playbook
Selecting a playbook in this field will attach the link to the playbook as a bookmark in the sepecified channel.
### Title
This field will be the text that gets displayed in the bookmarkbar of the Slack channel.
### Link
Use this field to specfify the URL for the bookmark. You can either input a hardcoded link or use Liquid variables to dynanmically set a link.
Some common examples:
* `{{ incident.url }}`
* `{{ incident.jira_issue_url }}`
* `{{ incident.pagerduty_incident_url }}`
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Channel
This field specifies which Slack channel to archive.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will archive the Slack channel of the triggering incident.
* The Liquid syntax `{{ parent_incident.slack_channel_id }}` can be for sub incidents and it will archive the Slack channel of the parent incident.
* You can also archive static channel (e.g. `#general`, `#alerts`)
# Create Slack Channel
Source: https://docs.rootly.com/integrations/slack/workflows/create-slack-channel
## Description
This action creates a designated Slack channel for an incident. Responding to each incident in their designated Slack channel can greatly help teams keep things organized.
## Action Attributes
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Workspace
Select the workspace from the dropdown. The channel will be created into the specified workspace.
### Title
Speicify a title for the incident channel. This field accepts [Liquid variables](/liquid/incident-variables) to allow you to dynamically name the Slack channel.
**Example**
Setting the field to `incident-{{ incident.created_at | date: '%Y%m%d' }}-{{ incident.title }}` will create a Slack channel with the name `#incident-20231119-
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Channel
This field specifies which Slack channel to invite the user(s)/user group(s) to.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will invite the user(s)/user group(s) to the Slack channel of the triggering incident.
* The Liquid snytax `{{ parent_incident.slack_channel_id }}` can be used for sub incidents and it will invite the user(s)/user group(s) to the Slack channel of the parent incident.
* You can also invite user(s)/user group(s) to static channel (e.g. `#gernal`, `#alerts`)
### Slack Users
This field sets the user(s) you wish to invite to the specified channel. User(s) can either be hard-coded to specific persons within your team or set dynamically via Liquid variables. For example, you can use the snytax `{{ incident.creator }}` to invite the person who originally declared the incident.
Slack User Groups
This field sets the Slack user group(s) you wish to invite to the specified channel. All users part of the specified user group will be invited. You can read more about Slack user groups [here](https://slack.com/help/articles/212906697-Create-a-user-group).
# Overview
Source: https://docs.rootly.com/integrations/slack/workflows/overview
Our Slack integration unlocks powerful workflows actions that you can leverage to streamline your incident management process. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows) documentation first.
## Available Workflow Actions
* [Add Slack Bookmark](/integrations/slack/workflows/add-slack-bookmark)
* [Archive Slack Channel](/integrations/slack/workflows/archive-slack-channel)
* [Create Slack Channel](/integrations/slack/workflows/create-slack-channel)
* [Invite to Slack Channel](/integrations/slack/workflows/invite-to-slack-channel)
* [Rename Slack Channel](/integrations/slack/workflows/rename-slack-channel)
* [Send Slack Blocks](/integrations/slack/workflows/send-slack-blocks)
* [Send Slack Message](/integrations/slack/workflows/send-slack-message)
* [Send Slack Reminder](/integrations/slack/workflows/send-slack-reminder)
* [Update Channel Topic](/integrations/slack/workflows/update-slack-channel-topic)
# Rename Slack Channel
Source: https://docs.rootly.com/integrations/slack/workflows/rename-slack-channel
## Description
This action renames the specified channel. This is particularly useful for teams that wish to keep the Slack channel name in-sync with the incident title, issue ticket number, etc.
## Action Attributes
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behave.
### Channel
This field specifies which Slack channel to rename.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will rename the Slack channel of the triggering incident.
* The Liquid snytax `{{ parent_incident.slack_channel_id }}` can be used for sub incidents and it will rename the Slack channel of the parent incident.
### New Title
Speicify a new title for the incident channel. This field accepts [Liquid variables](/liquid/incident-variables) to allow you to dynamically rename the Slack channel.
For example, if this action is taken after the incident title changes; setting the field to `incident-{{ incident.started_at | date: '%Y%m%d' }}-{{ incident.title }}` will rename the Slack channel to match the updated incident title. It will still maintain the `#incident-20231119-
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Slack Users
Specify the Slack user(s) you wish to send the custom Slack block to.
### Slack User Groups
Specify which Slack user group(s) you wish to send the custom Slack block to. All users part of the specified user group(s) will be sent the block. You can read more about Slack user groups [here](https://slack.com/help/articles/212906697-Create-a-user-group).
### Channels
This field specifies which Slack channels to send the Slack block to.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will send the block to the Slack channel of the triggering incident.
* The Liquid snytax `{{ parent_incident.slack_channel_id }}` can be used for sub incidents and it will send the block to the Slack channel of the parent incident.
* You can also send blocks to static channel (e.g. `#gernal`, `#alerts`)
### Send as Ephemeral
If selected, your message will be sent as a **hidden** message visible only to the specified users.
A value must be set for the `Slack Users` or `Slack User Groups` and `Channels` when this field is selected. Additionally, the selected users need to be in the specified channels.
### Pin to Channel
If selected, your message will pinned to the specified channel(s).
### Message Threading Options
If you want to thread the block under an existing block/message that Rootly has previously sent, you can do so by selecting a parent block/message to be threaded under.
#### Filter Tasks by Workflow
This field is used to filter for the workflow that contains the specific action responsible for sending the parent message. The value in this field will not persist once the workflow is saved, as the `Select a Task` field is what ultimately determines the parent message to thread under.
#### Select a Task
This field is used to select the specific action that's responsible for sending the parent block/message. This field determines which block/message is the parent block/message to thread under.
#### Update Parent Message
If this field is selected, the workflow will update the original parent block/message, instead of threading underneath it.
#### Broadcast Thread Reply to Channel
If this field is selected, the threaded block will also be broadcased as a new block in the specified channels.
### Notification Preview
Content in this field will be displayed in the push notifications. This field supports [Liquid variables](/liquid/incident-variables).
### Blocks
The blocks field consist of the payload that will be send in Slack. Customizing this payload will allow you to build custom messaging. The payload follows the same restrictions as Slack's block elements do. You can preview and check if your payload is valid by clicking the `Preview` button. This button will route you to [Slack's Block Kit builder](https://app.slack.com/block-kit-builder/).
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Slack Users
Specify the Slack user(s) you wish to send the custom Slack message to.
### Slack User Groups
Specify which Slack user group(s) you wish to send the custom Slack mesage to. All users part of the specified user group will be sent the message. You can read more about Slack user groups [here](https://slack.com/help/articles/212906697-Create-a-user-group "here").
### Channels
This field specifies which Slack channel(s) to send the Slack message to.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will send the message to the Slack channel of the triggering incident.
* The Liquid syntax `{{ parent_incident.slack_channel_id }}` can be used for sub incidents and it will send the message to the Slack channel of the parent incident.
* You can also send messages to static channel (e.g. `#gernal`, `#alerts`)
### Actions
Slack messages can also be sent with buttons that are linked to actions. The current available actions are listed below.
| Action | Description |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Update Summary` | Surfaces a Slack modal that allows you to update the incident's summary. |
| `Manage Incident Roles` | Surfaces a Slack modal that allows you to manage your incident's role assignments. |
| `Update Incident` | Surfaces a Slack modal that allows you to edit your incident's attributes. |
| `All Commands` | Surfaces the help toolbar. |
| `Leave Feedback` | Surfaces a Slack modal for incident feedback. |
| `Manage Custom Fields` | Surfaces a Slack modal for managing your custom fields. |
| `Manage Action Items` | Surfaces a checklist for managing the incident's action items. |
| `View Tasks` | Surfaces a checklist for managing action items assigned to your user. |
| `Add Pagerduty Responders` | Escalation modal for adding [PagerDuty responders](/integrations/pagerduty). This action requires that the PagerDuty integration is already set up for your team. |
| `Add Opsgenie Responders` | Escalation modal for adding [Opsgenie responders](/integrations/opsgenie). This action requires that the Opsgenie integration is already set up for your team. |
| `Add Victor Ops Responders` | Escalation modal for adding [VictorOps responders](/integrations/victor-ops). This action requires that the VictorOps integration is already set up for your team. |
### Text
This field contains sets content of the message you wish to send. [Incident variables](/liquid/incident-variables), [Liquid syntax](https://shopify.github.io/liquid/ "Liquid syntax"), and [Slack markdown](https://api.slack.com/reference/surfaces/formatting "Slack markdown") are all supported in this field.
### Message Threading Options
If you want to thread the message under an existing block/message that Rootly has sent, you can do so by selecting a parent block/message to be threaded under.
#### Filter Tasks by Workflow
This field is used to filter for the workflow contains the specific action responsible for sending the parent message. The value in this field will not persist once the workflow is saved, as the `Select a Task` field is what ultimately determines the parent message to thread under.
#### Select a Task
This field is used to select the specific action that's responsible for sending the parent message. This field determines which message is the parent message to thread under.
#### Update Parent Message
If this field is selected, the workflow will update the original parent message, instead of thready underneath it.
#### Broadcast Thread Reply to Channel
If this field is selected, the threaded message will also be broadcased as a new message in the specified channels.
### Send as Ephemeral
If selected, your message will be sent as a **hidden** message visible only to the specified users.
A value must be set for the `Slack Users` or `Slack User Groups` and `Channels` when this field is selected. Additionally, the selected users need to be in the specified channels.
### Pin to Channel
If selected, your message will pinned to the specified channels.
# Send Slack Reminder
Source: https://docs.rootly.com/integrations/slack/workflows/send-slack-reminder
## Description
This action sends a message to Slack channels, users, and user groups.
## Action Attributes
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Slack Users
Specify the Slack users you wish to send the custom Slack reminder to.
### Slack User Groups
Specify which Slack user groups you wish to send the custom Slack reminder to. All users part of the specified user group will be sent the message. You can read more about Slack user groups [here](https://slack.com/help/articles/212906697-Create-a-user-group "here").
### Channels
This field specifies which Slack channels to send the Slack reminder to.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will send the reminder to the Slack channel of the triggering incident.
* The Liquid snytax `{{ parent_incident.slack_channel_id }}` can be used for sub incidents and it will send the reminder to the Slack channel of the parent incident.
* You can also send reminders to static channel (e.g. `#gernal`, `#alerts`)
### Actions
## Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
## Channels
This field specifies which Slack channels to update the topic for.
Some common selections:
* Setting to `{{ incident.slack_channel_id }}` will update topic for the Slack channel of the triggering incident.
* The Liquid snytax `{{ parent_incident.slack_channel_id }}` can be used for sub incidents and it will update the topic for the Slack channel of the parent incident.
* You can also update topics for static channel (e.g. #gernal, #alerts)
## Topic
This field defines what the topic will be. [Incident variables](/configuration/incident-types), [Liquid syntax](https://shopify.github.io/liquid/ "Liquid syntax"), and [Slack markdown](https://api.slack.com/reference/surfaces/formatting "Slack markdown") are all supported in this field.
# Splunk
Source: https://docs.rootly.com/integrations/splunk
Install the Rootly Splunk app to forward alerts and trigger on-call notifications through custom alert actions.
## Splunk App
[https://splunkbase.splunk.com/app/7721](https://splunkbase.splunk.com/app/7721 "https://splunkbase.splunk.com/app/7721")
### App Description
The purpose of this app is to setup custom alert actions that forward to Rootly
### Installation Instructions
* Install via the Splunk Web Admin
* Configure using the full integration url or the integration key supplied after adding the splunk service in the Rootly Admin.
### Dependencies
N/A
### Where to install
The app needs to be installed on the search heads.
### Features
Easily integrates with Rootly's event API to handle oncall alert triggers.
# VictorOps (Splunk On-Call)
Source: https://docs.rootly.com/integrations/victor-ops
Connect Rootly with VictorOps (Splunk On-Call) to import teams, create alerts, and synchronize incident management workflows.
## Why
**VictorOps** Integration allows you to:
* Import **VictorOps** teams into Rootly teams.
* **Create** a Rootly alert when creating an incident in **VictorOps**.
* **Create** a VictorOps incident when creating an incident in Rootly.
* **Resolve** a VictorOps incident right from Rootly.
* Page Directly from Slack ( if Slack Integration enabled ).
**Note:** This integration required an VictorOps account with at least the **Enterprise** plan. [https://portal.victorops.com/dash/rootly-inc#/billing](https://portal.victorops.com/dash/rootly-inc#/billing)
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
You can also optionally configure webhooks so we ingest VictorOps incidents as Rootly alerts.
Copy the url above and create a webhook:
## Paging
You can page VictorOps teams right from Slack using our integration.
# Airtable
Source: https://docs.rootly.com/integrations/airtable
Connect Rootly with Airtable to automatically create records when incidents are declared, enabling seamless data integration and tracking.
## Why
**Airtable** Integration allows you to:
* Creating an incident in **Rootly** will create a record in a **Airtable** table of your choice if you choose to.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
Create an Oauth Application at [https://airtable.com/create/oauth](https://airtable.com/create/oauth "https://airtable.com/create/oauth")
With as callback url: `https://rootly.com/auth/airtable/callback`
## Permissions
Check the following scopes:
## Settings
Copy your `client_id` and `client_secret` into rootly
## Fields mapping[](#7z98s)
You can configure column mapping using our custom variables [Incident Variables](/liquid/incident-variables).
```json theme={null}
{
"Name": "{{incident.title}}",
"Notes": "{{incident.summary}}",
"Started At": "{{incident.started_at | date: '%FT%T%:z' }}",
"Link": "{{incident.url}}"
}
```
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Anthropic
Source: https://docs.rootly.com/integrations/anthropic
Connect Rootly with Anthropic Claude to enhance incident management with AI-powered assistance
# Anthropic Integration
## Overview
The Anthropic integration will allow you to leverage Claude's capabilities for incident management, including automated response generation, incident analysis, and intelligent recommendations.
## Features
* AI-powered incident analysis
* Automated response suggestions
* Intelligent incident classification
* Enhanced communication templates
## Setup
Documentation for setting up the Anthropic integration will be available soon.
## Configuration
Configuration details will be provided in an upcoming release.
***
Stay tuned for more information about this integration.
# AWS Elastic Beanstalk
Source: https://docs.rootly.com/integrations/aws-elastic-beanstalk
Deploy Rootly configurations to AWS Elastic Beanstalk environments using .ebextensions configuration files.
## Installation
* Create a `.ebextensions/rootly.config` file. (The name does not have to be 'rootly'.)
* Put this content into the file (Adapt for your use case)
```Shell Shell theme={null}
files:
"/opt/elasticbeanstalk/hooks/appdeploy/pre/01rootly.sh" :
mode: "000775"
owner: root
group: users
content: |
#!/bin/bash
rootly_api_key="$(/opt/elasticbeanstalk/bin/get-config container -k rootly_api_key)";
environment="$(/opt/elasticbeanstalk/bin/get-config container -k environment)";
service="$(/opt/elasticbeanstalk/bin/get-config container -k service)";
labels="key=value,key2=value2"
# install rootly cli
curl -fsSL https://raw.githubusercontent.com/rootly-io/cli/main/install.sh | sh
# log a pulse
rootly pulse --api-key "${rootly_api_key}" --quiet --environments "${environment}" --services "${service}" --labels "${labels}" Deploy in progress...
```
# Backstage
Source: https://docs.rootly.com/integrations/backstage/installation
Integrate Rootly with Spotify's Backstage developer portal to enhance service catalog management and incident response.
## Rootly plugin for Backstage
Cf. [https://github.com/rootlyhq/backstage-plugin](https://github.com/rootlyhq/backstage-plugin "https://github.com/rootlyhq/backstage-plugin")
# Coda
Source: https://docs.rootly.com/integrations/coda/coda
Streamline incident retrospectives with Coda integration, featuring pre-built templates and automated workflow creation.
## Overview
Rootly's Coda integration helps streamline the process of completing incident retrospectives. By leveraging pre-built templates and workflows, teams can automate their retrospective creation - saving hours of manual work, per incident.
Some key features of this integration includes:
1. **Customizable templates**
* Rootly enables teams to pre-define retrospective templates in both Rootly and Coda. If you're looking for a semi-custom retrospective that follows industry best practices, you can simply define the retrospective body in Rootly and we will take care of the rest. If you want a fully customized retrospective, you can build your template in Coda and we will generate the retrospective accordingly.
2. **Liquid variable support**
* Liquid variables can be referenced in both templates created in Rootly or Coda.
3. **Timeline Visualization:**
* Incident timelines are automatically generated for templates created in Rootly.
* [Custom Liquid syntax](/liquid/incident-variables) can be used to generate timelines for templates created in Coda
4. **Action Item Tracking:**
* Follow-ups are automatically recorded when Rootly-hosted templates are used.
* [Custom Liquid syntax](/liquid/incident-variables "Custom Liquid syntax") can be used to list out follow-ups in templates hosted on Coda.
## Installation
Please see the [**Installation** page](/integrations/coda/installation "Installation") to get started with your Coda integration.
## Workflows
Rootly relies on workflows to automate interactions with Coda. The [**Workflows** page](/integrations/coda/workflows "Workflows") will walk you through how to set up commonly used workflows involving Coda.
# Installation
Source: https://docs.rootly.com/integrations/coda/installation
Install and set up the Coda integration with Rootly to automate retrospective creation and document management.
## Installing Coda on Rootly
You'll be prompted to enter your Coda API Key
# Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete.**
# Workflows
Source: https://docs.rootly.com/integrations/coda/workflows
Configure Coda workflows to automatically generate retrospective pages and manage document creation from Rootly incidents.
## Overview
Our Coda integration leverages workflows to automatically generate retrospective pages in Coda. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows "Workflows") documentation first.
## Available Workflow Actions
### Create a Coda Page
This action allows you to create an incident retrospective into a Coda Doc.
#### Title
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Subtitle
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Page ID
This field allows you to enter the Coda `Page ID` under which the retrospective will be created. The Page ID can be found in the URL when viewing a specific page in your Coda doc.
#### Title
This field allows you to define the title of the Coda page. You can use `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
#### Doc ID
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Page ID
This field allows you to enter the Coda `Page ID` under which the retrospective will be created. The Page ID can be found in the URL when viewing a specific page in your Coda doc.
#### Title
This field allows you to define the title of the Coda page. You can use `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
#### Subtitle
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
## Create an incident
Now you should have a generated **email alias** tied to your team.
Let's send our email!
## Specify a severity
Rootly will **automatically detect** the incident **severity** in the mail **subject** and map accordingly:
For example:
* *\[SEV0] Shopping cart is showing empty items* **will be mapped** to severity **SEV0** (if exist in your configuration).
* *\[SEV1] Shopping cart is showing empty items* **will be mapped** to severity **SEV1** (if exist in your configuration).
* *Shopping cart is showing empty items \[SEV0]* **will be mapped** to severity **SEV0** (if exist in your configuration).
* *Shopping cart is showing empty items, this is a sev1* **will be mapped** to severity **SEV1** (if exist in your configuration).
* *Shopping cart is showing empty items* **won't be mapped** to any severity.
## Add emails to the timeline
You can respond to an incident email and we will add it to your timeline for you !
# Fivetran
Source: https://docs.rootly.com/integrations/fivetran
Connect Rootly with Fivetran to automatically sync incident data to your data warehouse for advanced analytics and reporting.
Fivetran is a no-code data movement platform that allows you to automatically transform data and then send it to your data warehouse.
Rootly provides plenty of built-in, customizable metrics right in the web platform, but if you want to dive even deeper into the data, the Fivetran integration will pull your Rootly data right into your centralized data location.
### Use Cases
With Rootly data synced to your data warehouse, you can:
* Build custom dashboards and visualizations in your BI tool of choice
* Analyze incident trends over time and identify patterns
* Combine Rootly incident data with other business metrics
* Create executive reports on MTTR, incident frequency, and team performance
* Perform advanced analytics and forecasting on incident data
### Synced Data Tables
Fivetran syncs these data tables from Rootly:
* **Audit** - Audit logs and history
* **Cause** - Incident root causes
* **Form fields** - Custom form field data
* **Incidents** - Core incident information
* **Roles** - User roles and assignments
* **Workflows** - Workflow definitions and runs
### Requirements
* Fivetran account with a configured destination (data warehouse)
* Rootly admin or owner access (required to generate API keys)
### Installation
To set up the integration:
1. Ensure you have a destination configured in Fivetran (e.g., Snowflake, BigQuery, Redshift)
2. Generate a Rootly API key from **Organization Settings > API Keys**
3. In Fivetran, create a new Rootly connector
4. Enter your destination schema name and Rootly API key
5. Click **Save & Test** to begin syncing
Fivetran will perform an initial sync and then sync data on a regular schedule according to your connector settings.
### Additional Resources
* [Fivetran's Rootly setup guide](https://fivetran.com/docs/connectors/applications/rootly/setup-guide) - Detailed configuration instructions
* [Fivetran's Rootly API configuration](https://fivetran.com/docs/connectors/applications/rootly/api-configuration) - API setup details
* [Rootly connector ERD](https://fivetran.com/connector-erd/rootly) - Database schema and relationships
### Notes
* Sync frequency is managed by Fivetran and depends on your Fivetran plan
* Historical data will be synced during the initial connector setup
* Ensure your data warehouse has sufficient storage for the synced data
# Functionalities
Source: https://docs.rootly.com/integrations/github/functionalities
## Attaching PRs to Incidents
Rootly will automatically detect a PR link and attach it to the incident when an engineer sends the URL in Slack. As the PR is approved and merged, Rootly will automatically communicate the status update in Slack and add an event to the incident's timeline.
## Fetch recent commits
Now a new task is available in your **Genius workflows:**
## Pulses
Rootly will automatically add the following GitHub events as pulses:
* Push to any repositories
* Merged pull requests
* More to come...
## About GitHub secret scanning
GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.
GitHub partnered with [Rootly](https://rootly.com/ "Rootly") to scan for our tokens and help secure our mutual users on public repositories. Rootly tokens allow users to authenticate against our API to create incidents programmatically for example. GitHub will forward access tokens found in public repositories to Rootly who will notify workspace owners and let them revoke tokens within few a seconds.
GitHub Advanced Security customers can also scan for Rootly tokens and block them from entering their private and public repositories with [push protection](https://github.blog/changelog/2022-04-04-secret-scanning-prevents-secret-leaks-with-protection-on-push/ "push protection").
* [Learn more about secret scanning](https://docs.github.com/en/github/administering-a-repository/about-secret-scanning "Learn more about secret scanning")
* [Partner with GitHub on secret scanning](https://docs.github.com/en/developers/overview/secret-scanning/ "Partner with GitHub on secret scanning")
# GitHub
Source: https://docs.rootly.com/integrations/github/github
Track deployments, create issues, fetch commits, and enrich PR links with automatic status tracking for incident management.
**GitHub** Integration allows you to:
* Fetch recent GitHub commits through workflows.
* Create and update GitHub issues for incidents and action items
* Track code deployment events such as pull requests, approvals, commits, etc. in Pulses.
* Enrich GitHub PR links you copy into your incident Slack channel and track PR statuses.
## Permissions
The following permissions are required for this integration:
* **READ** access to checks, code, deployments, metadata, and pull requests.
* **READ** and **WRITE** access to issues.
## Installation
Click on the `GitHub Marketplace` button.
2️⃣ Search for "*rootly*" and click on the **Rootly** app.
Go ahead and click on the `Add` button to begin the installation process.
3️⃣ If you're in multiple GitHub organizations, make sure you **select the correct organization** and then click `Install it for free`.
Double check that you've **selected the correct organization**. Check the `Allow my billing information to be linked with this organization` and click `Save`.
When ready, click on `Complete order and begin installation`.
4️⃣ Select the desired **scope of access** and click `Install`.
5️⃣ Log out of your GitHub account. We will need to re-establish a connection from Rootly in the next step.
6️⃣ Now, let's switch to your Rootly account to complete the installation. Navigate to the **Integrations** page in Rootly via this [link](https://rootly.com/account/integrations "link") and search for "*github*".
7️⃣ You'll be prompted to sign in to GitHub to establish a connection to the correct GitHub organization.
8️⃣ Click on the `Save` button and you're all set!
## Uninstall
If you wish to uninstall the integration, make sure that not only GitHub is uninstalled from Rootly, but rootlyhq app is uninstalled in your GitHub account as well.
1️⃣ `Delete` GitHub integration from Rootly by navigating to the GitHub integration modal on the **Integrations** page in Rootly.
2️⃣ `Uninstall` the **rootlyhq** app from your organization's **GitHub Apps** page.
# GitLab
Source: https://docs.rootly.com/integrations/gitlab
Integrate GitLab with Rootly to fetch recent commits, track pulse events, and enrich PR links in incident channels.
## Why
**GitLab** Integration allows you to:
* Fetch recent **GitLab** commits through **Genius** Workflows
* Track pulses events
* Enrich GitLab PR links you copy into your incident Slack channel and track PR statuses.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
Let's create an OAuth2 application:
Enter the following information:
* **redirect\_uri**: [https://rootly.com/auth/gitlab/callback](https://rootly.com/auth/gitlab/callback)
* **scopes**: `api` or `read_api`
Copy **Application ID** and **secret** into Rootly:
And you are all set!
## Fetch recent commits
Now a new task is available in your **Genius workflows:**
### Pulses
Rootly will automatically add the following Gitlab events as pulses:
* Push to any repositories
* Merged pull requests
* More to come...
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Glean
Source: https://docs.rootly.com/integrations/glean
A Python integration that syncs Rootly incident management data with Glean for unified search and discovery.
## **Overview**
This [project](https://github.com/rootlyhq/rootly-glean-connector) creates a seamless connection between Rootly and Glean, enabling users to search for:
* **Incidents** - Active and resolved incidents with severity, status, and timeline data
* **Alerts** - Alert configurations and monitoring rules
* **Schedules** - On-call schedules with rotations, shifts, and user assignments
* **Escalation Policies** - Links to escalation rules and notification chains
* **Retrospectives** - Links to post-incident analysis
## **Quick Start**
## **Requirements**
* **Python 3.13+**
```
# macOS (using Homebrew)
brew install python@3.13
```
1. **Clone and setup environment:**
```
git clone https://github.com/rootlyhq/rootly-glean-connector.git
cd rootly-glean-connector
python -m venv venv
source venv/bin/activate
```
2. **Install dependencies:**
```
pip install -r requirements.txt
```
3. **Get secrets file:** Create a `secrets.env` file containing:
```
GLEAN_API_TOKEN=your_glean_api_token_here
ROOTLY_API_TOKEN=your_rootly_api_token_here
```
4. **Run the integration:**
```
python app.py
```
## **Configuration**
Edit `config.json` to customize:
* **Glean API host** - Update `glean.api_host` to match your Glean server (default: `support-lab-be.glean.com`)
* Data type settings (enable/disable incidents, alerts, schedules, escalation policies, retrospectives)
* Item limits and pagination per data type
* Enhanced incident features (timeline events, action items)
* Logging levels and sync intervals
Configuration files:
* `config.json` - Contains non-sensitive configuration settings
* `secrets.env` - Contains API tokens
## **Architecture**
* **data\_fetchers/**: API clients for each Rootly data type
* **document\_mappers/**: Convert Rootly data to Glean document format
* **processors/**: Sync coordination and orchestration
* **glean\_schema/**: Glean document definitions
## **Glean Search Examples**
Once synced, search for Rootly data in Glean:
### **Incidents**
* `"Find incidents with timeline events"`
* `"Show incidents with high severity that are resolved"`
### **Schedules & On-Call**
* `"Show latest on-call schedule in rootly"`
### **Alerts & Monitoring**
* `Show latest alerts in Rootly`
## Support
If you need help or more information about this integration, please contact [**support@rootly.com**](mailto:support@rootly.com) or use the lower right chat widget to get connected with an engineer.
# Installation
Source: https://docs.rootly.com/integrations/google-calendar/installation
## Installing Google Calendar on Rootly
You'll be prompted to **choose a connection method** to your Google Meet:
* Connect through OAuth credentials
* Connect through JSON file credentials
### Integrating via OAuth
After selecting a Google account, you'll be prompted to **grant Rootly permission** to integrate with your Google account.
Select `Allow` and you'll be redirected back to Rootly and the installation is considered complete!
### Integrating via GCP Service Account
Next, navigate to `Service Accounts` and create a new service account by clicking on `Create Service Account`.
Fill in the Service account details, your `Service Account ID` will be automatically generated. Click on `Done` when you have completed the form.
Next, Navigate to the `Keys` tab and click on `Add a Key`.
Create a key and download the JSON format.
Next, navigate back to the Rootly integration page and upload the JSON file.
Now in [https://admin.google.com](https://admin.google.com/ "https://admin.google.com") > Security > [Api Controls](https://admin.google.com/ac/owl "Api Controls") > [Domain Wide Delegation](https://admin.google.com/ac/owl/domainwidedelegation "Domain Wide Delegation")
Select your service account and add the scope below:
* [https://www.googleapis.com/auth/calendar.readonly](https://www.googleapis.com/auth/calendar.readonly "https://www.googleapis.com/auth/calendar.readonly")
* [https://www.googleapis.com/auth/calendar.events](https://www.googleapis.com/auth/calendar.events "https://www.googleapis.com/auth/calendar.events")
Now in [https://admin.google.com](https://admin.google.com/ "https://admin.google.com") > Google Workspace > [Core Google Workspace.](https://admin.google.com/ac/appslist/core "Core Google Workspace.")
Select Google Calendar.
* Configure External sharing options for primary calendar like below:
* Configure Internal sharing options for primary calendar like below:
Now go in your own calendar > Settings and share your calendar with the service account email with **make changes to events** permission.
Make sure to enter the email of the user you want to schedule meetings as in the Rootly integration:
Click `Save` and you should be all set!
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete.**
# Workflows
Source: https://docs.rootly.com/integrations/google-calendar/workflows
## Overview
Our Google Meet integration leverages workflows to automatically schedule Google Calendar events. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows "Workflows") documentation first.
## Available Workflow Actions
### Create a Google Calendar Event
This action allows you to **schedule a Google Meet meeting** on Google Calendar.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Summary
This field allows you to define the title of the Google Calendar event. The default value is `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
#### Conference Type
This field allows you to select a conference type to attach a video meeting to your Google Calendar event using the selected option. Ensure that you select `Hangout`.
#### Time Zone
This field allows you to select a timezone for scheduling your Google Calendar event.
#### Days Until Meeting
This field allows you to specify the date of the Google Calendar event by providing the number of days left until the event.
#### Meeting Duration
This field allows you to define the duration of your Google Calendar event. This field supports Liquid syntax.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Event
This field allows you to specify the Google Calendar Event ID of the event you want to update. The default is set to `{{ incident.google_calendar_event_id }}` to match the event ID of your incident. This field supports Liquid syntax.
#### Adjustment
This field is a dropdown that allows you to specify the type of date-and-time adjustment you want to perform on your Google Calendar event, if any.
#### Adjustment Days
This field is a dropdown that allows you to specify the number of days by which you want to adjust your Google Calendar event, if any.
#### Meeting Duration
This field allows you to define the duration of your Google Calendar event. This field supports Liquid syntax.
## Installation
Please see the [**Installation** page](/integrations/google-meet/installation "Installation") to get started with your Google Meet integration.
## Workflows
Rootly relies on workflows to automate interactions with Google Meet. The [**Workflows** page](/integrations/google-meet/workflows "Workflows") will walk you through how to set up commonly used workflows involving Google Meet.
# Installation
Source: https://docs.rootly.com/integrations/google-meet/installation
Install and configure the Google Meet integration with Rootly to enable automated meeting room creation for incidents.
## Installing Google Meet on Rootly
You'll be prompted to **choose a connection method** to your Google Meet:
* Connect through OAuth credentials
* Connect through JSON file credentials
### Integrating via OAuth
After selecting a Google account, you'll be prompted to **grant Rootly permission** to integrate with your Google account.
Select `Allow` and you'll be redirected back to Rootly and the installation is considered complete!
### Integrating via GCP Service Account
Next, navigate to `Service Accounts` and create a new service account by clicking on `Create Service Account`.
Fill in the Service account details, your `Service Account ID` will be automatically generated. Click on `Done` when you have completed the form.
Next, Navigate to the `Keys` tab and click on `Add a Key`.
Create a key and download the JSON format.
Next, navigate back to the Rootly integration page and upload the JSON file.
Now in [https://admin.google.com](https://admin.google.com/ "https://admin.google.com") > Security > [Api Controls](https://admin.google.com/ac/owl "Api Controls") > [Domain Wide Delegation](https://admin.google.com/ac/owl/domainwidedelegation "Domain Wide Delegation")
Select your service account and add the required scope:
* `https://www.googleapis.com/auth/meetings.space.created`
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete.**
# Workflows
Source: https://docs.rootly.com/integrations/google-meet/workflows
Configure Google Meet workflows to automatically create meeting rooms for incident collaboration.
## Overview
Our Google Meet integration leverages workflows to automatically create Google Meet rooms. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows "Workflows") documentation first.
## Available Workflow Actions
### Create a Google Meet Room
This action allows you to **create a Google Meet link** for an incident, and each incident will receive its own separate Google Meet room. This applies to sub-incidents as well.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Meeting Name - Deprecated
This field allows you to define the title of the Google Meet meeting. The default is set to `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
## Configure
* Auth methods are currently done through `app role` + `app secret`. Need another way to authenticate? Contact us at [support@rootly.com](mailto:support@rootly.com).
## Define a secret
## How to use it
You can use our **liquid markup** in any of our workflow tasks:
Give the following secret in Vault:
```JSON theme={null}
{
"first-secret": "Vault Is The Way",
"nested-secret": {
"foo": "bar"
}
}
```
You can now read secrets:
```JSON theme={null}
{{ secrets.my_secret.first-secret }} // Will resolve to "Vault Is The Way"
{{ secrets.my_secret.nested-secret.foo }} // Will resolve to "bar"
```
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Heroku
Source: https://docs.rootly.com/integrations/heroku
Track Heroku build and deployment events by automatically creating pulses for builds, releases, and deployments.
Heroku will **automatically** add the following Heroku events as pulses:
* A build starts
* A build ends ( Failed or succeeded )
* A release is deployed
* More to come...
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
## Kubewatch
An example ConfigMap is available at: [https://github.com/robusta-dev/kubewatch/blob/master/examples/conf/kubewatch.conf.webhook.yaml](https://github.com/robusta-dev/kubewatch/blob/master/examples/conf/kubewatch.conf.webhook.yaml "https://github.com/robusta-dev/kubewatch/blob/master/examples/conf/kubewatch.conf.webhook.yaml")
You only need the webhook handler to integrate with Rootly.
**Webhook url will be displayed and needs to be replaced after you create this integration**
# Triage Responsibility
Source: https://docs.rootly.com/integrations/linear/triage-responsibility
Integrate Linear's Triage Responsibility feature with Rootly On-Call Schedules to automatically assign issues to current on-call responders.
Use Linear's [Triage responsibility](https://linear.app/docs/triage#triage-responsibility) feature with your Rootly On-Call Schedules to ensure your Linear triage queue stays organized.
When a new issue is created and set to triage, the issue will automatically be assigned to the current person who's on-call. This allows your on-call responders to be the point person for all urgent matters associated with your teams, products, and services across Rootly and Linear.
## Sync a Schedule with your Linear team
### In Rootly
To begin automatically assigning tickets in triage to your on-call responder:
1. In Rootly, navigate to Schedules and edit the schedule you want to sync with Linear.
2. Open the 'Integrations' tab and toggle on 'Sync with Linear'.
### In Linear
1. Navigate to your Team Settings and select 'Triage' under 'Workflows'.
2. Under 'Triage responsibility', select 'Use schedule' at the bottom right corner of the table.
3. Select your Rootly schedule.
# Looker
Source: https://docs.rootly.com/integrations/looker
Capture and share Looker dashboard snapshots in incident workflows for data-driven incident response.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
Then go in your looker instance under Users:
Select an User and add a new api Key:
All set!
## Snapshot graphs
Now a new task is available in your **Genius workflows:**
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# MCP Server
Source: https://docs.rootly.com/integrations/mcp-server
Enable incident management within IDE environments like Cursor and Claude using the Rootly MCP (Model Context Protocol) Server.
## Overview
The Rootly MCP (Model Context Protocol) Server enables you to resolve production incidents quickly within IDE environments like Cursor, Windsurf, and Claude. This open-source tool dynamically generates MCP resources from Rootly's OpenAPI specification, providing seamless incident management capabilities within your development workflow.
This will generate a **webhook url** you need to configure in **Nobl9**
Let's do it!
Nobl9 > Integrations
Click on Alert methods and create a new alert
Select **webhook** type
Copy the webhook url from rootly in there:
That's it! Now you you connect this alert method to any alert policies ! Enjoy.
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# OpenAI
Source: https://docs.rootly.com/integrations/openai
Connect Rootly with your OpenAI account to leverage Rootly AI features using your organization's specific OpenAI agreements and data retention policies.
## Why
Connect Rootly with your Open AI account to leverage Rootly AI using your organizations OpenAI account. Organizations individual accounts may have more specific agreements pertaining to [data retention](/integrations/openai) than the default Rootly OpenAI integration.
## Installation
Rootly requires an OpenAI [API key](https://platform.openai.com/api-keys "API key") and [Organization ID](https://platform.openai.com/settings/organization/general "Organization ID") to integrate with your organizations OpenAI account.
The OpenAI API key must have the 'Model' permission set to 'Read' and the 'Model Capabilities' permission set to 'write'. [Add your API key and Organization ID here](https://rootly.com/account/integrations/open_ai_accounts "Add your API key and Organization ID here")
# Opslevel
Source: https://docs.rootly.com/integrations/opslevel
Integration with OpsLevel service catalog for service ownership and metadata management.
Select the `Setup` to begin installation. You'll be asked to accept the request to install.
## Configuration
Rootly's Outlook integration relies on workflows to automate the scheduling of events. The most common setup is to run the **Create an Outlook Event** when an incident resolves.
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### Calendar
Pick the calendar that you would like to schedule the event to.
### Summary
Enter the title of your scheduled event. This field accepts Liquid syntax.
### Description
Enter a more detailed description of your scheduled event.
### Attendees
Enter the emails of the attendees you'd like to invite. This field accepts Liquid syntax.
### Time Zone
Enter the timezone in which you'd like the meeting to be booked in. The value you select later in the `Time of Meeting` field will be in the timezone selected here.
### Days Until Meeting
Enter the number of days you'd like to schedule the event into. Rootly starts counting from the time when the workflow is run. For example, if the value set in this field is `3` and the workflow was run on January 1st, the event will be scheduled 3 days from January 1st.
### Meeting Duration
Enter the length of the event you'd like to schedule. This field accepts Liquid syntax.
### Time of Meeting
This is the time in which the event will be scheduled at. The time entered here will be in the timezone specified in the `Time Zone` field.
### Exclude Weekends
Checking this option will not include weekends in the count for `Days Until Meeting`.
### Post to Incident Timeline
Checking this option will post the workflow run to the incident timeline.
## Uninstall
1. Login to your **Microsoft Teams Meeting** account.
2. Click **Manage > Installed Apps** or search for the **Rootly** App.
3. Click the **Rootly** app.
4. Click **Uninstall**.
# Pulumi
Source: https://docs.rootly.com/integrations/pulumi
Manage Rootly resources using infrastructure as code with the Pulumi provider.
Our Pulumi provider is available at:
[https://www.pulumi.com/registry/packages/rootly/installation-configuration/](https://www.pulumi.com/registry/packages/rootly/installation-configuration/ "https://www.pulumi.com/registry/packages/rootly/installation-configuration/")
## Installing
This package is available for several languages/platforms:
### Node.js (JavaScript/TypeScript)
[](https://www.npmjs.com/package/@rootly/pulumi "https://www.npmjs.com/package/@rootly/pulumi")[https://www.npmjs.com/package/@rootly/pulumi](https://www.npmjs.com/package/@rootly/pulumi "https://www.npmjs.com/package/@rootly/pulumi")
To use from JavaScript or TypeScript in Node.js, install using either npm:
```js theme={null}
npm install @rootly/pulumi
```
or yarn:
```js theme={null}
yarn add @rootly/pulumi
```
### Python, Go, & .NET
*TBA*
## Creating resources
```js theme={null}
const rootly = require("@rootly/pulumi")
new rootly.Severity("sev0", {
name: "SEV0",
color: "#FF0000"
})
new rootly.Service("elasticsearch_prod", {
name: "elasticsearch-prod",
color: "#800080"
})
new rootly.Functionality("add_items_to_card", {
name: "Add items to card",
color: "#FFFFFF"
})
```
## Syncing resources
Run the regular `pulumi up` command.
# SCIM
Source: https://docs.rootly.com/integrations/scim
Configure SCIM (System for Cross-domain Identity Management) integration for automated user provisioning and management.
## Features
The following features are supported by Rootly:
* **Create users**. Users in Okta assigned to the Rootly application in Okta will be automatically added as members of your organization in Rootly.
* **Deactivate users**. Users in Okta unassigned from the Rootly application in Okta will be automatically removed as members of your organization in Rootly.
* **Import users**. Users in Okta can be imported at once into Rootly.
* **Update User Attributes**. Users attributes updated in Okta will be updated in Rootly ( As firstname, lastname etc. )
## Requirements
Make sure you setup [SSO](/integrations/sso) first.
**Rootly Tenant URL Endpoint:** `https://rootly.com/scim`
**Note**: The endpoint will only resolve in the application after SSO setup has been completed first as noted above.
## Okta
### Enable SCIM provisioning functionality in Okta
1. In Okta, navigate to **Applications > Rootly**
2. Click on the **Provisioning** tab in the application. Under the **Settings** panel on the left-hand side, click the **Integrations** link. Then click **Configure API Integration**.
3. Enter your API Token, you will find it under `Rootly > Integrations > SSO` under `SCIM Token`.
### Enable “create users” and “Deactivate users” functionalities in Okta[](#sKgme)
1. In Okta, navigate to **Applications > Rootly**
2. Click on the **Provisioning** tab in the application. Under the **Settings** panel on the left-hand side, click the **To App** link.
3. Click the **Edit** button at the top right. Check the **Enable** box next to **Create users** and **Deactivate users** to automatically provision/deprovision users in Rootly when they are assigned/unassigned to the Rootly app in Okta.
4. Ensure the **Default username** used to create accounts in Okta is set to **email**. If it’s not, update this value by going to the **Sign on** tab of the Rootly application in Okta, click **Edit**, then set the **Application username** format to **email** under the **Credentials settings** section.
### Provision Users via Push Groups
**Create a Group**
1. In Okta, navigate to **Directory > Groups** on the left navigation pane.
2. Click on **+Add Group**.
3. Give the Group a `name` and an optional `description`.
4. Now you have a Group which you can add Users to and provision the entire Group to a Rootly Role.
**Provision a Group**
1. In Okta, navigate to **Applications > Rootly**
2. Click on the **Push Groups** tab
3. Click on **+Push Groups** button to find the Group you'd like to provision.
1. Click on the Group you'd like to provision from the dropdown.
4. Switch from **Create Group** to **Link Group**.
5. Click **Save**.
6. Navigate to your Rootly UI and select **Integrations > SSO**.
7. Under the **Role Assignment** section, select which **Rootly Role** you'd like to assign to the **Okta Group**.
8. You're all set! Now, every time you add a user to that Okta Group, they will be provisioned to Rootly in the associated Rootly Role.
## Microsoft Entra
### Enabled SCIM provisioning functionality in Microsoft Entra
[https://learn.microsoft.com/en-us/entra/identity/saas-apps/rootly-provisioning-tutorial](https://learn.microsoft.com/en-us/entra/identity/saas-apps/rootly-provisioning-tutorial "https://learn.microsoft.com/en-us/entra/identity/saas-apps/rootly-provisioning-tutorial")
## Google Workspace
### Enabled SCIM provisioning functionality in Google Workspace[](#Kpp0A)
Google Workspace only supports SCIM for a few apps for reasons we aren't aware about. Fortunately enough we can take advantage of those to make it work with rootly.
* Add a new Web and Mobile apps
* Then add Adobe App
* In the next form fill out all fields with
* [https://dummy.com/saml](https://dummy.com/saml)
* When it comes to configure auto-provisioning, copy the SCIM token you can find under Rootly > Integrations > SSO.
* Endpoint url to configure is [https://rootly.com/scim](https://rootly.com/scim "https://rootly.com/scim")
* Select a group of user you want to import into rootly or leave empty.
* Finally enabled the application. The sync should kick in shortly.
## Keycloak
### Enable SCIM provisioning functionality in Keycloak
1. **Install the SCIM Extension**
* Download the keycloak-scim JAR file from the [releases](https://github.com/mitodl/keycloak-scim/releases)
* Place it in `/opt/keycloak/providers/` directory
* Restart Keycloak to load the extension
2. **Configure Event Listeners**
* Navigate to **Realm Settings > Events**
* In the **Event Listeners** tab, add `scim` to the list of listeners
* Save the configuration
3. **Create SCIM Federation Provider**
* Navigate to **User Federation**
* Click **Add provider** and select **SCIM**
* Configure the following settings:
* **UI display name**: `Rootly`
* **SCIM 2.0 endpoint**: `https://rootly.com/scim`
* **Endpoint content type**: `application/scim+json`
* **Auth mode**: `BEARER`
* **Auth password/token**: Enter your SCIM token from `Rootly > Integrations > SSO`
4. **Configure Username Format**
* Set the environment variable `SCIM_EMAIL_AS_USERNAME=true` to ensure usernames are sent in email format
* This is required for proper user matching in Rootly
5. **Enable Propagation Features**
* **Enable user propagation**: On
* **Enable group propagation**: On (optional)
* **Log SCIM requests and responses**: On (for debugging)
* **Import action**: `CREATE_LOCAL`
6. **Optional Periodic Sync**
* **Periodic full sync**: Enable if you want regular full user synchronization
* **Periodic changed users sync**: Enable for incremental synchronization
### Testing the Configuration
* Create a test user in Keycloak
* Check Rootly to verify the user was automatically provisioned
* Review logs in Keycloak for any SCIM errors
**Note**: Ensure your Rootly SCIM token is valid and SSO is properly configured before setting up the SCIM integration.
## Troubleshooting
If you encounter any questions or difficulties with SSO or SCIM provisioning with Okta, please contact Rootly support via [support@rootly.com](mailto:support@rootly.com).
# SendGrid
Source: https://docs.rootly.com/integrations/sendgrid
Send email notifications with custom domain names through SendGrid's email delivery service.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page.
Create an API Key with restricted access and scopes:
* `mail.send`
# Installation
Source: https://docs.rootly.com/integrations/service-now/installation
The ServiceNow integration provides a step-by-step instructions to connect Rootly with your ServiceNow instance, enabling bi-directional transfer of incident data.
## Overview
**ServiceNow** Integration allows you to:
* Automatically **create an incident in ServiceNow** upon creation of Rootly incident.
* Automatically **update an existing incident in ServiceNow** upon updates on Rootly incident.
* Automatically **create incident in Rootly** upon creation of ServiceNow incident.
* Automatically **update an existing incident in Rootly** upon updates on ServiceNow incident.
* Automatically **page on-call user** upon creation of ServiceNow incident.
## Establish Write-Access to ServiceNow
Rootly integrates to ServiceNow via OAuth - enabling Rootly to create and update the INC table in ServiceNow.
Click **Setup** to open configuration modal.
**Log into your ServiceNow** instance as an Admin user and navigate to \*\*System OAuth \*\*>**Application Registry** .
Click on **New** to initiate the creation of a new application.
Select the **Create an OAuth API endpoint for external clients** option.
Copy and paste the following values to the corresponding fields in ServiceNow and then click on **Submit**.
| ServiceNow Field | Value |
| ---------------- | ---------------------------------------------- |
| `Name` | `Rootly` |
| `Redirect URL` | `https://rootly.com/auth/service_now/callback` |
Locate and open the new application you just created in ServiceNow. You might have to search for it by Name if you have a lot of applications already.
Copy following fields from ServiceNow.
You'll be presented with a ServiceNow screen to proceed with the integration. Click on **Allow**.
If integration is successful, you'll be presented with this screen on Rootly.
You can click on **Save** and you are all set! Your ServiceNow card should appear with a **Connected** indicator when you're on the [Integrations page](https://rootly.com/account/integrations).
## Establish Ability to Receive ServiceNow Events
Webhooks are set up in ServiceNow to send incident events to Rootly. Rootly is then able to process these events to facilitate automated actions.
Navigate to your ServiceNow instance and go to \*\*System Definition \*\*>**Business Rules** .
Click on **New** to initiate the creation a new business rule.
Fill in the following fields.
| ServiceNow Field | Value |
| ---------------- | -------------------------------------------------------------------------------------- |
| `Name` | Give it any descriptive name you'd like. |
| `Table` | Select `Incident [incident]`. |
| `Advanced` | Ensure this is checked. |
| `When` | Select `After`. |
| `Insert` | Check this if you want to receive an event after an incident is created in ServiceNow. |
| `Update` | Check this if you want to receive an event after an incident is updated in ServiceNow. |
| `Delete` | Check this if you want to receive an event after an incident is deleted in ServiceNow. |
Navigate to the **Advanced** tab.
Replace content in the **Script** editor with the following code.
```js theme={null}
(function executeRule(current, previous /*null when async*/ ) {
try {
var r = new sn_ws.RESTMessageV2();
r.setEndpoint("
Click **Submit**. Now you're ready to receive ServiceNow events in Rootly!
## Uninstall
You can **uninstall** this integration by navigating to **Configuration** > **Integrations** > \*\*ServiceNow \*\*>**Delete.**
## Using ServiceNow as an Alert Source
If your org is using Rootly On-Call, ServiceNow can also be set up as an alert source. This allows your on-call user to be paged whenever a ServiceNow ticket is created.
### Update a ServiceNow Incident
This workflow action updates the data properties of an existing record from the `Incident` table (e.g. `INC0010001`).
## Common Custom Fields
### Major Incident
```js theme={null}
// Example create major incident (make sure acts_as_user is set) and ACL good (Cf. https://community.servicenow.com/community?id=community_question&sys_id=fae73aeb1b7370900b8a9979b04bcb1a)
{
"assignment_group": "3De45d9ebc3b333200fe02c9bb34efc434",
"major_incident_state": "proposed"
}
```
### Work Notes
Work notes are internal comments that can be added to a ServiceNow incident. Work notes cannot be seen by customers.
```js theme={null}
{
"work_notes": "{{ incident.events[0].event_raw }}"
}
```
### Comment
Comments can be added to a ServiceNow incident and it can be seen by customers.
```js theme={null}
{
"comments": "{{ incident.events[0].event_raw }}"
}
```
## Add Configuration Item (CI) to Incident
Adding a configuration item (CI) to an incident is an awkward action due to technical limitations of ServiceNow APIs. To facilitate this action we will need to utilize Rootly's HTTP Client workflow action to consolidate mutiple ServiceNow API calls into a single action.
The ServiceNow API we will use to add CIs to an incident is the [Table API](https://docs.servicenow.com/bundle/xanadu-api-reference/page/integrate/inbound-rest/concept/c_TableAPI.html#title_table-POST "Table API").
```curl theme={null}
curl -X POST \
'https://
### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
### URL
This is the endpoint of the ServiceNow Batch API. The value should be in the following format: `https://
Create an **api key** on Shortcut and fill our integration api key input:
## Settings
You custom specify which **project** you want to create stories in
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# SMTP
Source: https://docs.rootly.com/integrations/smtp
Send email notifications using your custom domain through SMTP server configuration.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page.
**Address**: This would be the SMTP server address for the email server. e.g: smtp.gmail.com **Port**: Port for the SMTP server. **Domain**: The domain of the custom domain name you would like to use. **Username**: The email of the email that will be used to send emails. **Password**: The password of the email that will be used to send emails.
**Port**: Port for the SMTP server.
**Domain**: The domain of the custom domain name you would like to use.
**Username**: The email of the email that will be used to send emails.
**Password**: The password of the email that will be used to send emails.
# SSO
Source: https://docs.rootly.com/integrations/sso
Enable single sign-on with SAML 2.0 compatible identity providers including Okta, Google, OneLogin, Auth0, Azure, and more.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
## Identity Providers
Rootly is compatible with **any identity provider** supporting **SAML 2.0.**
Depending on the identity provider, you might be asked for the following information during your setup process:
**ACS URL**: [https://rootly.com/users/saml/auth\\](https://rootly.com/users/saml/auth\\)
**Entity ID**: [https://rootly.com/users/saml/metadata](https://rootly.com/users/saml/metadata)
### Okta
Let's go to the **Applications** panel.
Search for **Rootly**.
Click on **Add**.
Select **SAML 2.0**.
Now our app is created let's go back in **Applications > Rootly** and click **View Setup Instructions:**
Finally copy the fields as shown below into **Rootly**, this information from Okta is unique to your organization.
You are all set!
### Google
You will need to access the **Google Admin Console:** [https://admin.google.com/ac/home](https://admin.google.com/ac/home).
Follow screenshot steps as below:
Make sure `Signed Response` is checked and the app `ON for everyone` is checked in your org unit.
And finally let's edit the attributes mapping.
Let's switch to Rootly. You can get the identity login url by clicking on the `TEST SAML LOGIN` button.
### OneLogin
Browse the Applications Store page and install Rootly.
Copy fields over Rootly like shown below
* Issuer URL **->** Identity Provider ID
* SAML 2.0 endpoint **->** Identity Login Url
* In the certificate section > View Details > X.509 Certificate **->** Idp Cert
You are all set!
### Auth0
Docs: [https://marketplace.auth0.com/integrations/rootly-sso-integration](https://marketplace.auth0.com/integrations/rootly-sso-integration)
### Azure
Install SSO integration through the Azure marketplace
* Marketplace: [https://azuremarketplace.microsoft.com/en-US/marketplace/apps/aad.rootly](https://azuremarketplace.microsoft.com/en-US/marketplace/apps/aad.rootly)
* Tutorial: [https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/rootly-tutorial](https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/rootly-tutorial)
### Rippling
Integrate Rippling SSO + SCIM in one click [https://www.rippling.com/app-shop/app/rootly](https://www.rippling.com/app-shop/app/rootly)
### Keycloak
Keycloak is an open-source identity and access management solution. Follow these steps to configure SAML SSO with Rootly.
#### Prerequisites
* Access to Keycloak admin console
* Keycloak realm set up (can use default `master` realm for testing)
* User account in Keycloak with email attribute configured
#### Step 1: Create SAML Client in Keycloak
1. Navigate to **Clients** in the Keycloak admin console
2. Click **Create Client**
3. Select **SAML** as the client type
4. Set **Client ID** to: `https://rootly.com/users/saml/metadata`
5. Click **Next** and **Save**
#### Step 2: Configure Client Settings
Navigate to your client's **Settings** tab and configure:
**Access Settings:**
* **Root URL**: `https://rootly.com/users/saml`
* **Home URL**: `https://rootly.com/users/saml`
* **Valid redirect URIs**:
* `https://rootly.com/*`
* `https://rootly.com/users/saml/auth`
* **Master SAML Processing URL**: `https://rootly.com/users/saml/auth`
**SAML Capabilities:**
* **Name ID format**: `email`
* **Force POST binding**: `On`
* **Include AuthnStatement**: `On`
**Signature and Encryption:**
* **Sign documents**: `On`
* **Sign assertions**: `On`
* **Signature algorithm**: `RSA_SHA256`
* **SAML signature key name**: `KEY_ID`
* **Canonicalization method**: `EXCLUSIVE`
#### Step 3: Configure Keys
Navigate to the **Keys** tab:
* **Client signature required**: `Off`
* **Encrypt assertions**: `Off`
#### Step 4: Configure Name ID Mapper
1. Go to **Client scopes** → **Dedicated scopes** → **Mappers**
2. Create or edit the **Email** mapper:
* **Mapper type**: `User Attribute Mapper For NameID`
* **Name**: `Email`
* **Name ID Format**: `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
* **User Attribute**: `email`
#### Step 5: Configure User Email
Ensure your test user has an email address set:
1. Navigate to **Users** → Select your user
2. Go to **Details** tab
3. Set **Email** field (e.g., `user@company.com`)
4. Set **Email verified**: `Yes`
#### Step 6: Get Keycloak Configuration
Collect the following information from Keycloak:
1. **Identity Provider ID**: `https://your-keycloak-host/realms/your-realm`
2. **Identity Login URL**: `https://your-keycloak-host/realms/your-realm/protocol/saml`
3. **Certificate**:
* Go to **Realm Settings** → **Keys** → **RS256** → **Certificate**
* Copy the certificate and format with proper PEM headers:
```
-----BEGIN CERTIFICATE-----
[certificate content]
-----END CERTIFICATE-----
```
#### Step 7: Configure Rootly
In your Rootly SSO integration modal, set:
| Rootly Field | Keycloak Value |
| ---------------------- | ------------------------------------------------------------ |
| `Identity Provider Id` | `https://your-keycloak-host/realms/your-realm` |
| `Identity Login Url` | `https://your-keycloak-host/realms/your-realm/protocol/saml` |
| `Identity Logout Url` | Leave blank or set logout URL |
| `Idp Cert` | PEM-formatted certificate from Keycloak |
| `Domain Name` | Your domain (e.g. company.com) |
### Jumpcloud
Let's begin by navigating to the **SSO Applications** page from the left navigation.
Click **Add New Application**
Search for and install the **Rootly** application.
Once installed, select the Rootly application to enter edit mode and navigate to the **SSO** tab.
Update the `IdP Entity ID` from `JumpCloud` to `JumpCloud-
Download your **IDP Certificate**. It should download as a `.pem` file.
Navigate to your **Rootly SSO Integration** modal and fill in the following fields with the corresponding values from JumpCloud.
| Rootly Field | JumpCloud Field |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `Identity Provider Id` | `IdP Entity ID ` |
| `Identity Login Url` | `IDP URL` |
| `Identity Logout Url` | Leave blank or choose any page you'd want to navigate your user to when they log out. |
| `Idp Cert` | Open the certificate you downloaded in the previous step with a text editor of your choice. Copy and paste the text content. |
| `Domain Name` | Your domain (e.g. mycompany.com) |
Go ahead `Enable` and `Save` your SSO setup in Rootly.
You're now SSO enabled!
If you want to set up **Just-In-Time (JIT) provisioning**, navigate to the **Identity Management** tab in edit mode and set the following fields according to the mappings below.
* `API Type`: `SCIM API`
* `SCIM Version`: `SCIM 2.0`
* `Base URL`: `https://rootly.com/scim`
* `Token Key`: Pick this value up from your SSO Configuration screen in in Rootly
* `Test User Email`: You can use your own email as long as the email domain matches the one set in your Rootly SSO configuration page.
Go ahead and select `Test Connection`. You should see a successful message once a connection is confirmed.
If you'd like to **provision users by JumpCloud Groups**, go ahead and select the following option.This will allow you to provision the users in each JumpCloud Group with a specific Rootly Role.
Navigate to your **Rootly SSO Integrations** modal and map the desired JumpCloud Group to the desired Rootly Role.
Go ahead and `Save` your configuration. You're all set for JIT user provisioning!
## Login Behaviour
If you have SSO enabled, all other login methods such as Google, Slack, Email/Password will automatically redirect users to the SSO method instead.
## Misconfiguration
If you set up SSO incorrectly, you may not be able to sign in anymore. In that case please contact [support@rootly.com](mailto://support@rootly.com) or use the lower right chat widget for live assistance.
# Creating A Statuspage Incident
Source: https://docs.rootly.com/integrations/status-page-io/creating-a-statuspage-incident
Learn how to create StatusPage.io incidents directly from Rootly incidents using the Status Page Timeline feature.
## Overview
The following guide will walk you through how to create a StatusPage.IO via a Rootly incident. In order to create a status page incident you first need import a status page from StatusPage.io. If you have not done that yet please refer to this guide [here](/integrations/status-page-io/importing-status-pages "here").
## Steps
1. Within any non published incident click the Status Page Timeline tab the click publish
2. Within the publish dialog select a status page that you have integrated with StatusPage.IO (these pages will have "(StatusPage.io)" in the title). Fill out the publish form with your desired settings.
3. After clicking publish your incident should be added to the Rootly timeline. Clicking the hyperlink next to the incident event will take you to the newly created StatusPage.io incident
# Importing Status Pages
Source: https://docs.rootly.com/integrations/status-page-io/importing-status-pages
Import your existing status pages from StatusPage.io into Rootly for integrated incident communication management.
## Importing Status Pages
### Overview
You can import your existing status pages from statuspage.io. This requires that StatusPageIO integration has already been set up. If you have not that yet please refer to our guide [here](/integrations/status-page-io "here").
### Steps
1. Within our web experience navigate to *Configuration > Status pages*
2. On the status pages configuration page click *Import from statuspage.io*
3. Within the popup modal select the StatusPageIO page you want to import into Rootly. Then click import pages
4. You should see the newly imported page within the list
# Importing Templates
Source: https://docs.rootly.com/integrations/status-page-io/importing-templates
Import StatusPage.io templates into Rootly to auto-populate status page update fields with standardized content.
## Overview
Rootly supports StatusPage.IO templates. After importing your templates from StatusPage.IO you can utilize them when making status page updates to auto populate fields.
Templates can only be imported for status pages that are linked to StatusPage.IO. If you don't have a status page that is linked to StatusPage.io you can follow steps [here](/integrations/status-page-io/importing-status-pages "here") on importing status pages
## Steps
1. Within the status page configuration page select edit on a status page that has a StatusPage.IO page linked. A StatusPage.IO linked page will have the STATUSPAGE.IO column populated
2. Scroll down until you see Import from Statuspage.io for templates
3. Within the popup modal select which templates you wish to import from StatusPage.IO
4. The imported template should now be in Rootly under your StatusPage.IO integrated status page
# Using Status Page Templates
Source: https://docs.rootly.com/integrations/status-page-io/using-status-page-templates
Use imported StatusPage.io templates to standardize and auto-populate status page event updates in Rootly.
## Overview
Event status updates are often standardized via templates. These are preset values that will auto-populate your event update. This guide will aim to help you use them. Using StatusPage templates requires you to first import them into Rootly. If you have not done that yet please follow this guide [here](/integrations/status-page-io/importing-templates "here").
## Steps
1. Within any incident in Rootly click the Status Page Timeline Tab then the Add to Timeline button
2. Within the publish modal select a status page that has StatusPage.io integrated (These pages will have "(Statuspage.io) in the title")
3. Within the same publish modal select the template you wish to use for your incident event update
4. Post selection, the template will populate preset such as the event message, status, and any effected components
# Terraform
Source: https://docs.rootly.com/integrations/terraform
Manage Rootly resources using infrastructure as code with the official Terraform provider for services, severities, workflows, and more.
Our Terraform provider is available at:
[https://registry.terraform.io/providers/rootlyhq/rootly/latest](https://registry.terraform.io/providers/rootlyhq/rootly/latest "https://registry.terraform.io/providers/rootlyhq/rootly/latest")
## Documentation
[https://registry.terraform.io/providers/rootlyhq/rootly/latest/docs](https://registry.terraform.io/providers/rootlyhq/rootly/latest/docs "https://registry.terraform.io/providers/rootlyhq/rootly/latest/docs")
## Example
```tf main.tf theme={null}
terraform {
required_providers {
rootly = {
source = "rootlyhq/rootly"
}
}
}
# Configure the Rootly provider
provider "rootly" {
# We recommend using the `ROOTLY_API_TOKEN` env var to set the API Token
# when interacting with Rootly's API.
# api_token = "
## Update a Trello card
# Twitter
Source: https://docs.rootly.com/integrations/twitter
Post incident updates directly to Twitter to keep your community informed about ongoing issues and resolutions.
## Installation
You can setup this integration as a **logged in admin user** in the integrations page:
## Tweet
You can tweet directly from the incident timeline by changing the visibility to: **incident responders + private status page + twitter**
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Installation
Source: https://docs.rootly.com/integrations/webex/installation
## Installing Webex on Rootly
You'll be prompted to sign in with your Webex account or create a new one. After signing in, you'll be prompted to grant Rootly permission to integrate with your Webex account.
Once confirmed, you'll be redirected back to Rootly and the installation is considered complete!
## Uninstall
You can uninstall this integration in the integrations panel by clicking **Configure > Delete.**
# Webex
Source: https://docs.rootly.com/integrations/webex/webex
Streamline incident communication with automatic Webex meeting creation, dynamic naming, and Slack integration for efficient collaboration.
Rootly's Webex integration enhances incident management experience by streamlining incident communication, providing teams with a robust platform for real-time collaboration and efficient incident resolution.
Some key features of this integration includes:
1. **Real-time Collaboration:**
* Automatically spin up Webex Meeting bridge associated with an incident.
2. **Liquid variable support**
* Dynamically set meeting names via Liquid variables.
3. **Slack-Native Experience:**
* Automatically surface Webex Meeting link within incident Slack channel
## Installation
Please see the [**Installation** page](/integrations/webex/installation "Installation") to get started with your Webex integration.
## Workflows
Rootly relies on workflows to automate interactions with Webex. The [**Workflows** page](/integrations/webex/workflows "Workflows") will walk you through how to set up commonly used workflows involving Webex.
# Workflows
Source: https://docs.rootly.com/integrations/webex/workflows
## Overview
Our Webex integration leverages workflows to automatically create a Webex Meeting link for an incident. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows "Workflows") documentation first.
## Available Workflow Actions
### Create a Webex Meeting
This action allows you to create a Webex Meeting link for a specific incident.
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Meeting Name
This field allows you to set the Webex meeting's title. The default is set to `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
## Actions
# Zendesk
Source: https://docs.rootly.com/integrations/zendesk
Create and sync tickets automatically between Rootly incidents and Zendesk, with bidirectional updates and marketplace plugin support.
Leverage our popular Zendesk integration for automatic ticket creation and syncing. In addition to the Rootly Zendesk integration, you can bring Rootly right into Zendesk with our new plugin from the [Zendesk Marketplace](https://www.zendesk.com/marketplace/apps/support/995423/rootly/ "Zendesk Marketplace").
## Integration Capabilities
Our **Zendesk** Integration allows you to:
* Ability to create a Rootly incident directly in Zendesk.
* Updating the incident's title, description, and/or status in Rootly will also update the corresponding Zendesk ticket.
* Ability to create a Rootly action item in Zendesk.
* Updating an action item's title, description, and/or status in Rootly will also update the corresponding Zendesk ticket.
* Ability to view, search, and attach recent Rootly incidents in Zendesk.
* Ability to view active or related Rootly incidents in Zendesk and attach them to the Zendesk ticket.
Limitations include:
* Changing Zendesk incident ticket attributes will not update incident attributes in Rootly.
* Changing the Zendesk action item ticket status will not update the action item status in Rootly.
## Setting Up
## Permissions
Following oauth2 scopes are required
```ruby theme={null}
users:read
tickets:write
webhooks:write
triggers:write
```
## Uninstall
You can **uninstall** this integration in the integrations panel by clicking **Configure > Delete**
# Installation
Source: https://docs.rootly.com/integrations/zoom/installation
## Installing Zoom on Rootly
You'll be prompted to **sign in with your Zoom account** or create a new one. After signing in, you'll be prompted to **grant Rootly permission** to integrate with your Zoom account.
## Permissions
* meeting:write - **View and manage your meetings**
* This scope is used to create a new meeting
* meeting:read - **View your meetings**
* This scope is used to join a new meeting
* user\_zak:read - **View user’s zak token**
* This scope is unused, however cannot be removed from a Zoom SDK app
* user:read - **View your user information**
* This scope is used to improve your zoom experience
Once confirmed, you'll be redirected back to Rootly and the **installation is complete**!
Configure your Zoom room preferences, such as the meeting name and call recording storage, on the Rootly Integrations page.
## Uninstall
On Rootly:
1. You can uninstall this integration in the integrations panel by clicking **Configure > Delete.**
On Zoom:
2. Login to your Zoom account and navigate to the Zoom App Marketplace.
3. Click Manage > Apps on Account or search for the Rootly App.
4. Click the Rootly app.
5. You can **Remove** or **Disable** Rootly from this page.
# Workflows
Source: https://docs.rootly.com/integrations/zoom/workflows
## Overview
Our Zoom integration leverages workflows to automatically create a Zoom link associated with an incident. If you are unfamiliar with how Workflows function please visit our [Workflows](/workflows/workflows) documentation first.
## Available Workflow Actions
### Create a Zoom Room
This action allows you to **create a Zoom link for an incident.**
#### Name
This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.
#### Meeting Name
This field allows you to set the Zoom meeting's title. The default is set to `{{ incident.title }}` to match the title of your incident. This field supports Liquid syntax.
## Installation
Please see the [**Installation** page](/integrations/zoom/installation "Installation") to get started with your Zoom integration.
## Workflows
Rootly relies on workflows to automate interactions with Zoom. The [**Workflows** page](/integrations/zoom/workflows "Workflows") will walk you through how to set up commonly used workflows involving Zoom.