# Checkly Traces

**Source**: https://www.checklyhq.com/product/traces/

> Trace the root cause of every failure. Checkly Traces connects OpenTelemetry spans to your synthetic checks, so a failed check opens straight to the trace that explains it — checks and traces in one place.

Checkly Traces is OpenTelemetry-native. It captures only the spans tied to a failed synthetic check, giving you the exact context to debug a failure without the volume and cost of sample-everything tracing.

## What it does

- **Find the root cause, instantly**: Jump from a failed synthetic check directly to the exact span where it broke. No dashboard-hopping, no service-blame guessing.
- **Cut MTTD and MTTR with Rocky AI**: Rocky AI reads correlated traces and returns plain-language root cause analysis, so teams resolve incidents in minutes instead of hours.
- **A failed check, already correlated to its trace**: Every check result, test session, and editor run links to its OpenTelemetry trace, and failed checks auto-correlate to the exact causative spans.
- **Instrument once with OpenTelemetry, no vendor lock-in**: Use your existing OTel SDKs, point collectors at Checkly, and keep exporting traces to Grafana Tempo, Honeycomb, or Datadog.
- **Export to the observability tools you already run**: Native OTLP ingestion supports OpenTelemetry, Grafana Tempo, Honeycomb, Datadog, Coralogix, and any OTLP-compliant backend.

## Key facts

- Because Checkly only records the interactions it generates, trace volume drops sharply versus sample-everything pipelines (illustratively, ~3.1 GB/day versus ~4.1 TB/day for traditional tracing), lowering storage and egress costs.

## Frequently Asked Questions

### What makes Checkly Traces different from traditional distributed tracing?
Traditional tracing samples all of your traffic and bills you for the volume. Checkly captures only the spans tied to a failed synthetic check, so you get the exact context to debug a failure without the unrelated telemetry or its storage bill.

### Do I have to replace my current observability stack?
No. Checkly Traces is built on standard OpenTelemetry. Instrument with the OTel SDKs you already run, point an existing Collector at Checkly, and export the same traces to Grafana Tempo, Honeycomb, or Datadog. There is no vendor lock-in.

### How do traces connect to my checks?
Every check result, test session, and live editor run is correlated to its OpenTelemetry trace. When a check fails, Checkly links it directly to the spans that caused it, so you go from a red check to the failing span in one click.

### What does Rocky AI do with traces?
When a check fails, Rocky AI automatically retrieves and interprets the OTel trace to pinpoint the root cause. For example, an API check can fail with a 500 while the trace reveals the real culprit is a downstream Clickhouse query returning the error, and Rocky reports that in plain language.

### Which languages and frameworks are supported?
Anything with OpenTelemetry instrumentation: Node.js, Python, Go, Java, .NET, Ruby, and more. If your services emit OTel spans, Checkly can correlate them to the checks that generated them.

### Will this actually reduce my observability costs?
Yes. Because Checkly only records the interactions it generates, trace volume drops sharply compared with sample-everything pipelines, which lowers storage and egress costs while keeping the data you actually need to resolve issues.

## Related

- [Traces (full page)](https://www.checklyhq.com/product/traces/)
- [Synthetic Monitoring](https://www.checklyhq.com/product/synthetic-monitoring/)
- [API Monitoring](https://www.checklyhq.com/product/api-monitoring/)
- [OpenTelemetry Guides](https://www.checklyhq.com/docs/learn/opentelemetry/overview/)
- [Pricing](https://www.checklyhq.com/pricing/)
- [Start for free](https://app.checklyhq.com/signup/)