---
title: "Query dropped traces | Grafana Cloud documentation"
description: "Adaptive Traces keeps every dropped trace queryable by trace ID for 24 hours after ingest."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Query dropped traces

When a trace doesn’t match any of your sampling policies, Adaptive Traces drops it. Dropped traces remain queryable by trace ID for up to 24 hours after ingest. This is useful when a log line, exemplar, or another system gives you a specific trace ID to investigate.

## How it works

- For the first 24 hours after ingest, every trace is queryable by trace ID, including dropped traces.
- The first time you look up a dropped trace within that 24-hour window, Adaptive Traces writes it to Tempo for long-term storage. After a trace is in Tempo, you can keep looking it up by trace ID.
- Dropped traces that nobody looks up within the 24-hour window are permanently discarded.
- There is nothing to enable or configure. This applies to every Adaptive Traces tenant automatically.

## Identify a restored trace

When Adaptive Traces returns a trace through trace ID lookup, it adds a `grafana.adaptivetraces.restored` attribute to every span. This lets you tell apart restored traces from traces that were originally sampled.

Expand table

| Attribute                                     | Example value       | When it’s added                                                                                             |
|-----------------------------------------------|---------------------|-------------------------------------------------------------------------------------------------------------|
| `grafana.adaptivetraces.restored`             | `true`              | Always present on a restored trace.                                                                         |
| `grafana.adaptivetraces.truncated`            | `true`              | Present when only part of the trace could be returned, typically because the trace was very large.          |
| `grafana.adaptivetraces.truncated_percentage` | `93.93200201457533` | Present alongside `truncated`. Reports how much of the trace was truncated, as a floating-point percentage. |

## TraceQL search is not supported

Dropped traces are retrievable only by their trace ID. They do not appear in TraceQL search results, the service graph, or any aggregation, even after they’ve been written to long-term storage.

To make a trace discoverable through TraceQL, for example to investigate by service, latency, or attribute, you have to select it with a sampling policy at ingest. Refer to [Create policies](/docs/grafana-cloud/adaptive-telemetry/adaptive-traces/create-policies/) for guidance on writing policies that keep the traces you want to be searchable.

## When to use this

Looking up a dropped trace by ID is useful when:

- You have a trace ID from another system, such as a log line, an error report, or a link shared by a customer, and you want the underlying trace even if it was dropped.
- You’re investigating a specific incident where you already know which trace you need.
- You want to spot-check that your sampling policies are behaving as expected by looking up traces that should or shouldn’t have been kept.

For exploratory or aggregate analysis, such as finding all slow traces, all errors, or anything matching a TraceQL query, rely on the policies you’ve configured to keep the right traces searchable.