# Overview Source: https://docs.rootly.com/ai/ai Discover how Rootly AI supports incident response with proactive guidance, concise summaries, and conversational workflows across the incident lifecycle. Rootly AI applies generative AI across the entire incident lifecycle, from the moment an alert fires through post-incident analysis. Rather than acting as a separate tool, Rootly AI is embedded directly into incident workflows, helping responders understand what is happening, decide what to do next, and document outcomes with minimal manual effort. Rootly AI provides proactive guidance, accurate summaries, and contextual insights using simple conversational prompts in both Slack and the web application. All AI capabilities are designed to fit naturally into existing incident response processes without disrupting established workflows. Rootly AI is designed to augment incident responders, not replace them. It provides context, suggestions, and summaries while keeping humans in control of decisions and actions. Rootly AI overview

## What Rootly AI Can Do Rootly AI supports a focused set of capabilities that map directly to common incident-response needs. Each feature can be used independently and is available when both enabled at the team level and permitted for the specific incident based on privacy settings. ### Generated Incident Titles Rootly AI can automatically generate concise, descriptive incident titles based on available incident context. This helps teams quickly understand the nature of an incident without manually crafting a summary under pressure. Titles are designed to be short, consistent, and informative, making dashboards, timelines, and retrospectives easier to scan. ### Incident Summarization Incident Summarization produces a single, coherent summary of what happened during an incident. The summary is generated from incident metadata, timeline events, alerts, action items, and relevant communications. It is intended to capture the problem, impact, trigger or cause when available, resolution steps, and key participants in plain language. Summaries can be generated and updated during an active incident or after resolution, automatically improving as more information becomes available. Summaries can be generated using `/rootly summary` in Slack or the **Generate Summary** button in the web application. ### Incident Catchup Incident Catchup helps responders who join an incident after it has already started quickly get oriented. Instead of scrolling through long Slack threads, responders can request a catchup summary that reflects the current state of the incident. Responders can request a catchup summary using `/rootly catchup` in Slack or the catchup feature in the web application. This is especially useful for long-running or high-severity incidents with heavy communication volume. ### Mitigation and Resolution Summaries When an incident transitions through key lifecycle stages such as mitigation, resolution, cancellation, or closure, Rootly AI can assist by drafting short explanations of what actions were taken and why. These summaries help ensure that incident timelines and retrospectives accurately reflect decision-making and outcomes without requiring responders to write detailed explanations during or after an incident. ### Ask Rootly AI Ask Rootly AI allows responders to ask contextual questions using natural language. In Slack, this appears as a conversational assistant within the incident channel that answers questions about the current incident. In the web application, the AI Copilot enables questions across incident history and aggregated metrics, with the ability to query, filter, group, and visualize incident data. This capability can be used to understand what has happened so far, identify next steps, draft communications, or analyze trends across incidents. ### Rootly AI Editor The Rootly AI Editor is available in all text fields throughout the platform, including incident descriptions, summaries, communications, retrospectives, and more. It helps improve written content by fixing grammar, simplifying language, expanding details, or shortening text while preserving meaning. ### Meeting Scribe Rootly AI can automatically join incident bridge calls on supported meeting platforms including Zoom, Google Meet, Webex, Microsoft Teams, and GoToMeeting. During meetings, it captures live transcripts and produces post-meeting summaries. These transcripts and summaries are attached to the incident and can be incorporated into AI-generated summaries and retrospectives. ## Privacy, Security, and Control Rootly AI is designed with privacy and data isolation as first-class principles. All AI functionality is controlled through team-level settings, allowing organizations to opt in or out of individual features. AI access is evaluated on a per-incident basis and respects incident visibility and Slack message-scoping rules. For private incidents, AI features are only available when explicitly permitted by configuration. Sensitive information such as links, emails, and passwords is automatically redacted before being sent to AI providers, and all requests are authenticated and scoped to the requesting organization. Organizations can also bring their own LLM API keys, including OpenAI or IBM Watsonx, for additional data privacy and segmentation. Rootly AI never uses customer data to train models or improve results for other customers. Data sent to AI providers is used solely to deliver Rootly AI functionality. ## Learn More * [Generated Incident Title](/ai/generated-incident-title) * [Incident Summarization](/ai/incident-summarization) * [Incident Catchup](/ai/incident-catchup) * [Mitigation and Resolution Summary](/ai/mitigation-and-resolution-summary) * [Ask Rootly AI](/ai/ask-rootly-ai) * [Rootly AI Editor](/ai/rootly-ai-editor) * [Meeting Scribe](/ai/meeting-scribe) *** ## Frequently Asked Questions No. Rootly AI is controlled through team-level configuration settings and can be enabled or disabled per feature. AI access is also evaluated on a per-incident basis and respects incident visibility and privacy rules. No. Rootly AI does not take actions or modify incident properties automatically. It provides suggestions, summaries, and contextual guidance while keeping responders fully in control of decisions and updates. No. Rootly AI never uses customer data to train models or improve results for other customers. Data sent to AI providers is used solely to deliver Rootly AI functionality. Rootly AI can be used in private incidents only when explicitly permitted by configuration. Access depends on incident visibility settings and Slack message scope controls. Rootly AI settings are managed at the team level in the Rootly web application. Each AI capability can be enabled or disabled independently. *** **Need help or have a question?** Contact us anytime at **[support@rootly.com](mailto:support@rootly.com)**, use the `/rootly support` Slack command, or visit **Getting Help** to start a chat. # Ask Rootly AI Source: https://docs.rootly.com/ai/ask-rootly-ai Interactive AI assistants that help answer questions about the current incident in Slack or analyze incident history and metrics in the web application. ## Overview Ask Rootly AI provides two complementary AI assistants designed to support responders during incidents and after the fact. * **Slack Copilot** helps responders ask questions about the *current incident* directly within an incident Slack channel. * **Web Copilot** enables deeper analysis across *incident history and metrics* in the Rootly web application. Together, these tools help teams quickly understand what’s happening, communicate clearly, and analyze trends—without replacing human decision-making. *** ## Slack Copilot (Ask Rootly AI in Slack) Slack Copilot is designed for real-time collaboration during an active incident. By mentioning `@rootly` in a thread within an incident Slack channel, responders can ask questions and receive concise, contextual answers based on the current incident. **Via Slack in an incident channel: mention `@rootly` in a thread** Ask Rootly AI in Slack

### What Slack Copilot Can Help With Slack Copilot focuses exclusively on the *current incident* and can: * Answer questions about what has happened so far * Identify roles such as the incident commander * Summarize actions taken and decisions made * Help draft internal or external communications * Provide general incident response guidance Example prompts include: * What happened? * What caused the incident? * Who is the commander? * What have we tried so far? * What should I do next? * Write a customer-facing summary of this incident Responses are intentionally concise to support fast decision-making. ### Limitations Slack Copilot cannot: * Answer questions about historical incidents * Modify incident properties * Access data outside the current incident Slack Copilot is restricted to answering questions about the current incident and general incident management practices. *** ## Web Copilot (AI Copilot in the Web Application) Web Copilot is designed for broader analysis beyond a single incident. It allows users to ask questions across their entire incident history and analyze trends and performance metrics. **Via the web application: open the AI Copilot interface** Ask Rootly AI on the web

