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. A connector can also expose supported connector actions. Built-in connectors limit calls to Rootly-reviewed tool names; the Custom MCP connector limits calls to the tools you allowlist. A reviewed or allowlisted 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. Supported connector actions can also make an explicit, permission-controlled change in a provider. Built-in tool names are Rootly-reviewed; Custom MCP tools are customer-allowlisted. Provider-defined commands or query languages can have their own write boundary, documented in the connector guide. For supported connectors, optional scheduled ingestion derives facts such as service identities, dependency relationships, and selected cloud project or workload identities. 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 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. Providers connect through one-click authorization or a provider-specific configuration form. 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 and follow any authorization prompt. There are no Rootly configuration fields to fill in. 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 and dedicated setup guide. Azure Monitor additionally requires the one-time Entra enrollment described in its guide.

AWS

Read-only cloud infrastructure via an IAM Role. 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 Managed

The same signals from a self-managed 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.

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 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 use this provider’s supported tools. Built-in tool names are Rootly-reviewed; Custom MCP tool names are customer-allowlisted. Provider permissions and command controls still govern what an allowed tool can do. Every connected card has a Disconnect button. Providers with credentials or scoping options also show Configure.
​
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 rather than maintaining a full replica of their underlying data. Supported connector actions run only after an authorized user asks. For supported connectors, optional fact ingestion also runs scheduled read-only queries. Observability connectors can store derived service identities and dependency relationships; Google Cloud can store selected project, hierarchy, Cloud Run service, and Compute Engine instance facts. 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, 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. Credentials for setup-required connectors (API keys, IAM Role ARNs, service-account tokens) are stored encrypted and used only for the connector’s supported calls. Most calls query the provider. An action-capable connector can use supported built-in tool names or customer-allowlisted Custom MCP tool names with a shared provider account for an authorized action; its guide identifies the Rootly permission and provider-side controls that apply. 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 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.
  • 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 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 with a publicly reachable OAuth 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.
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 query third-party tools while investigating. A connector can also expose supported, permission-controlled provider actions.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.
Query responses can appear in retained LLM traces. Buildkite, DeepWiki, Devin, 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. With optional fact ingestion enabled, supported observability connectors can store derived service identities and dependency relationships, while Google Cloud can store selected project, hierarchy, Cloud Run service, and Compute Engine instance facts. 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 OAuth-based MCP endpoint, then choose which tools investigations may call. For an internal-only MCP server, approved early-access customers can use Private Agent MCP without exposing the endpoint publicly.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 with the vendor and marks the card Available again. 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 authored derived facts—including supported observability connectors and Google Cloud—disconnecting also deletes those facts; 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.