Skip to main content

​
Overview

AI connectors link the SaaS tools your team already uses, such as observability platforms, code hosts, documentation systems, work trackers, feature-flag services, and cloud infrastructure. Rootly AI pulls real context from them while investigating an incident, summarizing a timeline, or answering an operational question. AI connectors are one source of context for Atlas, the context layer Rootly AI works from, alongside the Knowledge graph and Memory. They support AI SRE investigations and conversations with Rootly AI. Connector availability varies by surface. When Rootly AI answers a responder-initiated conversation or runs an AI SRE investigation, it looks up just the context it needs from each connected tool and reasons over the results alongside the available alert or incident record. A connector can also expose supported connector actions. Most built-in connectors limit calls to a Rootly-reviewed list of tools. Atlassian, Notion, Linear, Braintrust, Honeycomb, AWS, and the Cloudflare connectors pass through the provider’s full tool catalog, so the scopes, roles, and permissions you grant in the provider set the boundary. The Custom MCP connector limits calls to the tools you allowlist. Any available tool can still accept provider-defined commands or query languages that change data. Provider permissions and provider-side command controls remain authoritative. See each connector guide for its exact access and action model.

​
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. A connector tool can also change data in a provider, within what the connected provider account is allowed to do. Most built-in connectors expose a Rootly-reviewed tool list; Custom MCP tools are customer-allowlisted. Provider-defined commands or query languages can have their own write boundary, documented in the connector guide. Supported connectors can also feed derived facts, such as service identities and dependency relationships, into the Knowledge graph. Data normally flows tool → Rootly AI; a connector action flows Rootly AI → tool.
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 surfaces during an incident once you’ve connected each provider:
Each row is one connector doing its job. Connectors add the most when several run on the same investigation, with GitHub and Sentry and LaunchDarkly answering “was this a source change, a bad exception, or a flag flip?” in one investigation output.

​
Provider Directory

Paths on this page use the consolidated AI SRE navigation, which is rolling out. If your sidebar still shows AI & Agents, open the connector catalog under AI & Agents → Connectors. See Where AI Settings Live.
Members with an Incident Response seat can open AI SRE → Atlas → Connectors to view the connector catalog and status. Where Rootly has enabled AI connectors for the selected team, any member of that team without the seat can open the view-only direct catalog by appending /account/ai-sre/integrations to the Rootly app URL. Only Incident Response Owners, Incident Response Admins, and On-Call Admins can connect or configure connector accounts; those roles can use the same direct path without a seat. See the canonical AI & Agents permissions matrix for the complete role and seat rules. Providers connect through one-click authorization or a provider-specific configuration form. Which provider cards you see depends on what Rootly has enabled for the selected team. The native Azure Monitor connector also requires a one-time Microsoft Entra application enrollment from your Rootly account team before a Rootly admin completes the form.

​
One-Click Providers

Click Connect on the provider card, enter a Connection name, and follow any authorization prompt. DeepWiki requires no vendor account or authorization; the other providers open their authorization flow. Except for DeepWiki, 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 require provider-specific setup before Rootly AI can use them. Each has its own configuration form; the linked providers have dedicated setup guides. Azure Monitor additionally requires the one-time Entra enrollment described in its guide.

AWS

Cloud infrastructure through an IAM role you create, whose policies set what Rootly AI can reach. CloudFormation, Terraform, or manual setup, plus optional EKS support.

Google Cloud

Read-only logs, metrics, alerts, Cloud Run, and Compute Engine across an explicit project selection.

Azure Monitor (Native)

Read-only access to logs, metrics, alerts, deployments, resource health, and control-plane changes with explicit tenant, resource, and capability allowlists.

Datadog MCP

Services, logs, metrics, monitors, APM traces, RUM events, and database signals.

Grafana Cloud

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

Grafana OSS

The same signals from a self-hosted Grafana instance.

New Relic

Entities, NRQL, alerts, and golden metrics across US, EU, and Japan. Connect with OAuth or a user API key.

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

GitLab

Merge requests, pipelines, code, and project ownership. Confirm your GitLab instance, then authorize.

Semaphore

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

Metabase

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

ClickHouse

Direct, bounded SQL across ClickHouse logs, metrics, traces, and operational data.

Splunk