### What Web Copilot Can Help With Web Copilot can: * Query incident history using filters such as severity, environment, service, or incident type * Group incidents by attributes like service, severity, or team * Calculate metrics such as incident count, MTTR, and MTTM * Create charts and visualizations * Answer questions about trends and patterns over time Example prompts include: * How many incidents occurred last month? * What is our average time to resolution for severity 1 incidents? * Show incidents grouped by service * Create a chart of incidents over the last quarter Web Copilot maintains conversation context and is suited for analysis, reporting, and operational insights. *** ## Configuration Ask Rootly AI features are available to all customers but must be explicitly enabled. To enable these features, navigate to **Rootly AI** and toggle on **Enable Rootly AI**. Only Admins can configure Rootly AI settings. Then enable the relevant assistants: * **Ask Rootly AI** — enables Slack Copilot * **Rootly AI Copilot** — enables Web Copilot For best results with Slack Copilot, configure **Slack channel message visibility** to **All messages** or **All messages in Public + pinned in Private**. This allows Rootly AI to access sufficient context when answering questions. Rootly AI configuration

Availability in private incidents depends on your Slack channel message visibility settings. For private incidents, AI features are available only when your channel history scope includes private messages. *** ## Troubleshooting Ensure **Ask Rootly AI** is enabled in Rootly AI settings. Verify that you are in an incident Slack channel and mentioning `@rootly` within a thread. For private incidents, confirm that Slack channel message visibility settings allow AI access. Ensure **Rootly AI Copilot** is enabled in Rootly AI settings and that you have access to the Rootly web application. This is expected behavior. Slack Copilot is intentionally scoped to the current incident only. Use Web Copilot for questions about historical incidents or aggregated metrics. # Data Privacy for AI Source: https://docs.rootly.com/ai/data-privacy-for-ai Learn about Rootly's data privacy safeguards for AI features, including what data is shared with OpenAI and how to opt out for your organization. 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 Note: To enable higher quality output [Slack Scope Updates](/ai/slack-scope-updates) are required. # Generated Incident Title Source: https://docs.rootly.com/ai/generated-incident-title Automatically generate concise and descriptive incident titles using AI that analyzes incident context and improves as more details become available. ## Overview Rootly AI can automatically generate concise, descriptive incident titles by analyzing the current context of an incident, including summaries, alerts, and early timeline events. Titles are designed to clearly describe the underlying problem and are kept short for readability across dashboards, timelines, and retrospectives. Generated titles are limited to under 90 characters and can be regenerated as more information becomes available, allowing titles to improve in accuracy as an incident evolves. ## How to Generate an Incident Title You can generate or regenerate an incident title from both the web application and Slack. ### Via the Web Within an incident, click the **magic pen** icon next to the incident title to generate a suggested title using AI. Generate incident title in web UI

### Via Slack In an incident Slack channel, run the `/rootly update` command and click the **Generate with AI** button to generate or regenerate the incident title. Generate incident title in Slack

You may regenerate the title multiple times as the incident progresses to reflect newly available information. ## How It Works Rootly AI analyzes the incident’s current context, which may include: * Incident summary and description * Associated alerts and alert metadata * Initial timeline events * Slack channel messages, when available and permitted by privacy settings Using this information, the AI generates a concise title that describes the problem that caused the incident. If insufficient information is available, Rootly will indicate that more incident context is required before a meaningful title can be generated. ## Configuration Generated incident titles are available to all customers but must be explicitly enabled. To enable this feature, navigate to **Rootly AI** and toggle on **Enable Rootly AI**. Only Admins can enable Rootly AI features. Ensure that **Incident title suggestion** is enabled. For best results, configure **Slack channel message visibility** to one of the following: * **All messages** * **All messages in Public + pinned in Private** This allows Rootly AI to access sufficient context when generating titles. These settings can be updated at any time from **Rootly AI** configuration. Rootly AI configuration

Incident title generation in private incidents depends on your Slack channel message visibility settings. For private incidents, AI features are only available when your channel history scope includes private messages. *** ## Troubleshooting Ensure that Rootly AI is enabled and that **Incident title suggestion** is turned on. Verify that the incident contains sufficient information, such as alerts, timeline events, or a summary. For private incidents, confirm that Slack channel message visibility settings allow AI access. Try regenerating the title after additional incident details become available. Adding more context to the incident summary or allowing relevant Slack messages to be included often improves results. # Incident Catchup Source: https://docs.rootly.com/ai/incident-catchup Quickly get up to speed on an ongoing incident with a private, AI-generated summary of timeline events, status, and key decisions delivered directly in Slack. ## Overview Incident Catchup helps responders quickly understand the current state of an incident when joining an incident Slack channel midstream. Using Rootly AI, responders can request an up-to-date summary that explains what has happened so far, what is currently known, and how the incident is being handled—without needing to read the full channel history. Incident Catchup is available in **Slack only** and is designed specifically for real-time collaboration during an active incident. When a responder runs the catchup command in an incident channel, Rootly generates a concise, AI-powered summary based on the incident’s current context and delivers it as a private, ephemeral message visible only to the requester. ### Via Slack In an incident Slack channel, run one of the following commands: * `/rootly catchup` * `/rootly catch up` * `/rootly catch-up` * `/rootly summarize` All variations trigger the same behavior. Incident catchup command in Slack

The summary is sent as an ephemeral message, meaning it is only visible to you and does not post publicly in the channel. You can run the command multiple times as the incident evolves to receive updated summaries. Incident catchup private summary

## What’s Included in a Catchup Summary Incident Catchup uses the same AI summarization technology as standard incident summaries, with an expanded output. The catchup summary includes: * A single-paragraph narrative describing the incident problem, impact, trigger or cause, and resolution or mitigation steps (when available) * People involved in the incident and their roles (when documented) * An automatically appended attributes list, which may include: * Meeting or bridge links * Severity * Affected environments and services * Selected custom form field values This ensures responders receive both a narrative overview and key structured details in one view. ## How It Works The `/rootly catchup` command uses the same AI service as Incident Summarization and analyzes the incident’s complete current context, which may include: * Incident metadata and attributes * Timeline events * Associated alerts * Action items and follow-ups * Slack channel messages (when permitted by privacy settings) * Meeting transcripts, if available The summary is generated at the time the command is run and reflects the most current state of the incident. Because the message is ephemeral, it does not clutter the incident channel and remains private to the requesting user. ## Permissions To use Incident Catchup, you need the following conditions: * Have permission to generate summaries on the incident, or * Have permission to update the incident If you do not meet these requirements, the command will return an error. ## Configuration Incident Catchup is available to all customers but requires Incident Summarization to be enabled. To enable this feature: 1. Navigate to **Rootly AI** 2. Toggle on **Enable Rootly AI** 3. Ensure **Incident summarization** is enabled Only Admins can manage Rootly AI configuration. To ensure the best results, configure **Slack channel message visibility** to one of the following: * **All messages** * **All messages in Public + pinned in Private** These settings allow Rootly AI to access sufficient Slack context when generating summaries and can be updated at any time from **Rootly AI** configuration. Rootly AI incident catchup configuration

