Coverage-first or cost-first: two ways to automatically apply Adaptive Metrics' recommendations

Adaptive Metrics , which is part of the Adaptive Telemetry suite, looks at how your metrics are actually used and recommends how much detail you should keep for each metric. This helps you cut costs while still retaining the data you actually need. 

Last year we added auto-apply capabilities that let you implement those recommendations automatically, but only with coverage-first behavior, maximizing coverage of whatever you're querying. If your team wanted anything different, the only option was to review and apply recommendations by hand. 

But now, with the General Availability release of auto-apply, we've added a second mode: cost-first, a built-in safeguard that only applies recommendations that won't increase your total active series—ensuring optimization never turns into a cost spike. 

Auto-Apply continuously applies recommendations in either mode with no human intervention, while your existing dashboards, alerts, and queries keep working unchanged.

How cost-first mode decides what to apply

Every recommendation Adaptive Metrics generates comes with a projected change to your series count—some recommendations decrease it, others increase it. Cost-first mode can now take those projected changes into account, much like a careful manual review would, in three steps:

1. Series-reducing recommendations always apply. Anything that lowers your projected series count goes through immediately, including brand-new recommendations.
2. Series-increasing recommendations get ranked. Anything that would raise your projected series count is sorted from least impactful to most impactful.
3. Adaptive Metrics stops at your current total. It works down that ranked list, applying recommendations until the next one would push your projected series count above where it started the cycle.

How coverage-first mode decides what to apply

Coverage-first works more simply than cost-first does: every recommendation gets applied as soon as it's generated, whether it lowers your series count or raises it.

1. Every recommendation applies, no ranking required. Coverage-first doesn't weigh one recommendation against another or check a budget. It just applies what Adaptive Metrics finds.
2. Increases go through immediately. If a query comes in for data that's already been aggregated away, the recommendation to restore it at full resolution applies right away, because someone clearly needs that data.
3. Your metrics stay in lockstep with usage. As what you query shifts week to week, coverage-first adjusts automatically, so nothing you actually use ever falls out of resolution.

The tradeoff is the one cost-first exists to solve: because every increasing recommendation applies too, a spike in queries against previously-aggregated data shows up as a spike in series count.

A simplified example makes this concrete. Say a cycle generates three recommendations:

The net effect is that your series count stays flat or drops. It never rises above where you started the cycle, which is the guarantee cost-first mode is built around.

Cost-first vs. coverage-first: when to apply each one

Adaptive Metrics' original auto-apply behavior, coverage-first, maximizes coverage of whatever you're actually querying. It's still there, and it's still the better fit for some of your data. If a dataset is business critical and your team knows exactly what it's querying and why, you want nothing standing between a real query and the raw data behind it. That's the mode we at Grafana Labs use internally for our own critical telemetry.

Cost-first mode is the better fit where cost matters more than guaranteed full coverage. For example, it would be well suited for a PromptQL query that asks for more than the person writing it realized, or an agent issuing queries on your behalf with no visibility into the cost impact downstream. That's increasingly common as less experienced users get access to larger datasets without realizing the potential impact of their queries. In those cases, you'd rather have Adaptive Metrics hold the line on cost and let you review and restore specific data later than have it de-aggregate automatically every time something gets queried unintentionally.

You also don't have to pick one mode for all of your data. Adaptive Metrics' segments feature lets you partition your telemetry along a dimension you choose (e.g., by team, environment, or cluster) and set a different mode on each segment independently. Keep coverage-first on the segments your experts own, and turn on cost-first mode for the segments where cost predictability matters more. It's the same underlying system; you're just telling it which guarantee you want and where.

Try auto-apply in Adaptive Metrics

If you're already using Adaptive Metrics in Grafana Cloud, both versions of auto-apply are available today, no extra setup required. Head to your Adaptive Metrics configuration, pick a segment, and turn it on to see your chosen mode applied on your next recommendation cycle.

For the full mechanics and configuration options, see the auto-apply documentation. It’s worth creating exemptions first for anything you can't afford to lose, and you'll need the Admin role to make the change. 

You can also check your Adaptive Telemetry savings to see the impact on your Grafana Cloud bill.

New to auto-apply? Walk through the full learning journey in our docs: Enable auto-apply in Grafana Adaptive Metrics.

Grafana Assistant is the easiest way to get started with metrics, logs, traces, dashboards, and more in Grafana Cloud. We have a generous forever-free tier and plans for every use case. Sign up for free now!