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

# Related Incidents

> Rootly AI surfaces genuinely related past incidents with a one-line explanation of why each matches, so responders can learn from history in Slack.

## Overview

Related Incidents connects the incident you're working on to relevant incidents from your team's history. When you ask Rootly AI about an incident, it returns a short, ranked list of past incidents that share a concrete overlap — the same failing component, a matching symptom or error, or a common dependency — along with a one-line explanation of **why** each incident matches.

Instead of relying on memory ("didn't this happen last quarter?") or manual searching, responders get the most relevant precedents in the incident channel, each linked to its incident page and Slack channel so they can dig into how it was investigated and resolved.

<Note>
  Related Incidents is deliberately conservative. Only high-relevance matches are shown, sorted by relevance — and if nothing in your history is genuinely related, Rootly AI says so rather than padding the list with weak matches.
</Note>

## How to Find Related Incidents

In an incident channel, ask [Rootly AI in Slack](/ai/rootly-in-slack/overview) for related incidents. For example:

* `@Rootly are there any related incidents?`
* `@Rootly has something like this happened before?`
* `@Rootly find past incidents involving this service.`

Rootly AI replies with a structured card for each related incident (up to three), showing why it matches and where to learn more.

## What's in Each Suggestion

Each related incident card includes:

* **Incident title and link** — jump straight to the incident page
* **Why it matches** — a one-line explanation of the concrete overlap with your current incident
* **Slack channel** — the related incident's channel, so you can review the discussion without leaving Slack
* **Responders** — who worked the incident (commander first), so you know who to ask
* **Key facts** — severity, time to resolution, and when it happened
* **Feedback buttons** — 👍 / 👎 to tell Rootly whether the suggestion was actually useful

Feedback is recorded and used to measure and improve suggestion quality for your organization. It is never used to train models for other customers.

## How It Works

When Rootly AI is enabled, Rootly builds a vector embedding of each incident from its title, summary, and attributes (severity, services, environments, incident types, and other metadata). The embedding is kept up to date as the incident evolves — updates to the incident, its timeline, action items, attachments, and other associated records refresh it automatically.

When you ask for related incidents, Rootly runs a two-stage funnel:

1. **Retrieval** — the current incident's embedding is compared against your team's past incidents to gather a pool of candidates.
2. **Re-ranking** — an LLM reviews the candidates against the full incident context and selects only the ones with a genuine, concrete relationship, writing a short explanation for each. Shared boilerplate or superficially similar wording is not enough to qualify.

The top results are returned sorted by relevance. Because the final selection comes from an LLM judging real relatedness — not just word similarity — an empty result is a valid and expected answer when nothing in your history is truly related.

<Note>
  When Related Incidents is first enabled, embeddings for your historical incidents are built gradually in the background. Results improve over the first hours as your incident history finishes indexing.
</Note>

## Configuration

Related Incidents is part of Rootly AI and must be enabled by an Admin.

1. Navigate to **AI & Agents** in the main navigation.
2. Under **Features**, toggle **Related incidents** on or off.

For organizations starting a new trial, Related Incidents is enabled by default alongside the other Rootly AI features. Existing organizations can turn it on (or off) at any time — disabling the toggle immediately stops Rootly AI from returning related incidents.

## Privacy and Data Handling

* **Your data stays yours** — related incidents are only ever drawn from your own organization's incident history, and your incident data is used solely to deliver Rootly AI functionality for your organization — never to train models for other customers. See [Data Privacy for Rootly AI](/ai/data-privacy-for-rootly-ai).
* **Private incidents** — results respect each user's existing Rootly permissions. If you can't see a private incident in the web app, it will never appear in your related incidents results.

## Best Practices

<AccordionGroup>
  <Accordion title="Keep incident metadata accurate" icon="list-check">
    Related Incidents matches on incident content and attributes — title, summary, severity, services, environments, and incident types. Incidents with accurate metadata produce noticeably better matches, both as the incident you're asking from and as candidates in your history.
  </Accordion>

  <Accordion title="Ask early in the incident" icon="clock">
    Checking for related incidents during triage is the highest-leverage moment — a strong match can point you at a known cause, a proven mitigation, or the person who fixed it last time.
  </Accordion>

  <Accordion title="Use the feedback buttons" icon="thumbs-up">
    The 👍 / 👎 buttons on each suggestion are the main signal for measuring whether suggestions are genuinely useful for your organization. A quick reaction takes a second and directly informs quality improvements.
  </Accordion>
</AccordionGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Why did Rootly AI return no related incidents?" icon="circle-question">
    An empty result usually means exactly what it says — nothing in your team's history clears the relevance bar. Related Incidents deliberately abstains rather than showing weak matches. If the feature was enabled recently, historical incidents may still be indexing; try again later. Also confirm **Related incidents** is enabled in your Rootly AI settings.
  </Accordion>

  <Accordion title="Why can't I see an incident I know is related?" icon="eye-slash">
    Results are filtered by your own permissions — private incidents you don't have access to are excluded. Very old incidents may also fall outside the default 180-day lookback window used during triage. Weak metadata on either incident (a vague title, no summary, no services) can also keep a genuinely related incident below the relevance bar.
  </Accordion>

  <Accordion title="How is this different from the MCP server's find_related_incidents tool?" icon="circle-info">
    The [Rootly MCP Server](/integrations/mcp-server) exposes a `find_related_incidents` tool that uses TF-IDF text similarity — a separate, simpler mechanism for MCP clients. The Related Incidents feature described on this page uses incident embeddings with LLM re-ranking and is available through Rootly AI in Slack.
  </Accordion>

  <Accordion title="What happened to the Similar Incidents tab?" icon="clock-rotate-left">
    The legacy Similar Incidents tab on the incident page has been removed and is replaced by Related Incidents. Old links to the tab redirect to the incident page.
  </Accordion>
</AccordionGroup>
