---
title: "Reduce individual trace size | Grafana Cloud documentation"
description: "Understand what makes traces large and how to reduce individual trace size in Grafana Cloud Traces."
---

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

# Reduce individual trace size

Grafana Cloud Traces enforces a per-trace size limit. When a trace exceeds this limit, its spans are partially discarded, which causes gaps in your trace data. This page explains what contributes to trace size and what you can do to keep traces within limits.

For guidance on reducing the overall *number* of traces you ingest (volume), refer to [Sampling strategies](/docs/grafana-cloud/send-data/traces/configure/sampling/).

## What makes traces large

A trace’s byte size is determined by three factors:

- **Number of spans.** Each span adds overhead. Traces with thousands of spans are often the result of retry loops, large fan-out (for example, a service calling hundreds of downstream endpoints in parallel), or debug-level instrumentation left enabled in production.
- **Span attributes.** Each attribute key-value pair contributes bytes. Long string values (HTTP request/response bodies, SQL statements, stack traces, serialized objects) are common sources.
- **Span events and links.** Events (such as exception recordings) and span links add to the overall payload. A single span with many exception events can be surprisingly large.

## Identify oversized traces

If you’re seeing `trace_too_large` discards, you can find the affected traces and services using TraceQL and Usage Insights. Refer to [Identify which services are causing discards](/docs/grafana-cloud/send-data/traces/troubleshoot/#identify-which-services-are-causing-discards) in the troubleshooting documentation for step-by-step instructions.

To proactively find traces with high span counts:

traceql ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```traceql
count() > 10000 | rate() by (resource.service.name)
```

This query plots the rate of spans grouped by service for traces that exceed 10,000 spans. Click the exemplars to investigate specific traces. Adjust the threshold based on your workload.

## Reduce trace size

As a Grafana Cloud Traces user, you control trace size through your instrumentation, SDK configuration, and collector pipeline. All of these run upstream of Cloud ingestion.

### Fix instrumentation patterns

Common instrumentation patterns that produce oversized traces include:

- Retry loops. Each retry attempt creates a new child span. If retries are unbounded or aggressive, a single request can generate thousands of spans. Cap retries and consider recording retry count as an attribute on the parent span instead.
- Unbounded fan-out. A service that calls hundreds of downstream endpoints in a loop creates a span for each call. Consider batching or summarizing these calls in fewer spans.
- Debug spans in production. Development-time instrumentation (method-level tracing, loop iteration spans) generates high span counts with little diagnostic value.
- Large attribute values. Logging full HTTP request/response bodies, SQL statements, or serialized payloads as span attributes inflates trace size. Record only what you need for debugging (for example, truncated URLs, status codes, error messages).
- Excessive span events and links. Recording many events per span (for example, attaching a span event for every log line or every retry attempt) or creating span links for every related trace inflates the payload. Limit events to meaningful state changes, and use span links selectively for cross-trace correlation.

For more detail, refer to [Best practices for traces](/docs/tempo/latest/set-up-for-tracing/instrument-send/best-practices/).

### Set SDK limits

OpenTelemetry SDKs support environment variables that cap attribute counts and value lengths at the source. Setting these prevents your application from emitting oversized spans regardless of how it’s instrumented:

Expand table

| Environment variable                | What it limits                               | Default  |
|-------------------------------------|----------------------------------------------|----------|
| `OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT`   | Maximum attributes per span                  | 128      |
| `OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT` | Maximum character length per attribute value | No limit |
| `OTEL_SPAN_EVENT_COUNT_LIMIT`       | Maximum events per span                      | 128      |
| `OTEL_SPAN_LINK_COUNT_LIMIT`        | Maximum links per span                       | 128      |
| `OTEL_EVENT_ATTRIBUTE_COUNT_LIMIT`  | Maximum attributes per event                 | 128      |

Setting `OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT` to a reasonable value (for example, `2048`) is one of the most effective ways to prevent individual spans from growing unexpectedly large.

For the full list of SDK configuration options, refer to the [OpenTelemetry SDK environment variables](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/) specification.

### Filter in your collector pipeline

If you run Grafana Alloy or the OpenTelemetry Collector between your applications and Grafana Cloud, you can use processors to reduce trace size before export:

- **Drop low-value spans.** Filter out spans that don’t provide diagnostic value, such as health check endpoints or internal housekeeping operations.
- **Remove or truncate attributes.** Strip attributes that inflate payloads (for example, full HTTP bodies) or truncate long values.
- **Filter span events.** Remove verbose event data like repeated exception recordings.

These processors let you selectively reduce trace size without dropping entire traces.

For configuration details, refer to:

- [Grafana Alloy OpenTelemetry components](/docs/grafana-cloud/send-data/alloy/reference/components/otelcol/)
- [OpenTelemetry Collector filter processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor)
- [OpenTelemetry Collector attributes processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor)
- [OpenTelemetry Collector transform processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor)

### Use Adaptive Traces to drop unwanted traces

If certain traces are consistently too large and don’t provide value, you can use [Adaptive Traces](/docs/grafana-cloud/adaptive-telemetry/adaptive-traces/) drop policies to discard them at ingestion. For example, you can create a `span_count` policy to drop traces that exceed a span threshold, or a `string_attribute` policy to drop traces from specific services or endpoints.

Adaptive Traces operates at the trace level. It keeps or drops entire traces rather than trimming individual spans.

## Cloud platform behavior

Grafana Cloud Traces applies the following automatically:

- **Attribute truncation.** Attributes exceeding 2 KB (2048 bytes) are automatically truncated before storage.
- **Per-trace size limit.** Traces that exceed the configured limit are partially discarded. You can’t change this limit directly. Contact [Grafana Support](/contact/) to request an increase if your traces are legitimately large.

For information about ingestion limits and discard reasons, refer to [Troubleshoot Grafana Cloud Traces](/docs/grafana-cloud/send-data/traces/troubleshoot/#discarded-traces).