Rootly AI incident catchup configuration

Incident Catchup in private incidents depends on your Slack channel message visibility settings. For private incidents, AI features are available only when your channel history scope includes private messages. ## Troubleshooting Ensure that Rootly AI is enabled and **Incident summarization** is turned on. Verify that you have permission to generate summaries and that you meet the incident permission requirements. For private incidents, confirm that Slack channel message visibility settings allow AI access. Incident Catchup summaries are sent as ephemeral messages and are only visible to you. Check for a private message in the channel rather than a public post. The summary can only include information that exists at the time it is generated. Add or update timeline events, alerts, action items, or incident details, then run the command again to receive an updated summary. # Incident Summarization Source: https://docs.rootly.com/ai/incident-summarization Generate AI-powered summaries of the current incident that capture the problem, impact, resolution steps, and key participants in a single coherent overview. ## Overview Incident Summarization generates a concise, single-paragraph summary of the current incident using the information available at the time of generation. Rootly AI compiles context from incident metadata, alerts, timeline events, action items, and communications to produce a clear narrative that helps responders quickly understand what happened and how it was addressed. Summaries can be generated during an active incident or after resolution. As more details are added over time, the summary can be regenerated to reflect the most accurate and up-to-date state of the incident. ## How to Generate an Incident Summary You can generate or regenerate an incident summary from both the web application and Slack. ### Via the Web Within an incident, click **Generate Summary** to create a summary using Rootly AI. Generate incident summary in web UI

### Via Slack In an incident Slack channel, run `/rootly summary` to generate a summary. You can regenerate the summary at any point as the incident evolves. Generate incident summary in Slack

## What’s Included in the Summary The generated summary is designed to capture the most important incident details in plain language. Depending on what information is available, the summary may include the incident problem, customer impact, trigger or cause, steps taken to mitigate or resolve the issue, and the people involved along with their roles. When configured, the summary may also include an automatically appended attributes list, such as meeting links, severity, affected environments and services, and selected custom form field values. ## How It Works Rootly AI generates the summary by analyzing the incident’s current context. This may include incident attributes such as severity, environments, services, labels, and incident types, along with form field selections, action items, timeline events, and alert data. If permitted by your privacy settings, Rootly AI may also incorporate relevant Slack channel messages and meeting transcripts to improve summary quality and completeness. For best results, configure **Slack channel message visibility** to **All messages** or **All messages in Public + pinned in Private**. If there is not enough information available to produce a meaningful summary, Rootly will indicate that additional incident context is required. ## Configuration Incident Summarization is available to all customers but must be explicitly enabled. To enable this feature, navigate to **Rootly AI** and toggle on **Enable Rootly AI**. Only Admins can enable Rootly AI features. Ensure that **Incident summarization** is enabled. To ensure the best results, configure **Slack channel message visibility** to **All messages** or **All messages in Public + pinned in Private**. This allows Rootly AI to access sufficient context from Slack communications when generating summaries. These settings can be updated at any time from **Rootly AI** configuration. Rootly AI incident summarization configuration

Rootly AI incident summarization configuration

Incident summarization in private incidents depends on your Slack channel message visibility settings. For private incidents, AI features are available only when your channel history scope includes private messages. ## Best Practices Generate an initial summary when the incident starts, then regenerate it as more details emerge. As timeline events, alerts, and resolution steps are added, the summary becomes more accurate and useful. Timeline events, action items, alerts, and relevant Slack communications significantly improve summary quality. Providing clear and complete context helps Rootly AI produce more accurate summaries. The `/rootly catchup` command uses the same summarization technology to help new responders quickly understand long-running incidents without needing to read the full incident history. ## Troubleshooting If you see a message indicating that *“The incident report does not provide enough information to summarize”*, add more context such as an incident summary or description, associated alerts, timeline updates, or action items and try again. In private incidents, confirm that Slack channel message visibility settings allow AI access. The summary can only include information that exists in the incident context at the time it is generated. Add or update key incident details such as impact, mitigation steps, resolution notes, or relevant timeline events, then regenerate the summary. If Slack messages or meeting transcripts are expected to be included, confirm that privacy settings permit their use. # Rootly Meeting Scribe Source: https://docs.rootly.com/ai/meeting-scribe Record, transcribe, and summarize incident bridge calls across Zoom, Meet, Webex, Teams, and GoToMeeting with built-in privacy protections. ## Overview Rootly Meeting Scribe helps capture and preserve critical incident context that would otherwise live only in live bridge calls. When enabled, Meeting Scribe automatically joins incident bridge meetings to record, transcribe, and summarize discussions—making incident communication more accessible, auditable, and actionable. By continuously capturing meeting context, Rootly Meeting Scribe ensures responders who join late, stakeholders who weren’t on the call, and post-incident reviewers all have access to the same shared source of truth. Meeting Scribe supports **Zoom, Google Meet, Webex, Microsoft Teams, and GoToMeeting**, and integrates directly with Incident Summarization, Incident Catchup, and retrospectives. Once enabled, Rootly Meeting Scribe automatically joins incident bridges and captures transcripts and summaries. ## Supported Platforms Meeting Scribe supports the following virtual meeting platforms: * **Zoom** (optional auto-join support) * **Google Meet** * **Webex** * **Microsoft Teams** * **GoToMeeting** Each platform must be integrated with Rootly before Meeting Scribe can be used. ## Configuration To get started, integrate your meeting platform with Rootly. Refer to the [integration documentation](/integrations) for platform-specific setup instructions. Once your meeting platform is integrated: 1. Navigate to **Integrations** and select your meeting platform 2. Toggle on **Meeting transcript and summary** 3. For Zoom, optionally enable **Auto-join bot** to allow the bot to join meetings without manual admission Enable meeting transcript and summary

When enabled, Meeting Scribe is automatically created when a meeting URL is added to an incident. **Important:** Always use the virtual meeting room created by Rootly when an incident starts. This meeting link is pinned at the top of the incident’s Slack channel. Using the Rootly-generated meeting URL ensures the bot can join successfully and associate recordings with the correct incident. ## During Incident Bridges Once admitted to the incident bridge, Meeting Scribe immediately begins capturing the call. During the meeting, the bot will: * Announce its presence to participants * Begin **live transcription** in real time * Record audio (and video when supported) * Identify speakers in the transcript * Stream transcription updates back to Rootly continuously * Post **Slack notifications** to the incident channel when recording starts and when the transcript is ready Live transcription is available during the meeting and is included in AI-powered features such as [Incident Catchup](/ai/incident-catchup). This allows new responders to quickly understand what has already been discussed without interrupting the bridge. Meeting Scribe recording and transcription

