Skip to main content
The Knowledge graph is the part of Atlas that records what exists in your environment and how it connects: services, datastores, cloud resources, and the dependencies between them. Rootly builds it from facts that your Rootly services, catalogs, and supported AI connectors report, and every relationship lists the sources that assert it. Rootly AI SRE reads the graph during investigations to learn what a failing service is, what it depends on, and what depends on it. AI SRE is the only Rootly AI feature with tools to query the graph. You can explore the same data on the Knowledge graph page.
The Knowledge graph requires AI SRE, which your Rootly account team enables for each team. When AI SRE isn’t enabled for the selected team, AI & Agents → AI SRE shows a waitlist page. Within AI SRE, the Knowledge graph page and the collection of graph data are enabled separately and may not be on for every team; your Rootly account team turns them on. Viewing the page also needs an Incident Response seat on the currently selected team. See Getting Started for enablement and Manage User Permissions for access.

​
Open the Knowledge Graph

The docs file the Knowledge graph under Atlas, but the product places it on the Atlas page.
These paths use the consolidated AI SRE navigation, which is rolling out. If your sidebar still shows AI & Agents, open the card under AI & Agents → AI SRE. See Where AI Settings Live.
1

Open the Atlas Page

Go to AI SRE → Atlas.
2

Open the Knowledge Graph

Select the Knowledge graph card. The page opens at AI SRE → Atlas → Knowledge graph.
If the other AI SRE cards appear but Knowledge graph doesn’t, the page isn’t enabled for the selected team. AI SRE can still use graph data in investigations when data collection is on, even if the page isn’t shown.

​
What the Graph Records

The graph is assembled from individual facts rather than stored as one model. Each fact says one thing about an entity (what it is, one of its attributes, or its relationship to another entity) and records the source that reported it. Rootly rebuilds the page from these facts each time you load it.

​
Node Types

​
Relationship Types

The graph supports twelve relationship types: depends on, uses, consumes, runs on, is owned by, is a logical member of, acts as, can assume, reports as, triggers, notifies, and watches. The page draws a relationship only when both ends are graph entities; is owned by can appear when its owner is another graph entity. The Relationship types filter lists only the types actually drawn in your graph. Different tools describe the same dependency with different words. Any mix of depends on, uses, and consumes between the same two nodes merges into one relationship, so a dependency that your configuration declares and your telemetry observes shows up once, with both sources. Some facts are stored but not drawn as relationships:
  • Containment, such as a resource inside an AWS account or a Google Cloud project.
  • Cloud regions and aliases.
  • Ownership from your catalog. Those owners are people and teams rather than graph entities, so the page doesn’t draw an is owned by edge to them. AI SRE can still read those owner facts during an investigation.

​
Evidence Labels

Each relationship in a node’s detail panel shows how it’s known and which sources assert it, for example Observed · Datadog, Declared · AWS, Capability · AWS, or Corroborated · AWS, Datadog. The page shows sources and evidence labels, not confidence scores.

​
Aliases

The same resource often has a different name in each tool. Aliases record those names so facts from different tools land on one node. Each Rootly service contributes aliases from its Datadog ID, GitHub repository name, PagerDuty ID, and Kubernetes deployment name, so an alert that uses any of those names resolves to the same service.

​
Environments

Only two sources set a node’s environment:
  • Infrastructure as code, from a directory in the file path, such as aws/staging/.
  • AWS, from a resource’s Environment, Env, or Stage tag.
Both recognize production, staging, development, sandbox, and qa, including the short forms prod, stage, and dev. Nodes with no recognized environment appear as Unspecified in the Environment filter.

​
Where the Data Comes From

The graph reads only the sources below. The Data sources section of the page uses these same names. Google Cloud facts link resources to their project through containment, which the page doesn’t draw. Google Cloud nodes therefore appear without relationships unless another source connects them. Other AI connectors, such as Sentry, GitLab, Linear, and Notion, don’t add to the graph. Neither do Custom MCP connectors or private agents. AI SRE can still query them live during an investigation. Past incidents don’t build the graph either. Lasting lessons from investigations and past incidents are proposed as notes in Memory. You can connect sources in any order. When the set of declared nodes changes, Rootly re-reads the observed sources so their relationships attach to the right nodes.

​
How Infrastructure as Code Is Read

