10 reasons not to use bitdrift: 2, you like paying for logs you don’t use

One of the quiet truths of observability is that the vast majority of logs are never read. Industry estimates routinely put the number at ~95%. They’re generated, emitted, uploaded, stored, indexed, and billed… and then they sit there forever, untouched. If that sounds reasonable, if you’re comfortable paying for data “just in case,” then bitdrift probably isn’t for you.

95% of logs are never used

Traditional logging pipelines assume that every log line might be important at some point. So they upload everything from the device, store it centrally, and hope it proves helpful later. bitdrift flips this model. Instead of treating logs as raw text that must always be uploaded and stored centrally, bitdrift metricizes and pre-aggregates logs on the device for fleet-wide metrics, and only uploads logs when you explicitly request a session replay. This gives you:

• Completely unsampled charts
• Zero costs for uploading logs
• High-signal visibility without uploading mountains of raw log data

You still see what’s happening across your entire fleet without paying for logs you don’t need.

Logging costs (and bandwidth) are unpredictable

Most observability vendors price logs by volume. That forces teams to guess:

• How many logs will we generate each month (typically one year out)?
• What happens if usage spikes?
• What’s the overage bill going to look like?

And even if you guess correctly, you’re still paying for logs you never inspect. On mobile, there’s an additional tax: network overhead. Uploading logs continuously means:

• More background network traffic
• Higher bandwidth usage
• Increased battery drain
• More pressure on users’ data plans

To avoid this, many teams sample logs not just for cost reasons, but simply to reduce network overhead. Some vendors even need to sample to scale to thousands of mobile devices. bitdrift avoids all of this:

• Logs are stored locally on the device
• They’re only uploaded when you choose to troubleshoot a specific issue
• We don’t charge for log volume at all

Pricing is based on monthly active applications, not how chatty your logs are. Your costs grow in line with your user base and revenue, not with spikes in debug output or unexpected incidents. With bitdrift, there is no guesswork and no surprise overages.

How teams try to cope (and why it backfires)

To manage cost and bandwidth, most teams fall into one of two traps.

1. Sampling logs

Sampling helps with cost and network usage, but it comes at a steep price. You miss rare failures and edge cases, you introduce blind spots, and the logs you need during an incident often… aren’t there. Sampling is a budget control mechanism, not an observability strategy.

2. Removing logs

The other approach is to log less, or to obsess over which logs are “worth it.” This is especially painful on mobile, because it leads to less context when issues occur, and a longer time to root cause. And if you realize you need more logs? You have to change code, cut a new release, wait for App Store approvals, and hope users update. That’s not a great story when customers are already impacted. With bitdrift, logging becomes boring again, in the best way possible. You can log freely, leave debug logs in production, and stop worrying about volume, bandwidth, or cost. Because logs stay on the device, developers don’t have to predict the future.

Unlimited logging means you can stop thinking about breadcrumbs

In the first post in this series, we talked about breadcrumbs: why they exist, and why developers spend so much time carefully choosing what context to capture. Unlimited logging entirely changes that mental model. When logging is free, you don’t need to curate breadcrumbs carefully. You don’t need to debate which events are important enough, and you don’t need to trade context for cost. You just log what’s useful at the time, knowing it’ll be there if and when you need it. The result is better debugging, fewer blind spots, and far less second-guessing.

If this sounds wasteful…

If paying to upload, store, and index logs that no one ever reads feels inefficient, especially on mobile, then you may find bitdrift interesting. If you’re happy paying for logs you don’t use, sampling away the ones you need, and guessing your way through pricing and bandwidth tradeoffs… You probably don’t need bitdrift. Want to try bitdrift for yourself? Sign up for free to see it in action or check out the sandbox to keep exploring.