Best practices for policies

Adaptive Traces gives you the power to control your observability costs and reduce noise by keeping only the traces that provide value.

The most important best practice is also the simplest: start with what Adaptive Traces recommends out of the box, and only add custom policies when you have a specific need the recommendations don’t cover. Most policy configurations that go wrong are hand-built from scratch. The recommendations exist so yours doesn’t have to be.

This guide describes the recommended policy layers in the order you should adopt them, and how to add custom policies safely when you need them.

Start with the recommendations

The onboarding experience sets up a volumetric sampling policy plus keep rules for errors, slow traces, and unique traces in one click, with anomaly detection enabled by default. After that, Adaptive Traces continues to analyze your traffic and surfaces recommendations on the Overview page.

For most customers, applying the out-of-the-box recommendations is the whole job. Before you create any custom policy, ask whether a recommendation already covers the need. Hand-crafted policies are the last layer, not the first.

After onboarding, new recommendations appear when your traffic changes enough to need them, not on a schedule. Apply them when they show up on the Overview page.

Understand the core evaluation logic

Before you change anything, it’s crucial to understand how policies are evaluated.

Drop always wins: If a trace matches any policy configured to drop it, it’s immediately discarded. This rule has the highest priority and overrides all others.
Keep if any match: If a trace isn’t dropped, it only needs to match one keep policy to be saved. Think of your keep policies as a large “OR” condition.
Default is drop: If a trace matches no policies at all (neither keep nor drop), it’s discarded.

Layer your policies in the recommended order

Build your configuration in layers, from broad volume control down to specific hand-crafted rules. Each layer has one job.

Use volumetric sampling to control bulk volume

Your base layer controls how much data you keep overall. Use a volumetric policy for this rather than a plain probabilistic policy.

At the same sampling percentage, volumetric sampling distributes your budget evenly across services and trace types, so a noisy service that produces 90% of your traffic doesn’t also consume 90% of your retained traces. The onboarding experience creates a volumetric policy for you. If you enabled Adaptive Traces before volumetric sampling was available and still have a single probabilistic policy, Adaptive Traces recommends upgrading it to a volumetric policy at the same percentage; apply that recommendation.

Start low, for example at the recommended 5%. You can always increase it later if you find you need more data.
Lower the percentage incrementally as you confirm that low-volume services remain well represented.

Use diversity sampling to capture unique traces

Volume control alone can miss rare behavior. A diversity policy guarantees that at least one trace for each unique combination of attributes, such as service, route, and status code, is kept every 15 minutes. The onboarding creates this policy for you unless you chose the custom option and cleared keep unique traces. If you don’t have one, apply the recommendation when it appears.

This gives every service and endpoint a minimum footprint, no matter how little traffic it receives. It also removes the need for the hand-crafted per-service keep policies teams often build to guarantee coverage: with diversity sampling in place, you can delete those policies instead of maintaining them.

Keep anomaly detection on

Anomaly detection is enabled by default; leave it on. When Adaptive Traces detects a significant change in service behavior, such as a latency spike, it temporarily keeps the relevant traces so you can investigate issues you didn’t know to look for.

This layer is what makes low sampling percentages safe: when something goes wrong, sampling automatically shifts toward the traces you need.

Keep errors and slow traces

Ensure you never lose your most critical signals. The onboarding configuration creates these keep rules for you; verify they’re in place rather than recreating them.

Always keep errors: Keep 100% of traces that have a status code of Error.
Capture high latency: Define what slow means for your key services and keep any trace that exceeds that threshold, for example, latency greater than 2 seconds.

Add hand-crafted drop or keep policies last

Only after the layers above are in place, add custom policies for needs the recommendations can’t know about. Common use cases include:

Dropping noisy traffic like health checks
Keeping a specific percentage of very specific traces
Rate limiting volume from particular entities
Adjusting the recommended policies to be more or less aggressive

Keep this layer small. Every hand-crafted policy is something you have to maintain as your services change; the layers above adapt on their own. When you write a custom policy, match on a specific attribute with equals, for example http.target or rpc.method. Don’t use a broad contains match on a URL. If a later recommendation covers something you built by hand, delete the custom policy.

To see how many traces each policy keeps or drops, refer to Monitor Adaptive Traces.

Use drop policies carefully

Drop policies eliminate high-volume, low-value traffic that you never need to see, regardless of whether it’s anomalous.

Drop policies have the highest evaluation priority. A trace that matches a drop policy is immediately discarded, and no other policy (including anomaly or diversity) can override that decision. This makes them powerful but potentially dangerous if misused.

Good use cases:

Health checks and readiness probes: Endpoints like /healthz, /ready, and /metrics generate constant, homogeneous traffic with no diagnostic value. Dropping them is safe because there is no interesting anomaly hiding in a synthetic 200 response.
Synthetic test traffic: If your load tests or canary deploys tag traces with a known attribute (for example, app.synthetic: true), a drop policy ensures they never consume your trace budget.
Enforcing required attributes: Drop traces that are missing a mandatory attribute like deployment.environment to keep your data clean.

Example: Create a String Attribute policy to drop all traces where url.path matches /healthz or /metrics.

Antipattern — don’t use drop policies for rate limiting:

It’s tempting to use a drop policy to reduce volume from a noisy but important endpoint (for example, /api/checkout). However, this creates a blind spot: if that endpoint starts returning errors or experiences a latency spike, those traces are silently discarded before anomaly detection can catch them.

Instead, use a sampling policy scoped to that traffic. For example, create a composite policy that matches the high-volume attribute and applies a low sampling rate (for example, 5%). This reduces throughput while still giving anomaly and diversity policies a chance to rescue interesting traces that fall outside the sample.

Rule of thumb: If the traffic is never useful, drop it. If the traffic is just noisy, sample it.