Rootly reads infrastructure as code from one repository per connected GitHub AI connector. If the team has multiple GitHub connections, graph ingestion processes each connection independently. Within each GitHub App installation, Rootly picks a repository whose name suggests infrastructure, such as terraform, infra, helm, k8s, or gitops. Private repositories rank before public ones, and non-forks rank before forks. If several repositories have the same rank, Rootly uses the first one returned by GitHub; there is no manual repository picker or guaranteed tie-break order. To control the selection, grant each GitHub App installation access only to the intended repository or a small set of candidates. Rootly reads the repository two ways. A deterministic pass extracts declared resources and Terraform references, written as uses relationships. A model then interprets the files, and Rootly drops any fact from that pass that doesn’t cite a file it read.
When your organization has exactly one working AWS connection and no more than one GitHub connection, Rootly skips infrastructure as code and describes your infrastructure from the AWS inventory instead.

​
When the Graph Updates

The graph refreshes from its sources in the background. Loading the page doesn’t start a refresh, and the page has no refresh button.
  • Connecting a source. Connecting or changing the scope of a supported AI connector refreshes that source. Connecting Datadog also refreshes Service catalog.
  • Changing a Rootly service or catalog. Creating a service, or changing its name, slug, Datadog ID, GitHub repository name, PagerDuty ID, or Kubernetes deployment name, refreshes Service catalog. So does changing a catalog property on a service or a custom catalog entity.
  • Once a day. Rootly re-reads infrastructure as code, AWS, Google Cloud, Datadog, Grafana Cloud, Grafana, New Relic, Dash0, Dynatrace, and Sumo Logic. Service catalog isn’t part of the daily refresh because service and catalog changes trigger it.
A refresh for one source, such as a catalog edit or reconnecting a telemetry or cloud connector, finishes within minutes. A run that reads the infrastructure-as-code repository, including reconnecting GitHub, can take an hour or more.

​
Edits That Don’t Trigger a Refresh

Editing a service’s dependency list or its owners directly on the service doesn’t refresh the graph. Those changes reach the graph the next time something else refreshes Service catalog. Owners and dependencies set through catalog properties do trigger a refresh.

​
Disconnecting a Connector

Disconnecting an AI connector deletes the facts it contributed as part of the disconnect. Facts that AI SRE investigations recorded through that connection go with it. Service catalog facts stay when you disconnect Datadog. Deselecting a Google Cloud project removes that project’s facts right away.

​
How Deleted Resources Leave the Graph

Sources differ in whether a refresh removes resources they no longer report. Deleting a Rootly service therefore doesn’t remove its node.

​
When Sources Disagree

Two tools will eventually describe the same thing differently. The graph settles attributes and relationships in different ways. Attributes pick one value. Each attribute, such as kind, tier, environment, region, or repository, shows one value on the page. Source authority decides first, then confidence. A lower-ranked source can fill in an attribute nothing above it reports, but it can’t override one.
  • For what a resource is (its kind, component type, tier, and environment), declared sources outrank observed ones: Infrastructure as code, Service catalog, AWS, and Google Cloud come before any telemetry source.
  • For other attributes, the order is Infrastructure as code, Service catalog, Datadog, AWS, Google Cloud, Grafana Cloud, Grafana, New Relic, Dash0, Dynatrace, Sumo Logic, then AI SRE investigations. The Data sources section lists sources in this order.
Relationships are merged. Drawn relationships from every source are combined, never ranked against each other. A relationship lists every source that asserts it and carries the strongest evidence label among them. A dependency your telemetry observed stays in the graph even when your infrastructure as code doesn’t declare it, and declaring something different in infrastructure as code doesn’t remove it. Owner facts from every source remain available to AI SRE, but people and team owners from the catalog are not drawn as graph edges. Some conflicts are flagged. A banner reading Some graph data needs attention appears when a node claims two environments, or when an observed dependency starts from a datastore. It lists how many environment conflicts and resource type conflicts it found. Correct the value in the source that reports it. Because most sources don’t remove an old value on refresh, the conflict can stay until the old fact leaves the graph. See Correct the Graph.

​
Explore the Graph