Meeting Scribe recording and transcription

## After the Incident After the meeting ends and the incident is resolved, Meeting Scribe processes the captured data and updates the incident with: * **Full meeting transcript** with speaker labels * **AI-generated meeting summary** highlighting key discussion points and decisions * **Optional video recording**, when supported by the platform * **Automatic PII redaction**, removing sensitive data such as emails, phone numbers, passwords, and personal identifiers All artifacts are stored in the **Meeting** tab of the incident and are automatically incorporated into incident summaries, catchup responses, and retrospectives. Meeting transcript and summary in incident

Meeting transcript and summary in incident

## How It Works Meeting Scribe uses the Recall.ai platform to manage meeting participation, transcription, and post-meeting analysis. When a meeting URL is added to an incident: 1. **Bot creation**\ Rootly creates a Meeting Scribe bot scoped to the incident and team. 2. **Bot joins the meeting**\ The bot joins automatically or waits for admission, depending on platform and settings. 3. **Live transcription & recording**\ Real-time transcription is captured during the call, with speaker identification and word-level timing. 4. **Post-meeting analysis**\ After the meeting ends, the bot: * Generates a full transcript * Produces an AI-generated summary * Applies automatic PII redaction * Attaches recordings and artifacts to the incident 5. **Incident integration**\ Meeting transcripts are included in Incident Summarization and Incident Catchup, ensuring meeting context is available across Rootly AI features. The bot may automatically retry joining meetings in certain scenarios (for example, if the meeting has not started yet or the bot is waiting to be admitted), with safeguards in place to prevent excessive retries. ## Recording Sessions A single incident can have **multiple recording sessions** per platform—up to 10 sessions each. A recording session is created each time the bot joins or rejoins a call, which is distinct from the meeting itself. This is useful when: * A bridge call is interrupted and the bot needs to rejoin * The bot is removed and later reinvited to the same meeting * The bot reconnects after a network disruption Each session produces its own transcript, summary, and optional video recording. All sessions are displayed chronologically in the **Meeting** tab of the incident. ### Pause and resume You can **pause** and **resume** a recording mid-call without ending the session. This is useful when sensitive topics arise that should not be captured. Pausing stops transcription and recording; resuming picks up where it left off within the same session. ### Reinviting the bot If the bot leaves or is removed from a call, you can reinvite it from the **Meeting** tab. Reinviting creates a new session, preserving all prior session data. Recording sessions can also be managed programmatically via the Meeting Recordings API. Available operations include listing, creating, pausing, resuming, stopping, and deleting sessions. ## Privacy and Security Meeting Scribe is built with strong privacy and security controls. Meeting data is used only to support your organization’s incident response workflows and is never shared across customers. ### Subprocessors Meeting Scribe relies on the following third-party subprocessors to deliver recording, transcription, and analysis capabilities: | Subprocessor | Purpose | Data processed | | ---------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------- | | [Recall.ai](https://recall.ai) | Meeting orchestration, recording capture, and platform connectivity | Meeting audio/video streams, bot lifecycle events | | [AssemblyAI](https://assemblyai.com) (via Recall.ai) | Speech-to-text transcription, summarization, PII redaction, and speaker identification | Meeting audio for transcription | | [Amazon S3](https://aws.amazon.com/s3/) | Encrypted storage of meeting video recordings | Video files | | [OpenAI](https://openai.com) | AI-powered incident summarization using meeting transcripts ([learn more](/ai/data-privacy-for-ai)) | Redacted transcripts and summaries | All subprocessors are bound by data processing agreements. Data sent to subprocessors is used solely to provide Rootly services and is not used for model training. ### Data flow 1. **Recording** — When a meeting starts, Rootly dispatches a bot via Recall.ai to join the call on the configured platform (Zoom, Google Meet, Microsoft Teams, Webex, or GoToMeeting). 2. **Live transcription** — During the call, the bot streams real-time transcription back to Rootly. Live transcripts are used by features like [Incident Catchup](/ai/incident-catchup) to keep responders informed in real time. 3. **Post-meeting analysis** — After the meeting ends, the full recording is sent to AssemblyAI (through Recall.ai) for final transcription with automatic PII redaction, speaker labeling, and summarization. The PII-redacted transcript replaces the live version. 4. **Storage** — The redacted transcript and summary are stored in Rootly’s database. Video recordings are stored in Amazon S3 with encryption at rest. 5. **AI analysis** — Redacted transcripts feed into Rootly AI features such as Incident Summarization and Incident Catchup, processed via OpenAI under the same [data privacy safeguards](/ai/data-privacy-for-ai) as all other Rootly AI features. ### Automatic PII redaction All transcripts are automatically processed through AssemblyAI’s PII redaction engine before storage. The following categories are redacted: * Account numbers * Banking information * Blood type * Credit card CVV * Credit card expiration * Credit card numbers * Dates * Dates of birth * Driver’s license numbers * Drug references * Email addresses * Events * Gender and sexuality * Healthcare numbers * Injuries * IP addresses * Languages * Locations * Medical conditions * Medical processes * Money amounts * Nationalities * Number sequences * Occupations * Organizations * Passport numbers * Passwords * Person ages * Person names * Phone numbers * Political affiliations * Religions * URLs * US Social Security numbers * Usernames * Vehicle IDs ### Data retention and deletion * **Video recordings** — Stored in encrypted Amazon S3. Users can delete video files at any time while retaining the transcript. Deleted videos are removed from storage immediately. * **Transcripts and summaries** — Stored in Rootly’s database, scoped to the incident and team. Deleted when the associated recording is removed. * **Recall.ai** — Recording media at Recall.ai is subject to a configurable retention window. Once expired or explicitly deleted, data is permanently removed from Recall servers and cannot be recovered. See [Recall.ai Storage and Playback](https://docs.recall.ai/docs/storage-and-playback) for details. ### Security controls * **Encryption at rest** for all stored transcripts, summaries, and video recordings * **Webhook signature verification** (via Svix) ensures authenticity of all Recall.ai events * **Encrypted credential storage** for all meeting platform OAuth tokens * **Incident- and team-scoped access** — meeting data is only accessible within the associated incident and team * **Audit logging** for credential changes and recording deletions * **No cross-customer data sharing** — your meeting data is never used to improve results for other customers ## Usage Limits Teams have monthly usage limits for meeting recording time. Usage is tracked automatically and applies across all supported platforms. If a usage limit is exceeded, the bot will not join new meetings until usage resets or limits are increased. Your Rootly admin can review usage and limits if this occurs. ## Best Practices * Use the Rootly-generated meeting URL pinned in the incident Slack channel * Enable auto-join for Zoom when possible * Admit the bot promptly when it requests access * Monitor the **Meeting** tab for bot status and artifacts * Use Incident Catchup to onboard late responders efficiently ## Troubleshooting Ensure the meeting URL was generated by Rootly and that your meeting platform integration is enabled with **Meeting transcript and summary** turned on. For Zoom, confirm whether auto-join is enabled or manually admit the bot when prompted. Transcripts and summaries are generated after the meeting ends. Wait a few minutes, then check the **Meeting** tab of the incident. Confirm the bot successfully joined and recorded the call. Your team may have exceeded its monthly meeting recording limit. Contact your Rootly admin to review usage or adjust limits. # Mitigation & Resolution Source: https://docs.rootly.com/ai/mitigation-and-resolution-summary Generate concise AI-powered summaries explaining how an incident was mitigated, resolved, cancelled, or closed using Rootly AI in retrospectives and timelines. ## Overview Mitigation and Resolution Summary helps responders quickly document *how* an incident was handled at key status transitions. When an incident is marked as **mitigated**, **resolved**, **cancelled**, or **closed**, Rootly AI can generate a short, clear summary describing the actions taken and the outcome. These summaries are intentionally brief—typically one to two sentences—and are designed to reduce manual write-ups while maintaining accurate incident records for timelines, retrospectives, and reporting. ## How to Generate a Summary Mitigation and resolution summaries can be generated from both the web application and Slack when updating an incident’s status. ### Via the Web When updating an incident’s status to **mitigated**, **resolved**, **cancelled**, or **closed**, click the **Generate with AI** button (or the genius pen icon) next to the status message field. Generate mitigation or resolution summary in web UI