SPL searches, index and sourcetype discovery, knowledge objects, and alert investigation through Splunk MCP Server.

Devin

Private repository knowledge plus permission-controlled Devin platform actions in Slack AI.

Custom MCP

Bring your own publicly reachable MCP endpoint, authorized with OAuth or a bearer key. Add an allowlist of tools Rootly AI can call.
Sumo Logic is also a setup-required observability connector. Its card appears on AI SRE → Atlas → Connectors when available for your team; configure it through the in-app form. If the card is absent, ask your Rootly account team about availability. Sumo Logic can contribute service nodes from OpenTelemetry logs to the Knowledge graph.

​
The Provider Card

The Connectors page lists your existing connections under Connected and the providers you can add under Add a connection, grouped by category. Only providers that support multiple active connections appear there again when you already have one. To add another connection to one of those providers, select it under Add a connection and give it a distinct Connection name. ClickHouse and Azure Monitor (Native) currently allow one active connection per team; an Azure Monitor connection can cover multiple subscriptions in one tenant and its native setup form has no Connection name field. Use the Search sources, signals, or vendors box to filter both lists.
​
The provider can be connected. Click Connect to start the setup flow.
​
Rootly AI can use this connection’s supported tools. Most built-in connectors expose a Rootly-reviewed tool list; Custom MCP tool names are customer-allowlisted. Provider permissions and command controls still govern what an allowed tool can do. Depending on the provider, the card shows Configure or Rename, plus Disconnect on the card or inside Configure. Rename changes the Connection name, which Rootly AI uses to route calls when a provider has more than one connection.
​
The connection exists but setup isn’t complete, for example because authorization failed, a required credential is missing, or a Google Cloud connection has no project selected. Investigations skip a connection in this state.
​
An unconnected source you cannot manage shows You do not have permission to manage this source. instead of a Connect button. Ask an admin to connect the provider, or to grant you the required role.

​
Data Handling

Rootly AI normally queries connectors on demand during an investigation rather than maintaining a full replica of their underlying data. Custom MCP tools are available according to the customer-managed allowlist, including during automatic AI SRE runs; Rootly doesn’t infer whether a Custom MCP tool is a read or write from its behavior. When your Rootly account team has turned on knowledge graph ingestion for your organization, Rootly also reads supported connectors when you connect or re-scope them and again in a daily sweep, then stores derived facts for the Knowledge graph:
  • Datadog, Grafana Cloud, Grafana OSS, New Relic, Dash0, Dynatrace, and Sumo Logic can store service identities and, except for Sumo Logic, observed dependency relationships.
  • AWS can store the account, its regions, and resource inventory.
  • Google Cloud can store selected project, hierarchy, Cloud Run service, and Compute Engine instance facts.
  • GitHub can store infrastructure-as-code facts read from one infrastructure repository that Rootly selects. When exactly one AWS account and no more than one GitHub account are connected, Rootly uses the AWS inventory instead and skips this repository.
Rootly does not store the underlying telemetry or raw query result set as part of these facts. Conversation-history retention varies by connector. Buildkite, DeepWiki, Devin, GitHub, pganalyze, Sentry, Splunk, and Sumo Logic use redacted session history: Rootly replaces raw tool results and the response derived from them with omission markers in durable AI session history. Other connectors can retain outputs and derived responses in conversation history. Connector results can also appear in the LLM traces Rootly logs to its evaluation and observability platform for quality monitoring. See Data Privacy for Rootly AI for the full retention boundary. The early-access Private Agent path additionally stores encrypted transport records. Its transport-log filtering and scheduled cleanup do not exclude or delete downstream AI copies. See Private Agent data and retention. Connector credentials (OAuth tokens, API keys, and service-account tokens) are stored encrypted and used only for the connector’s supported calls. Most calls query the provider. An action-capable connector runs the action through the shared provider account, so the provider’s permissions set what it can change. See each connector guide for the controls that apply. The AWS connector stores no long-lived AWS keys: Rootly keeps the IAM role ARN and an encrypted External ID, and mints temporary credentials for each use. The native Azure Monitor connector stores no customer credential: Rootly stores the tenant and explicit allowlists and uses its own Entra application credential to mint short-lived tokens.