The page is view-only. Filters, selections, and views aren’t saved, and nothing you do on the page changes the graph or your tools. Hidden types, collapsed regions, and the environment filter apply everywhere: search, the table, relationship lists, and paths. Select a node on the graph, in search, or in the table to open its detail panel. The panel shows the node’s type, name, ID (such as svc:checkout), attributes, and its Outgoing relationships and Incoming relationships with their evidence labels. From there:
  • Explore relationships focuses the graph on the node’s neighborhood, with Depth from 1 to 3 and a direction of Outgoing, Incoming, or Both.
  • Find a path from here finds the shortest path to a destination you choose from search or the table, under the current filters. Exit path view returns to the graph.
When the graph has more than 1,200 nodes, the page draws the most connected ones and shows a Top N shown badge. The conflict banner still describes the full graph. When no source has contributed yet, the page shows No knowledge graph data is available yet with a Connect a data source button that opens the Connectors page.

​
Correct the Graph

You can’t edit the graph on the page. Fix the data in the source that reports it, then let the next refresh pick it up. For most sources, a refresh adds the new value but doesn’t remove the old one. The exceptions are an AWS resource’s region and the dependencies Datadog, Dash0, and Dynatrace observe for a service they report again. A removed catalog dependency, or a changed tier or environment, can stay in the graph beside the new value until the source is disconnected, or until the resource leaves an AWS, Datadog, Google Cloud, Dynatrace, or Dash0 read. For knowledge no source can express, such as which dependency matters most under load, write it in AI SRE instructions, or in a rule’s instructions on Investigation Rules when it applies to one class of alerts.

​
How AI SRE Uses the Graph

AI SRE reads the graph as context for an investigation. It queries the graph rather than reading it whole.
  • Early in the investigation, it looks up the services and resources the alert or incident names, using any alias a tool knows them by. For each match it reads what the graph records: what the entity is, what it depends on, what depends on it, and where its telemetry lives.
  • While it investigates, it can look up another entity by any of its names, list entities by kind, region, or owner from the stored graph instead of querying your cloud directly, and map what an entity depends on (candidate causes) and what depends on it (scope of impact). By default, that mapping follows dependencies rather than Capability relationships, so a shared security group doesn’t make every service look affected.
  • As it reads telemetry, it records where a node’s metrics, logs, or spans live. These facts appear under the AI SRE investigations source. Investigating a Datadog alert can also add a node, shown under Datadog, for a workload no source has reported yet.
The graph never writes back to the tools it was built from. See Evidence Sources for how AI SRE combines the graph with live queries to your connected tools. When Generate with AI is available on the AI SRE Instructions page, it also draws on Knowledge graph facts to draft your instructions. See Instructions.

Atlas Overview

Rootly’s AI layer and the ways people and applications use it.

AI Connectors

Connect the observability, cloud, and code providers that feed the graph.

Memory

What AI SRE remembers about your systems, and how to curate it.

Evidence Sources

What an investigation reads, and how it uses the graph alongside live queries.

​
Frequently Asked Questions

No. Rootly builds the graph from your Rootly services and catalogs and from the supported AI connectors you’ve connected. Curate your catalog and infrastructure as code first. They outrank telemetry on what a resource is and on its attributes.
The card appears on AI SRE → Atlas (AI & Agents → AI SRE if your sidebar doesn’t have an AI SRE item) only when AI SRE and the Knowledge graph page are enabled for the selected team, and you need an Incident Response seat on that team. If the AI SRE page shows a waitlist, AI SRE isn’t enabled yet. Contact your Rootly account team to turn these on.
Graph data collection may not be enabled for your organization, you may not have connected a supported source yet, or the first refresh may still be running. A refresh that reads infrastructure as code can take an hour or more. Check Data sources on the page to see which sources have contributed.
No. The page is view-only. Fix the data in the source that reports it, such as the Rootly service, a catalog property, your infrastructure as code, or a cloud tag. See Correct the Graph.
Service catalog only adds facts, and it can’t be disconnected, so a deleted Rootly service’s node stays in the graph. Infrastructure as code, Grafana Cloud, Grafana, New Relic, and Sumo Logic also only add facts, which leave only when you disconnect the source.
Yes, if they appear in your Rootly services or catalogs, in your AWS or Google Cloud inventory, or in the infrastructure-as-code repository Rootly reads. A service no source reports doesn’t appear.
No. Only the sources listed in Where the Data Comes From contribute. AI SRE can still call the tools you’ve selected for a Custom MCP connector during an investigation.
It adds facts: where a node’s telemetry lives, and sometimes a node for a workload that a Datadog alert names before any source has reported it. Nothing from the graph is written back to your tools.