Generate mitigation or resolution summary in web UI

### Via Slack In an incident Slack channel, run `/rootly mitigate` or `/rootly resolve` (also accepts `/rootly mitigated` or `/rootly resolved`). This opens a status update dialog where you can click **Generate with AI** to generate the summary. Generate mitigation or resolution summary in Slack

Generate mitigation or resolution summary in Slack

You can review and edit the generated text before submitting the status update. ## What’s Included Depending on the status transition, Rootly AI generates a concise explanation that focuses on the key actions and outcomes: * **Mitigated** — What specific actions were taken to reduce impact * **Resolved** — How the incident was fully resolved * **Cancelled** — Why the incident was cancelled * **Closed** — Why the incident was closed All summaries are limited to one or two sentences and prioritize clarity and relevance over exhaustive detail. The AI identifies the most important actions from the incident timeline and communications to explain the status transition clearly and consistently. ## How It Works Rootly AI analyzes the incident’s current context at the time of the status update. This may include timeline events, alerts, action items, mitigation or resolution notes, and communications associated with the incident. Using this context, the AI identifies the most relevant actions taken and generates a concise status summary. If there is not enough information available, Rootly will indicate that *“The incident report does not provide enough information to determine how the incident was \[status]”* and additional incident context is required before a summary can be generated. ## Configuration Mitigation and resolution summaries are available to all customers but must be explicitly enabled. To enable this feature, navigate to **Rootly AI** and toggle on **Enable Rootly AI**, then ensure **Mitigation and resolution summarization** is enabled. Only Admins can configure Rootly AI features. For best results, configure **Slack channel message visibility** to **All messages** or **All messages in Public + pinned in Private**. This allows Rootly AI to access sufficient context when generating summaries. Rootly AI mitigation and resolution configuration

Rootly AI mitigation and resolution configuration

Mitigation and resolution summary generation in private incidents depends on your Slack channel message visibility settings. For private incidents, AI features are available only when your channel history scope includes private messages. ## Best Practices * **Generate before finalizing**\ Use the AI-generated summary as a starting point, then review and refine it to match your team’s documentation standards. * **Add context first**\ Ensure the incident includes sufficient timeline events, action items, or resolution notes before generating a summary for best results. * **Edit as needed**\ AI-generated summaries are suggestions—customize them as needed to accurately reflect your team’s incident response. ## Troubleshooting Ensure Rootly AI is enabled and that **Mitigation and resolution summarization** is turned on. Verify that you have permission to update the incident status and that the status you’re selecting is supported (mitigated, resolved, cancelled, or closed). Summaries are intentionally brief and rely on existing incident context. If you see a message indicating insufficient information, add more detail to the incident—such as timeline events, action items, or resolution notes—and try again. You can always edit the generated summary before submitting it. # 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. ## Overview Rootly AI Editor helps you improve your writing across the Rootly platform with quick, AI-powered edits. Available in all text fields, the editor makes it easy to clean up spelling and grammar, adjust length, or simplify language—without leaving your workflow. Whether you're drafting an incident description, writing a customer update, or polishing a retrospective, the AI Editor provides fast, contextual suggestions you can review and apply instantly. Use the Rootly AI Editor to clean up writing in seconds—no context switching, no rewriting from scratch. ## Available Editing Actions Rootly AI Editor supports four editing operations: * **Fix spelling & grammar**\ Corrects spelling mistakes and grammatical errors while preserving your original meaning. * **Make shorter**\ Condenses text by removing unnecessary words and phrases while keeping the intent intact. * **Make longer**\ Expands text with additional clarity or detail when more context is needed. * **Simplify language**\ Rewrites complex or technical language into clearer, more accessible wording. ## How to Use the AI Editor 1. **Highlight text**\ Select any text in a supported text field. 2. **Open the AI menu**\ A floating **Ask AI** button appears near your selection. 3. **Choose an action**\ Select one of the available editing options. 4. **Review the result**\ After generation, you can: * **Accept** the suggestion * **Try Again** to regenerate * **Reject** and keep your original text Using the Rootly AI Editor by highlighting text

Using the Rootly AI Editor by highlighting text

## Where It’s Available The Rootly AI Editor works in all supported text fields across the platform, including: * Incident descriptions and summaries * Communications and status updates * Retrospectives and postmortems * Action items and follow-ups * Custom form fields * Any other rich text or standard text input ## How It Works When you select text and choose an editing action, Rootly AI applies the requested transformation and returns a revised version for your review. All edits are suggestions—you stay in control and decide whether to apply them. ## Configuration Rootly AI Editor is available to all customers but must be explicitly enabled. To enable the editor: 1. Navigate to **Rootly AI** 2. Toggle on **Enable Rootly AI** 3. Ensure **Ask Rootly AI** is enabled (this includes the AI Editor) Only Admins can enable Rootly AI features. Once enabled, no additional configuration is required—the editor is automatically available in supported text fields. ## Troubleshooting Ensure Rootly AI is enabled and that **Ask Rootly AI** is turned on. Verify that you’ve highlighted text inside a supported text field. The AI Editor only appears when text is actively selected. After generating a suggestion, you must click **Accept** to apply the changes. If the result isn’t what you expected, try selecting a different portion of text or click **Try Again** to regenerate. Errors may occur due to timeouts or rate limits. If this happens, wait a moment and try again. If the issue persists, contact Rootly Support. # 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. Document image

