← Blog
Observability Jul 14, 2026 · By Michael Shpilt

5 Strategies to Reduce Logging Costs

5 Strategies to Reduce Logging Costs

If you’re not careful, logging costs can rise up to staggering amounts. Paying 5 or 10 (or more) percent of your cloud host costs for logging is just too much. And let’s be honest, most of the logs are redundant and never queried. But you still need logs just in case, otherwise, you’re blind in production next time there’s an incident. So let’s try to find a middle ground. There are several good strategies to reduce your logging bill while keeping visibility.

Strategy 1: Sampling

Sampling is a very common practice and comes out of the box as a feature with most observability vendors. Sampling might sound simple but doing it right is actually quite tricky.

There are two ways of doing it: there’s Head Sampling and there’s Tail Sampling. In head sampling, by far the easiest method, you decide at the beginning what you want to sample and what not. e.g. sample every 10th trace. In tail sampling, on the other hand, you decide at the end. A use case for tail sampling might be to keep only traces where there was some kind of an error log.

Tail sampling requires keeping all logs of a trace or a span in a buffer and deciding on whether to log it or not at its end. If you’re using OpenTelemetry, you can achieve head sampling with SDK confi, and tail sampling can be done with an OTEL collector.

Be careful of using sampling features on the observability vendor’s server side, since those are often not aware of traces or spans. DataDog exclusion filters, for example, will randomly choose logs by the sampling percentage that you set, leaving traces with “holes”. Not to mention that with DataDog sampling via exclusion filters, you’ll keep paying for ingesting those logs, even if you don’t pay for indexing them.

Sampling disadvantages

The biggest problem with sampling is that you throw away information. The events you care about most are often the rare ones: a production bug that happens once in 10,000 requests, an unusual user flow, or a one-time failure.

Sampling also makes analysis harder. Counts become estimates, and different signals can become inconsistent. You might have full metrics, partially sampled logs, and sampled traces that don’t line up.

In any case, sampling at best solves the problem partially. It reduces the amount of telemetry you store, but you are still paying the cost of generating, processing, and transmitting noisy data.

Strategy 2: Tiered Storage

Another common pattern is storing your logs in warm/cold storage. Many vendors, have multiple tiers for storing logs. The default tier is usually the most expensive, but allows for the fastest queries, using logs for alerts, building metrics and dashboards from logs, depending on the vendor.

A middle tier might allow for cheaper storage, but with trade-offs. Queries might be slower, you might lose the ability to create monitors, or metrics from those logs.

The cold tier, what you might call archive, doesn’t allow for any query. But it allows for rehydration, which means when needed, on demand, you can pull out logs from that tier into the standard tier. Obviously, you’ll pay some kind of double cost for all that trouble by your vendor. But since it’s going to be used as a rare insurance, it still makes sense to use.

A common strategy is to store logs in the standard or warm tier for a short retention, then move them to the cold tier for a longer retention for compliance reasons or in case of a relevant incident. There’s a whole category of solutions called “Telemetry Pipeline” that act as a proxy between your application and the observability vendor, placing all logs in cheap storage, often cheaper than what the observability vendor offers, which allows rehydration and often even querying. The trade-off is adding another vendor, learning a new tool, and introducing more complexity for your developers and SRE engineers.

Tiered storage disadvantages

Keeping logs in tiers is a sensible choice, but when pushed to the limit it always comes to a trade off. You have to choose between more effective day-to-day analytics and incident response to observability costs. That’s why I like the hybrid approach of keeping logs in the standard tier for a short retention period and then moving them to the warm or cold tiers. Having said that, cross-tier analytics and even simple queries are a nuisance, which trips up usage constantly.

Strategy 3: Clean up and optimize in code

The third type of optimization is cleaning up the data. Logs often become a dumpster fire of old and no longer relevant data. You add logs throughout the years by many teams, but you never clean them, which amounts to heaps of waste, most of which nobody needs. Then one day somebody notices the bill is just a bit too much, maybe an extra digit or two more than expected, and it becomes a priority.

There are many techniques and patterns to optimize log noise, some of which are:

  • Remove duplications
  • Aggregate repetitive logs to a single log or to a metric
  • Unify consecutive logs into a single log
  • Reducing log level to DEBUG or TRACE for logs that you don’t need but aren’t quite ready to delete
  • Identifying and cutting overly verbose logs. Might be some json serialization that swelled needlessly or a long unnecessary explanation that can be turned concise.

So, let’s imagine we’re doing a cleanup sprint. We stop development for a week or a month, create a task force that goes over noisy logs, finds redundant ones, and cleans them. If you’re a developer, I bet that doesn’t sound great. Developers want to add features and work on the codebase, not to do house cleaning.

That’s where a new category of tools comes in, like Obics, which uses agentic methods to do most of that work. Instead of trying to find redundant logs yourself, you’ll get a list of redundancies and optimization suggestions, with the tool also creating the pull request to fix it on demand. An engineer still needs to review these optimizations, but there will be a day when this process might be entirely autonomous.

Strategy 4: Switch to a cheaper vendor

Another type of optimization is moving to a cheaper observability vendor. You’re obviously not solving the noise problem, but there’s a good chance you’ll solve the expense problem, at least for the short term. If you look, you’ll quickly find many cheaper alternatives to the “top tier” vendors like Splunk or Datadog.

Not to say this kind of move is bad, but for large companies and cross-functional teams, these migrations are notoriously expensive, especially if you’re not already using OpenTelemetry. Even if you are fully in OTEL, you still need to migrate alerts, dashboards, log-generated metrics. You need to retrain your teams who are accustomed to the old tool and you need to absorb the onboarding costs for everyone using the new one.

Strategy 5: Remove INFO logs

The worst case scenario is when your budget is so depleted, and your observability vendor is so expensive, that you have to stop logging. That’s where you raise the minimum log level to WARN and leave just the essentials.

The pros and cons of this strategy are pretty obvious. On the upside, you’ll definitely save on your observability costs. On the downside, you’re almost completely blind in production. A radical move for a radical situation.

Conclusion

There isn’t a single silver bullet for reducing logging costs. Different organizations benefit from different combinations of these strategies. Sampling reduces storage volume but sacrifices visibility. Tiered storage lowers retention costs but makes analysis more cumbersome. Switching vendors can reduce prices but often comes with a costly migration.

The most sustainable optimization is usually to reduce unnecessary telemetry before it ever leaves your application. Every redundant log you remove saves CPU cycles, network bandwidth, storage, and future engineering time. Unlike sampling or tiering, you’re not throwing away potentially useful information. Instead, you stop generating data that nobody needs.

As telemetry volumes continue to grow, observability cost optimization is becoming less about finding cheaper storage and more about treating telemetry as code that deserves the same continuous maintenance as the rest of your application. The teams that adopt that mindset will not only spend less on observability, they’ll end up with cleaner, more useful data when incidents inevitably happen.