Skip to main content
The Topology Explorer renders discovered Resource nodes and view-scoped relationships as an interactive map. Resource discovery syncs nodes only; users or the topology agent create relationships in a view.

​
Build a topology view

1

Sync Resource nodes

Connect each cloud account through Connections, then run Resource Discovery. Discovery creates Resource nodes; it does not create relationships.
2

Create a view

Click New View in the Topology Explorer.
3

Add resources

Drag Resource nodes from the left panel onto the canvas.
4

Create relationships

Click and drag between resources to create a relationship. Each relationship stays scoped to the current view.
5

Ask the topology agent

Ask the topology agent to create relationships in the current view when you want agent assistance.
6

Save the view

Name and save your topology view.

​
Resource types

The Topology Explorer supports all major cloud resource types:

​
Views, filters, and export

​
How agents use topology

Every agent can read the topology map and reason over dependency paths:

​
Topology-driven RCA

Topology speeds up root cause analysis because most incidents originate in a dependency, not in the service that alerted. Here is a worked example. The alert: checkout success rate drops to 60%. Checkout logs show scattered timeouts, but the payment service, database, and cache all report healthy.
  1. Start from the alert, not from logs. Ask Alex to show the topology centered on checkout-service.
  2. Trace upstream. The view shows the relationship chain checkout service → payment gateway → external payment API.
  3. Confirm the affected dependency before acting. Ask Alex to show relationships in the current topology view around the payment gateway. Review the view’s gateway-to-external-API relationship with the incident evidence before deciding whether the third-party provider is the origin.
  4. Resolve and document. Fail over to the backup payment provider, then export a topology snapshot for the incident record and postmortem.

​
Reading a cascading failure

When several services fail at once, the topology timeline view shows the origin and the propagation order in a single view, instead of each team investigating its own service. In this cascade, every downstream failure traces back to one expired SSL certificate:
Build your topology and add its scoped relationships before an incident. Resource discovery keeps Resource nodes current for the views you maintain.

​
Other things to ask

  • @alex show downstream dependencies of payment-service — check blast radius before a risky change
  • @oliver map all connections from instance i-0abc123 — scope security exposure during an investigation
  • @tony map every service connecting to the production database — find the source of connection exhaustion
  • @kai show service dependencies and single points of failure in the cluster — harden Kubernetes reliability
  • @alex compare the production topology with the DR region and list missing resources — validate disaster recovery coverage

Resources

View all discovered infrastructure resources

Root cause analysis

Run agent-led RCA on incidents

Assessment

Run infrastructure assessments