# 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. Alert Fields are populated automatically on alert creation or update, depending on the mappings you configure on each Alert Source. *** ### Overview Different observability tools send alerts in very different formats. Alert Fields standardize this by letting you: * Normalize metadata such as environment, severity, region, service, or product area * Route alerts consistently, regardless of which tool sent them * Enrich alerts with structured information to help responders triage faster * Build metrics and dashboards using clean, uniform data * Simplify workflows across multi-tool monitoring environments Alert Fields become part of the alert record itself and are accessible everywhere Rootly evaluates conditions, displays alert information, or triggers automation. *** ### How Alert Fields Work When an alert is ingested: 1. Rootly reads the raw payload from the alert source. 2. Each configured mapping is evaluated using Liquid. 3. The results are stored as `alert_field_values`. 4. The normalized fields are then available throughout the platform. Rootly automatically seeds built-in fields when creating a new Alert Source so you can map values immediately. Alert Fields configuration

*** ### 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: Navigate to the Alert Source and select the Fields tab to view all fields currently mapped. Click Add Field to select an existing field or create a new one.\ New fields immediately become available across all alert sources. Specify a Liquid expression that extracts a value from the alert payload.\ Reference recent alerts using the preview on the right. Click any purple pill in the payload viewer to copy its Liquid expression. All future alerts from this source will populate the field using your mapping. If the title or description fields are left blank, Rootly automatically assigns reasonable defaults (for example, using the subject line for email alert sources). *** ### Using Alert Fields in Alert Routes Alert Fields can be referenced directly in Alert Route conditions.\ This allows your routing logic to be built once and work across all sources, as long as each source maps its payload fields correctly. Examples: * Route all `severity = critical` alerts to the primary on-call * Route `region = EU` alerts to the EMEA team * Route alerts associated with a specific service or component * Route customer-impacting alerts differently from internal signals Learn more on the **[Alert Routes](/alerts/alert-routing)** page. *** ### Using Alert Fields for Auto-Resolution Rules (Email Sources) Email alert sources support auto-resolution rules based on Alert Fields. To set this up: 1. Open the email alert source. 2. Define auto-resolution conditions. 3. Reference Alert Fields in those conditions (e.g., subject text, severity, environment). When a new email alert arrives, Rootly evaluates your conditions and automatically resolves the alert if they match. *** ### Accessing Alert Fields as a Responder Responders can view alert field values in: * **Web:** Alert details panel * **Slack:** Alert details and context blocks * **Mobile:** Alert details in the Rootly mobile app This gives responders immediate access to normalized metadata without reviewing raw JSON payloads. *** ### Best Practices Use shared fields (severity, environment, service, region, etc.) to keep routing behavior consistent across monitoring tools. Test Liquid mappings with real alerts to avoid mismatches or null values. Map differences at the Alert Source layer rather than building multiple routing rules for each provider. Adopt consistent formatting across sources (e.g., PRODUCTION, STAGING, DEV). Alert Fields make workflow triggers more reliable and much easier to maintain. *** ### Troubleshooting * Ensure the field is mapped on the correct Alert Source. * Confirm your Liquid expression returns a value. * Check that the alert payload changed (fields update when payload changes). * Verify your team has Alert Fields enabled. * Confirm the payload path is accurate. * Use purple-pill copy from the alert payload preview. * Add default guards in Liquid where necessary. * Not all providers send uniform payloads. * Some alerts may lack the field entirely. * The mapping may require a conditional or fallback. * Verify the field is correctly populated before routing. * Compare formatting (case sensitivity, whitespace, arrays). * Ensure the route condition exactly matches the field value. *** ### Summary Alert Fields give your organization a unified layer of structured alert data across multiple tools. They power consistent routing, faster triage, stronger automation, and cleaner reporting—making them one of the most important parts of a scalable alerting setup in Rootly. Let them do the heavy lifting so your responders don’t have to. # Alert Grouping Source: https://docs.rootly.com/alerts/alert-grouping Reduce alert noise by automatically grouping related alerts into a single, leader-driven alert based on time windows, fields, and matching attributes. ### Overview Alert Grouping reduces noise and alert fatigue by consolidating related alerts into a **single leader alert** with associated **member alerts**.\ Responders are paged for the leader, while subsequent matching alerts join its group silently. This helps you: * Avoid duplicate pages from multiple monitors on the same issue * Keep alert timelines focused on one “source of truth” * Improve prioritization and reduce cognitive load for on-call responders **Non-paging alerts** (alerts that do not route to any team, service, or escalation policy) are not grouped. Only alerts that participate in routing and paging can form or join groups. *** ### How Alert Grouping Works Each **Alert Group** defines *which alerts belong together* based on: * **Destinations** – what the alert was routed to (team, service, escalation policy) * **Time Window** – how long alerts are considered part of the same episode * **Content Matching** – which alert attributes or payload fields must match When an alert arrives: 1. Rootly finds any **active group** whose rules and time window match. 2. If a match is found: * The existing alert becomes (or remains) the **group leader** * The new alert is added as a **member**, and **does not re-page** 3. If no group matches: * A **new leader alert** and group are created (and the responder is paged according to routing rules) *** ### Group Leaders vs. Members Within a group: * The **leader alert**: * Is the alert that originally caused the page * Acts as the **source of truth** for the group * Drives status and noise updates (e.g., acknowledged, resolved) * **Member alerts**: * Join silently (no additional pages) * Inherit status changes from the leader * Appear on the group timeline for context You can view an alert’s group on the **Alert details page** under the **Alert Group** tab. *** ### When to Enable Alert Grouping Alert Grouping is especially useful when: * A single service has **many monitors** (error rate, latency, CPU, DB health, etc.) * A failure in one component triggers multiple alarms across: * APM, logging, metrics, and infrastructure tools * You want to treat a burst of related alerts as **one incident episode** rather than many independent pages Example: > “Service A has 5 monitors. When it goes down, all 5 fire at once. With grouping, responders get **one page** and then see all related alerts attached to that leader.” *** ### Creating an Alert Group To create a new Alert Group in the web app: * Go to **Alerts → Grouping** * Click **+ New Alert Group** * Enter a **Name** (required) and a **Description** (optional) Destinations define **which routed alerts** are candidates for this group. Under **Destinations**, choose one of: * **All services, teams, and escalation policies** * **All services** * **All teams** * **All escalation policies** * **Select routes** – only alerts routed to specific: * Services * Teams * Escalation policies To group only alerts routed to specific targets: * Choose **Select routes** * Pick the services, teams, or escalation policies you want to include Destination scoping ensures you don’t accidentally group unrelated alerts\ (for example, SRE and Security alerts) into the same cluster. Next, decide how strictly routing must match inside a group. You can choose: * **Groups should only contain alerts for the same route** * Alerts must be routed to the **exact same** service, team, or escalation policy * Example: alerts routed to Service A group only with other Service A alerts * **Groups can contain alerts for any selected route** * Alerts routed to **any** of the selected targets are allowed in the same group * Example: all alerts routed to any SRE team are grouped together Internally, Rootly treats this as: * `same` – route must match exactly * `any` – any eligible route can join the group The **Time Window** defines how long alerts should be considered part of the same group. * Specify the window in **minutes** * Rootly supports values between: * **5 minutes (minimum)** * **7 days (maximum)** The time window is **rolling** and is anchored to the **last alert** added to the group. With a **10-minute** window, the group remains open as long as new alerts keep arriving within 10 minutes of the last one.\ Once 10 minutes pass with no new alerts, a **new group** will be created next time a matching alert arrives. Content Matching defines **what must be similar** between grouped alerts. You can group on: * **Alert Title** – matches the alert’s `summary` * **Alert Description** – the alert’s `description` * **Alert Urgency** – e.g., High, Medium, Low * **Source Link** – the `external_url` (e.g., link to Datadog, PagerDuty, etc.) * **Payload** – any field within the incoming alert payload (via JSONPath) * **Alert Fields** – normalized fields you’ve configured on the Alert Source Operators include: * `is one of` / `is not one of` * `contains` / `does not contain` * `starts with` / `ends with` * `matches regex` * `is empty` To group by a payload field, choose **Payload** and provide a **JSONPath**\ (for example `$.alert.feature`). Alert grouping conditions configuration