​
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 uses. Pick Atlassian (Jira) or Linear. 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 operate and expand later if Rootly AI’s output is missing signal. The IAM role’s policies are the authoritative limit. When you pick specific services under AWS services the agent can read, Rootly also restricts each session to their Get, List, and Describe calls; with all services allowed, the role’s policies are the only limit.
  • Keep Azure Monitor RBAC and its Rootly allowlist aligned. Grant the Rootly enterprise application only the Azure scopes responders need, then configure the same subscriptions, workspaces, resources, and capabilities on the Azure Monitor (Native) card.
  • Grafana Cloud and Grafana OSS are mutually exclusive in practice. Connect Grafana Cloud if your team is on the managed offering. Connect Grafana OSS if you self-host.
  • Reconnect after major credential rotations. If you rotate the API key or IAM role that Rootly AI uses, the connector stays under Connected but queries fail. Re-authenticate through Configure where the card offers it; otherwise disconnect and connect again.
  • Restrict who can manage connectors. Connectors pull real customer data into investigation context. On the current team, Incident Response Owners and Admins and On-Call Admins can connect, reconfigure, rotate, or disconnect connector accounts without an Incident Response seat. Assign those roles only to users who understand what each connector exposes. See Manage User Permissions.

​
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.
Credentials rotated on the vendor side without the connector being reconnected. Re-authenticate through the card’s Configure screen where it offers one, or disconnect and connect again. If saving the form fails, it shows the reason.
The catalog is the supported set, and some providers appear only after Rootly enables them for your organization. For anything else with a publicly reachable MCP endpoint, use the Custom MCP connector. Approved early-access customers can use Private Agent MCP for an internal-only endpoint. If neither option works, request the provider through support.
Connector management requires an Incident Response Owner or Admin role, or an On-Call Admin role, on the current team. An Incident Response seat is not required. If you have one of those roles without the seat, open the direct connector catalog by appending /account/ai-sre/integrations to the Rootly app URL. Otherwise, ask someone with an eligible role to run the setup or update your role. If you already hold an eligible role and the AWS, ClickHouse, or Azure Monitor (Native) card still shows this message, ask your Rootly account team to enable those connectors for your organization. The provider can separately require an external administrator, OAuth, or IAM permission. See Manage User Permissions.
Rootly AI only reaches for connectors that carry relevant signal for the current investigation. If it isn’t citing your connected Notion, the question probably didn’t call for a Notion lookup. Confirm the connector is under Connected without a Configuration required pill, 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 query third-party tools while investigating. A connector can also expose provider actions that change data, bounded by the connected account’s provider permissions.A single vendor can be all three at once, with independent configurations.
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.
Query responses can appear in retained LLM traces. Buildkite, DeepWiki, Devin, GitHub, pganalyze, Sentry, Splunk, and Sumo Logic use redacted session history, replacing raw results and derived responses with omission markers. Other connectors can retain them. The early-access Private Agent path additionally stores encrypted transport records; see Private Agent data and retention for its separate cleanup boundary. When your Rootly account team has turned on knowledge graph ingestion, supported observability connectors, AWS, Google Cloud, and GitHub can store derived facts, such as service identities, dependency relationships, cloud resources, and infrastructure-as-code facts, for the Knowledge graph. Rootly does not store the underlying telemetry or raw query result set as part of these facts. See Data Privacy for Rootly AI for full detail.
Use the Custom MCP connector for a publicly reachable MCP endpoint, then choose which tools investigations may call. A new Custom MCP connection exposes no tools until you check them. For an internal-only MCP server, approved early-access customers can use Private Agent MCP without exposing the endpoint publicly.Choose OAuth (recommended) or Bearer key when you connect. OAuth requires your server to support OAuth 2.0 and Dynamic Client Registration, because Rootly registers its own client at connect time. Bearer key sends a static key you provide, for servers that don’t support OAuth. See Custom MCP → Before You Start for the OAuth requirements.
Yes. Disconnecting removes the credentials Rootly uses with the vendor and returns the provider to Add a connection. Historical investigations that referenced that connector keep their context, but Rootly AI cannot query the source or run its actions in future interactions. For connectors that contributed derived facts to the Knowledge graph, including GitHub, AWS, Google Cloud, and the supported observability connectors, disconnecting also deletes those facts. Other Rootly data is unchanged.

Atlas Overview

The context layer AI SRE and Rootly AI draw on, and where each part lives.

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.