Skip to main content

Overview

Rootly AI is only as good as the context it can reach. Connectors link the SaaS tools your team already uses — observability platforms, code hosts, documentation systems, work trackers, feature-flag services, and cloud infrastructure — so Rootly AI can pull real context from them while investigating an incident, summarizing a timeline, or answering an operational question. When an investigation runs, Rootly AI looks up just the context it needs from each connected tool and reasons over the results alongside the incident record. Every connection is read-only — Rootly AI can query these tools but never modify them.

How Rootly AI Uses Connectors

Each connected tool gives Rootly AI a different kind of signal.
Connectors vs. other integration surfaces
  • Alert Sources — when your monitoring fires, an incident lands in Rootly. Data flows monitoring → Rootly.
  • Regular Integrations — Rootly posts to Slack, creates Jira tickets, pages on-call. Data flows Rootly → tool.
  • Connectors — Rootly AI looks up context in your tools while investigating. For supported observability connectors, optional scheduled ingestion also derives service identities and dependency relationships. Data flows tool → Rootly AI.
A single vendor can appear in more than one surface. Datadog, for example, can be an Alert Source (ingesting Datadog alerts as Rootly alerts) and a Connector (letting Rootly AI read Datadog logs during investigation). The two configurations are separate.

Rootly AI in Action

What Rootly AI actually surfaces during an incident once you’ve connected each provider:
Each row is one connector doing its job. The real lift shows up when multiple connectors run together on the same investigation — GitHub and Sentry and LaunchDarkly answering “was this a deploy, a bad exception, or a flag flip?” in one investigation output.

Provider Directory

Configure connectors in AI & Agents → Connectors. Each provider connects through one of two setup flows — one-click for vendors that support it, or a short configuration form for vendors that need instance URLs, API keys, or IAM roles.

One-Click Providers

Click Connect on the provider card, sign in on the vendor’s authorization screen, and you’re done. No fields to fill in. The authorization flow requires you to be signed in to the vendor’s platform with an account that has permission to grant third-party access. If the Connect button doesn’t open the vendor’s authorization screen, see Troubleshooting below.

Setup-Required Providers

These providers need a short configuration form before Rootly AI can query them. Each has its own dedicated setup guide:

AWS

Read-only cloud infrastructure via an IAM Role. CloudFormation, Terraform, or manual setup — plus optional EKS support.

Datadog

Logs, metrics, traces, dashboards, monitors, and incidents.

Grafana Cloud

Metrics, logs, dashboards, and alerts from your Grafana Cloud stack.

Grafana Managed

The same signals from a self-managed Grafana instance.

New Relic

Entities, NRQL, alerts, and golden metrics. US or EU region.

Dash0

Traces, logs, metrics, service catalog, dashboards, and alerts. OTel-native — pick a region and authorize.

Dynatrace

DQL, problems, entities, Kubernetes events, Davis analysis, and documents through Dynatrace MCP.

Honeycomb

Traces, metrics, logs, BubbleUp, Triggers, and SLOs. Pick US or EU, then authorize — no API key.

Semaphore

Pipelines, job logs, and CI/CD workflow context.

Metabase

Semantic-layer context and current analytics through Metabase’s read-only MCP tools.

Custom MCP

Bring your own OAuth-based MCP endpoint. Add an allowlist of tools Rootly AI can call.

The Provider Card

Every connector renders as a card with a status badge and a primary action.
The provider can be connected. Click Connect to start the setup flow.
Rootly AI can query this provider. The card shows Configure and Disconnect buttons — use Configure to update credentials or scoping, Disconnect to revoke the connection.
Rootly is working on this provider but it isn’t connectable yet. The Connect button is disabled.
Your Rootly account doesn’t have permission to manage this source. Ask an admin to enable the connection, or ask them to grant you the required permissions.

Data Handling

Rootly AI normally queries connectors on demand during an investigation. Rootly does not maintain a persistent copy of the connector’s underlying raw data, such as logs, traces, documents, or code diffs. For supported observability connectors, optional service-context ingestion also runs scheduled read-only queries. Rootly stores the derived service identities and dependency relationships used to connect investigation context, but not the underlying telemetry or raw query result set. Query results do appear in the LLM traces Rootly logs to its evaluation and observability platform — as with every other tool call Rootly AI makes — so a connector response can be retained in trace form for quality monitoring. See Data Privacy for Rootly AI for the retention boundary and what’s included. Credentials for setup-required connectors (API keys, IAM Role ARNs, service-account tokens) are stored encrypted and used only to query that connector on your behalf.

