Skip to main content
Telemetry gives investigations the hard signal that explains what your system was actually doing — error spikes, latency changes, log lines, and the dashboards your team already trusts. Connect the observability tools your responders reach for during an incident, and investigations can query them directly to confirm or rule out a hypothesis. Because an investigation learns the shape of each source, including the queries in your own dashboards, it queries them the way an engineer who knows your systems would — not with generic guesses.

What you can connect

Connect a provider to bring several data sources at once, or connect a data source directly. Providers

Grafana

Loki, Prometheus, Tempo, Pyroscope, and CloudWatch.

AWS

CloudWatch metrics and logs.

Google Cloud

Cloud Logging, Cloud Monitoring, and Cloud Trace.
Connect directly

Datadog

Logs, metrics, traces, and error tracking.

Elasticsearch

Logs from your index patterns.

Honeycomb

Traces and spans from your environments.

PostgreSQL

Read-only SQL queries.

MySQL

Read-only SQL queries.

HTTP API

Any HTTP API you describe.

MCP server

Any remote MCP server.

How telemetry is modeled

Some tools host others. Connect Grafana once, and investigations can discover the data sources behind it — Loki for logs, Prometheus for metrics, Tempo for traces, and more. The same pattern applies to AWS (which exposes accounts and regions) and Google Cloud (which exposes projects). You connect the provider once, then choose which of the discovered data sources to enable. Other tools — Honeycomb, Elasticsearch, your databases — are connected directly and stand on their own.

Capabilities

Each data source provides one or more capabilities, which is what investigations actually use it for:
CapabilityWhat it answers
LogsWhat was the system logging around the time of the incident?
MetricsDid error rates, latency, or saturation change?
TracesWhere did a slow or failing request spend its time?
SQLWhat does the data in this database actually show?
DashboardsWhat do the views my team already built reveal?

Enabling data sources

Each data source has an enabled toggle that controls whether investigations can use it. When a provider is first connected, some data sources are enabled by default and others are left off so you stay in control:
  • Read-only and low-risk sources (such as traces) tend to be on by default.
  • Sources that allow broader querying (such as logs) tend to be off by default, so you opt in deliberately.
Review the enabled data sources after connecting a provider and turn on the ones your team uses.

Learning your stack

Investigations don’t query blindly. For each connected data source we continually learn how to query it well in your environment — discovering its real labels and fields, learning the query patterns in your own dashboards, and remembering what worked in past investigations. That’s what lets a query filter on the attributes you actually use and reach for sensible defaults, instead of guessing against an unfamiliar stack. Routing a question to the right data source, translating it into the right query language, and the guidance and memory the system builds over time all sit behind this. See How telemetry works for the full picture.
Connect the data sources and dashboards your team reaches for during real incidents. The more your setup reflects your real workflow, the better investigations learn to query it.

How telemetry works

Routing, query planning, guidance, and memory.

How investigations work

How telemetry queries become evidence in a finding.