> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Telemetry

> Give Nexus the logs, metrics, traces, and dashboards your team relies on.

Telemetry is 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 Nexus can query them directly. It learns the shape of each source, including the queries in your own dashboards. So it queries them the way an engineer who knows your systems would, not with generic guesses.

Once you're connected, Nexus uses your telemetry in two places:

* **During an investigation**: Nexus queries your sources to confirm or rule out a hypothesis. It's the evidence that carries the most weight, and verifying against live system state is what gives an investigation the most [conviction](/investigations/how-investigations-work#building-conviction) in a finding.
* **In the agent**: ask [the agent](/ai/at-incident) what your systems are doing, from Slack, the dashboard, or the mobile app. It queries the same sources to answer, whether or not there's an incident open.

## What you can connect

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

**Providers**

<CardGroup cols={2}>
  <Card title="AWS" icon="aws" href="/nexus/telemetry/aws">
    CloudWatch, EKS, OpenSearch, and RDS.
  </Card>

  <Card title="Google Cloud" icon="cloud" href="/nexus/telemetry/google-cloud">
    Cloud Logging, Cloud Monitoring, Cloud Trace, and GKE clusters.
  </Card>

  <Card title="Grafana" icon="database" href="/nexus/telemetry/grafana">
    Loki, Prometheus, Tempo, Pyroscope, and CloudWatch.
  </Card>
</CardGroup>

**Connect directly**

<CardGroup cols={2}>
  <Card title="Coralogix" icon="database" href="/nexus/telemetry/coralogix">
    Logs, metrics, traces, and dashboards.
  </Card>

  <Card title="CrowdStrike Falcon LogScale" icon="database" href="/nexus/telemetry/logscale">
    Logs and dashboards from your repositories and views.
  </Card>

  <Card title="Datadog" icon="database" href="/nexus/telemetry/datadog">
    Logs, metrics, traces, error tracking, events, and dashboards.
  </Card>

  <Card title="Elasticsearch" icon="database" href="/nexus/telemetry/elasticsearch">
    Logs from your index patterns.
  </Card>

  <Card title="Honeycomb" icon="database" href="/nexus/telemetry/honeycomb">
    Traces and spans from your environments.
  </Card>

  <Card title="Kubernetes" icon="database" href="/nexus/telemetry/kubernetes">
    Live cluster state: what was running, what was failing, and why.
  </Card>

  <Card title="MySQL" icon="database" href="/nexus/telemetry/mysql">
    Read-only SQL queries.
  </Card>

  <Card title="New Relic" icon="database" href="/nexus/telemetry/new-relic">
    Logs, metrics, APM traces, and dashboards.
  </Card>

  <Card title="OpenSearch" icon="database" href="/nexus/telemetry/opensearch">
    Logs from your index patterns.
  </Card>

  <Card title="PostgreSQL" icon="database" href="/nexus/telemetry/postgresql">
    Read-only SQL queries.
  </Card>

  <Card title="Splunk" icon="database" href="/nexus/telemetry/splunk">
    Logs, metrics, and dashboards.
  </Card>

  <Card title="Splunk Observability Cloud" icon="database" href="/nexus/telemetry/splunk-observability-cloud">
    Metrics and dashboards.
  </Card>

  <Card title="Sumo Logic" icon="database" href="/nexus/telemetry/sumo-logic">
    Logs and metrics.
  </Card>
</CardGroup>

Connecting an HTTP API or an MCP server works differently: those are [connectors](/investigations/extensions/connectors), which give an investigation tools beyond telemetry.

## How telemetry is modeled

Some tools host others. Connect **Grafana** once, and Nexus can discover the data sources behind it: Loki for logs, Prometheus for metrics, Tempo for traces, and more. **AWS** works the same way: it exposes accounts and regions, then CloudWatch, EKS clusters, OpenSearch domains, and RDS databases. So does **Google Cloud**, which exposes projects, and the GKE clusters running in them. You connect the provider once, then choose which of the discovered data sources to enable.

The Grafana stack is connected this way only: there's no separate Loki, Prometheus, Tempo, or Pyroscope entry in the connect flow. Connect Grafana, and they come with it, using Grafana's own credentials.

Other tools are connected directly and stand on their own. Some data sources work either way: a PostgreSQL database or a Kubernetes cluster can be connected directly or discovered behind a provider.

### Capabilities

Each data source provides one or more capabilities, which is what Nexus uses it for:

| Capability | What it answers                                                                              |
| ---------- | -------------------------------------------------------------------------------------------- |
| Logs       | What was the system logging around the time of the incident?                                 |
| Metrics    | Did error rates, latency, or saturation change?                                              |
| Traces     | Where did a slow or failing request spend its time, and which requests hit the same problem? |
| Profiles   | Where did CPU and memory actually go?                                                        |
| Kubernetes | What was running, and what was failing, in the cluster?                                      |
| SQL        | What does the data in this database actually show?                                           |
| Dashboards | What do the views my team already built reveal?                                              |

## Enabling data sources

Each data source can be enabled or disabled, which controls whether Nexus can use it. Which state it starts in depends on how the data source arrived:

* Data sources discovered through a provider start disabled, so you opt in deliberately.
* Data sources you connect directly start enabled.

Either way, you can turn each one on or off from your [telemetry settings](https://app.incident.io/~/nexus/telemetry). Review the list after connecting a provider and enable the sources your team uses.

## Learning your stack

Nexus doesn't query blindly. For each connected data source we continually learn how to query it well in your environment. We discover its real labels and fields, learn the query patterns in your own dashboards, and remember 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](/nexus/telemetry/how-it-works) for the full picture.

<Tip>
  Connect the data sources and dashboards your team reaches for during real incidents. The more your setup reflects your
  real workflow, the better Nexus learns to query it.
</Tip>

## FAQs

<AccordionGroup>
  <Accordion title="Do you store or ingest our telemetry data?">
    No. We connect to the observability tools you already run and query them on demand; there's no need to ship
    telemetry to us or keep a copy. The goal is to become an expert user of your existing stack, not to replace it.
  </Accordion>

  <Accordion title="Can you query self-hosted or private telemetry?">
    Yes. For a data source that isn't exposed to the public internet, such as a Loki, Prometheus, or VictoriaMetrics
    instance inside your VPC, run a [proxy](/integrations/proxy) in your network and attach the data source to it.
    Queries travel over an outbound-only, encrypted tunnel, so you never open inbound ports.
  </Accordion>

  <Accordion title="Do we need to build a service catalog first?">
    No. Nexus learns each source by exploring it and making test queries, so connecting the source is enough to get
    started. A well-built Catalog can improve results, but it isn't required.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="How telemetry works" icon="magnifying-glass" href="/nexus/telemetry/how-it-works">
    Routing, query planning, guidance, and memory.
  </Card>

  <Card title="How investigations work" icon="https://mintcdn.com/incidentio-18bb4170/sRvzAk-yzIz8QOX3/icons/investigations.svg?fit=max&auto=format&n=sRvzAk-yzIz8QOX3&q=85&s=cf0971ce90cba6e9bee684c6deca9a51" href="/investigations/how-investigations-work#querying-your-telemetry" width="40" height="40" data-path="icons/investigations.svg">
    How telemetry queries become evidence in a finding.
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="/nexus/telemetry/troubleshooting">
    Why a data source's queries fail, and what to do about it.
  </Card>
</CardGroup>