Best Practices

  • Start with the observability and code connectors. These are the two categories that consistently show up in “what caused this?” investigations. Sentry + GitHub covers most product-tier incidents; adding Datadog or Grafana on top covers infrastructure. Everything else layers value on top.
  • Connect the work-tracking connector your team actually uses. Atlassian (Jira) or Linear — pick one. Connecting both when you only use Linear adds a source that never fires and clutters the picker.
  • Don’t over-scope AWS. Rootly AI works fine with narrowly scoped IAM permissions. Start with the AWS services you actually operate and expand later if Rootly AI’s output is missing signal.
  • Grafana Cloud and Grafana Managed are mutually exclusive in practice. Connect Grafana Cloud if your team is on the managed offering. Connect Grafana Managed if you self-host.
  • Reconnect after major credential rotations. If you rotate the API key or IAM Role that Rootly AI uses, the connector status shows Connected but queries fail. Reconnect from the Configure button to re-authenticate.
  • Restrict who can manage connectors. Connectors pull real customer data into investigation context. Limit the “manage connectors” permission to users who understand what each connector exposes.

Troubleshooting

A browser popup blocker is the most common cause. Confirm you’re not blocking popups from rootly.com, then try again. If the screen still doesn’t appear, check whether your account on the vendor’s platform has permission to authorize third-party apps — some organizations restrict this to admins only.
Credentials rotated on the vendor side without the connector being reconnected. Open the connector’s Configure screen and re-authenticate. Any specific failure reason will be surfaced when you save.
The catalog is the current supported set. If a provider is marked Coming Soon, it’s on the roadmap. For anything else, use the Custom MCP connector, which lets you point Rootly AI at any OAuth-based MCP endpoint. If neither option works, request the provider through support.
Your Rootly account role doesn’t include permission to manage connectors. Ask an admin to grant you the permission, or to run the setup on your behalf.
Rootly AI only reaches for connectors that carry relevant signal for the current investigation. If it isn’t citing your connected Notion, that usually means the question didn’t warrant a Notion lookup — not that the connector is broken. Confirm the connector is Connected, then try a prompt that explicitly targets its data (for example, “What does our runbook say about this?” for Notion).

Frequently Asked Questions

All three are ways Rootly connects to third-party tools, but they serve different purposes.Alert Sources bring events into Rootly (a Datadog monitor firing creates a Rootly alert).Regular Integrations let Rootly push actions into third-party tools (creating a Jira ticket when an incident is declared, posting to Slack when severity changes).Connectors let Rootly AI read from third-party tools while investigating.A single vendor can be all three simultaneously — the configurations are independent.
Yes. Alert Sources and regular Integrations don’t grant Rootly AI access to that vendor’s data. If you want Rootly AI to read Datadog logs during investigations, connect Datadog as a Connector too — separate from any Datadog Alert Source you already have.
Rootly does not keep a persistent copy of the underlying raw connector data. Query responses can appear in retained LLM traces. For supported observability connectors with optional service-context ingestion enabled, Rootly also stores derived service identities and dependency relationships, but not the underlying telemetry or raw query result set. See Data Privacy for Rootly AI for full detail.
Use the Custom MCP connector. It lets you point Rootly AI at any OAuth-based MCP endpoint and choose which of its tools investigations may call. Good for internal MCP servers or third-party tools not yet in the built-in catalog.Your server needs to support OAuth 2.0 and Dynamic Client Registration — Rootly registers its own client at connect time rather than using credentials you pre-provision. See Custom MCP → Before You Start for the full requirements.
Yes. Disconnecting removes the credentials Rootly uses to query the vendor and marks the card Available again. Historical investigations that referenced that connector keep their context, but Rootly AI cannot query the source in future investigations. For supported observability connectors, disconnecting also deletes the derived service identities and dependency relationships authored by that connector; other Rootly data is unchanged.

Rootly AI Overview

Parent page for the whole Rootly AI suite.

Data Privacy for Rootly AI

What Rootly AI sees, retention, and model training controls.

Alert Sources

The other integration surface — monitoring tools that ingest events into Rootly as alerts.