For convenience, Rootly provides quick toggles such as **Group by Title** and **Group by Urgency**, which automatically create the appropriate underlying conditions. *** ### Working with Alert Groups Once your Alert Groups are configured and active: * The **first alert** that matches a group becomes the **leader** and triggers paging * Subsequent alerts that match: * Are added as **members** * **Do not** re-page responders * Update the group’s timeline with additional context When you change the leader’s status: * All member alerts’ statuses are updated to match (e.g., resolving the leader resolves its members) * Noise controls on the leader (e.g., marking as noise) propagate to members as they join You can inspect group membership by: * Opening an alert in the web UI * Navigating to the **Alert Group** tab *** ### Example: Grouping Multiple Monitors for One Service Suppose you have the following monitors for `checkout-service`: * Error rate > threshold * P95 latency > threshold * CPU saturation * Database connection errors If the database experiences a serious issue, **all four monitors** might fire. Without grouping: * The on-call may receive 4 pages * Each alert appears as independent noise With alert grouping: * Destination condition: **Select routes → Service: checkout-service** * Route logic: **Groups should only contain alerts for the same route** * Time window: **10 minutes** * Content matching: **Group by Service + Urgency** (or only by destination) Result: * First alert pages and becomes the **leader** * Remaining alerts join silently as **members** * The responder sees one alert with a rich history of related signals *** ### Best Practices * **Start narrow** * Group by **route + short time window** first; broaden later if needed * **Use content carefully** * Combining **Title + Urgency + Payload** can create very precise groupings * Avoid overly broad conditions that might lump unrelated incidents together * **Align with incident semantics** * Think of an Alert Group as “all signals about the same episode,” not “all alerts about the same service forever” * **Regularly review grouped alerts** * Use the Alert Group tab and alert timelines to validate whether groupings still make sense as your monitoring evolves *** ### Troubleshooting * Verify the **Destination** condition includes those routes * Check whether the **route logic** is set to “same route” vs “any selected route” * Confirm the **Time Window** hasn’t expired between alerts * Make sure content matching conditions (Title, Urgency, Payload, etc.) actually match * Narrow the **Destination** scope (e.g., from “all teams” to “specific teams/services”) * Switch from “any selected route” to “same route” * Add or tighten **Content Matching** conditions (e.g., require matching Title and Urgency) * Reduce the **Time Window** duration * The previous group’s time window may have expired * Conditions may have changed (e.g., different title or urgency) * Destination may differ (e.g., different service or team) * This is expected: only alerts that **route to a team, service, or escalation policy** can group * Convert important non-paging alerts into routed alerts via **Alert Routes** if you want them to participate in grouping # Alert Routing Source: https://docs.rootly.com/alerts/alert-routing Use Alert Routes to determine which teams, services, and escalation policies receive incoming alerts from your monitoring tools based on conditions you define. ### Overview Alert Routing ensures that alerts from your monitoring and observability systems reach the correct responders quickly and reliably. Rootly provides a unified routing layer that works across all alert sources, enabling consistent on-call workflows. Rootly supports two routing pathways: 1. **Routing inside your monitoring tool** (Datadog, PagerDuty, Opsgenie, etc.) 2. **Routing inside Rootly** using centralized **Alert Routes** This guide focuses on routing **inside Rootly**. Alert Routes page

*** ### 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 **Tip:** Alert Routes work best when combined with **Alert Fields**, which let you write stable routing logic even when payload schemas vary across providers. *** ### Creating an Alert Route Navigate to **Alerts → Routes** and click **New Route**. Each route requires: #### Name A descriptive title that clarifies the route’s purpose. #### Alert Sources Select one or more alert sources the route should evaluate.\ Sources can be added or removed at any time. See all integrations → [Integrations Overview](/integrations/overview) #### Owning Team Controls who can edit the route. **Permissions:** * Team Admins may only create routes **for their own team**. * Teams can only route alerts **from alert sources they own**. After creating a route, you can begin adding Routing Rules. *** ### Configuring Routing Rules Routing Rules determine *which alerts should page responders* and *where they should go*. Click **Add routing rule** to create one. Routing Rule creation

*** ### Routing Rule Conditions Conditions define when a rule should trigger. #### Select a Field You may reference: * **Alert Fields** (recommended) * **Payload values via JSONPath** Alert Fields ensure your routing logic remains stable even if payload structures change. Condition builder

#### Choose an Operator Supported operators include: * *is one of* * *contains* * *starts with* * *matches regex* * *is empty* * and more Use **regex** when values vary across alert providers and need flexible matching. #### Add Additional Conditions Use **AND/OR** groups to define complex routing logic. #### Live Preview Rootly shows matching historical alerts to validate your logic. Matching alerts preview

*** ### 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. For easier reporting and maintenance, we recommend routing to **teams** or **services**, not directly to escalation policies. Rules may include **multiple destinations**, all of which will be paged when the rule fires. *** ### Completing the Alert Route A route may contain any number of rules.\ Rootly evaluates rules **top-to-bottom**, so ordering matters. Use the rule menu (**… → Reorder rule**) to adjust order. *** ### How Rootly Routes Alerts Rootly evaluates alerts in two sequential stages. #### Stage 1 — Payload-Based Routing If the alert payload contains a **target ID** (team or service), Rootly immediately routes the alert there without evaluating Alert Routes. #### Stage 2 — Evaluate Alert Routes If the alert does not specify a target: #### Evaluate Routes Rootly evaluates **every Alert Route associated with the alert’s source**. #### Evaluate Rules Within each route, rules are evaluated **from top to bottom**. * The first matching rule triggers paging * Rootly stops evaluating additional rules in that route * Other routes referencing the same source will still run If no rules match, the alert becomes a **Non-Paging Alert**. Review these in the Alerts dashboard by filtering **Status → Non-Paging**. Reordering rules

Order rules **most specific → least specific** to avoid unintended matches. *** ### Alert Timeline Every routed alert includes a timeline event documenting: * Which **Alert Route** was applied * Which **Routing Rule** matched * Which **destinations** were paged Alert timeline routing

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 * Ensure the alert source is included in at least one route. * Verify that at least one rule matches the alert. * Confirm the alert payload does not contain a `target_id`, which overrides routing. * Check the rule order; a broader rule may be matching first. * Validate operators and values used in conditions. * Ensure Alert Field mappings are extracting values correctly. * All routes referencing the alert source are evaluated. * Remove unnecessary alert sources from routes. * Tighten condition logic. * Review the alert payload preview (purple pill tokens). * Confirm your JSONPath reflects the actual alert structure. * Use Alert Fields whenever possible. # Alert Statuses Source: https://docs.rootly.com/alerts/alert-statuses Understand how alerts progress through their lifecycle in Rootly, including triggered, acknowledged, and resolved states with valid transitions. ### Overview Every alert in Rootly progresses through a well-defined **finite state machine (FSM)** that dictates how it escalates, notifies responders, synchronizes with alert groups, and ultimately resolves.\ Understanding these states ensures predictable behavior across Routing, On-Call Escalation Policies, Alert Grouping, and integrations like Slack. Rootly alerts can be in one of four statuses: * **open** * **triggered** * **acknowledged** * **resolved** These values are stored on the alert’s canonical `status` enum. All transitions, notification triggers, and timeline events are governed by Rootly’s internal state machine. 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` An alert immediately transitions from **open → triggered** when Routing assigns a team, service, user, or escalation policy. #### **triggered** The alert is **actively paging responders**. This is the state where on-call users are notified based on escalation logic. A triggered alert: * Sends notifications (SMS, push, phone call, Slack) * Can be acknowledged by responders * Can be resolved manually or via automation Allowed transitions: * `triggered → acknowledged` * `triggered → resolved` * `triggered → triggered` (retrigger—e.g., ack timeout, forced escalation, manual actions) All transitions into `triggered` create a `status_update` timeline event. #### **acknowledged** A responder confirmed that they have seen the alert and are working on it. Escalation pauses unless a timeout or retrigger occurs. Allowed transitions: * `acknowledged → resolved` * `acknowledged → triggered` (ack timeout or manual retrigger) If an acknowledged alert hits **acknowledgement timeout**, Rootly automatically **re-triggers** it and resumes escalation. #### **resolved** A terminal state indicating no further action is required. Notifications cease and Rootly records `ended_at`. However, Rootly allows: * `resolved → triggered` (re-open regression, manual retrigger, new escalation) This ensures alerts can be reopened without creating duplicates. Resolved alerts remain visible and analyzable in your alert history, even after re-triggering. *** ### Summary Table of Allowed Transitions | From ↓ | To: triggered | To: acknowledged | To: resolved | | ---------------- | ------------- | ---------------- | ------------ | | **open** | ✅ | — | ✅ | | **triggered** | — | ✅ | ✅ | | **acknowledged** | ✅ (retrigger) | — | ✅ | | **resolved** | ✅ (retrigger) | — | — | Retriggering is a first-class action in Rootly. A retrigger transitions an alert **back to `triggered`**, restarts escalation, and produces appropriate timeline events. *** ### How Rootly Records Status Changes Every transition writes a `status_update` event into the alert timeline. A status event includes: * The new status * The previous status * Who performed the action (user or system) * Metadata such as escalation step, ack timeout, grouping rule, or routing origin These timeline entries power audit trails, analytics, and seamless Slack updates. *** ### Interaction With Alert Grouping When an alert is part of an **Alert Group**, status synchronization is automatic: #### Leader Alert Behavior * The **group leader** is the first alert in the group (the one that paged). * Any change to the leader’s status cascades to all members. * Member alerts update timestamps, noise indicators, and events to match the leader. #### Member Alert Behavior * Members never independently influence group state. * Status changes come exclusively from the group leader. * Retriggering the leader retriggers all members. This ensures responders never lose the true “source of paging,” even when many alerts represent the same event. *** ### Visual Indicators Across Rootly Rootly uses consistent color/status styling across the Web UI, Slack, and Mobile: * 🟥 **Open / Triggered** — Requires action * 🟧 **Acknowledged** — Someone is actively working the alert * 🟩 **Resolved** — Incident has concluded These indicators appear in: * Alert lists * Slack alert threads * Alert details * Incident sidebars when alerts link to incidents *** ### Timestamp Behavior Each alert automatically manages its own lifecycle timestamps: * **started\_at** – Set when the alert is created * **ended\_at** – Set when transitioning into `resolved` * **ended\_at** is cleared if later retriggered This enables clean duration metrics (MTTA, MTTR, paging duration, escalation analytics). *** ### Troubleshooting * It may not match any routing rules * The alert source may not be associated with an Alert Route * No notification target was assigned * The alert may be a non-paging alert * Ensure its status is **triggered**, not **open** * Validate the routing rule actually assigned a team or escalation policy * Confirm notification channels are enabled * Check for quiet-only escalation paths * Review acknowledgement timeout settings * Check whether escalation policies intentionally retrigger * Ensure grouping leader logic isn’t retriggering members This is expected if: * A user manually retriggered * The system detected a regression * A new routing condition matched and assigned a destination *** ### Summary Alert Statuses are the backbone of Rootly’s alerting engine. They define: * How and when responders are notified * How escalation policies activate * How grouping behaves * How alerts appear in dashboards and Slack * How timeline events reflect real-world activity By enforcing strict, predictable transitions—and exposing complete audit trails—Rootly ensures smooth, reliable alerting workflows from ingestion → paging → acknowledgment → resolution → retriggering if needed. # Alert Urgency Source: https://docs.rootly.com/alerts/alert-urgency Learn how Alert Urgencies determine alert priority across Alert Sources, Heartbeats, Live Call Routing, and Escalation Policies for paging rules. ### Overview Alert Urgency controls **how quickly responders must act** when an alert is triggered.\ It’s the core signal Rootly uses to decide: * How aggressively to page on-call responders * Whether notifications should be **audible** (wake people up) or **quiet** * Which escalation paths apply during or outside of **working hours** Configured well, urgency ensures true incidents get immediate attention, while low-impact noise stays non-disruptive.