The Hidden Cost of Over-Logging

Ask a developer whether they're logging too much and you'll almost always get the same answer: 'I'd rather have too much than too little.' It's a reasonable instinct. Debugging a production incident with sparse logs is genuinely painful.

But over-logging has real costs that compound quietly over time — and most teams don't have a clear picture of what they're actually paying for.

The Obvious Cost: Ingestion Bills

Datadog, Splunk, Azure Monitor, and most observability platforms charge for log ingestion by volume. The pricing feels manageable at first — and then a new microservice goes to production, or a retry loop starts emitting debug output, and the bill doubles.

The problem is compounded by the fact that most of that data is never queried. Teams routinely find that 80-90% of their log volume is noise: debug statements left in from development, verbose framework output, and redundant INFO logs on hot paths.

The Less Obvious Cost: Signal Degradation

High log volume doesn't just cost money — it actively degrades the quality of your observability. When a production incident occurs and you're querying a log stream with millions of events per hour, finding the relevant signals is much harder.

This creates a counterintuitive outcome: teams that log more often have worse incident response times than teams that log precisely. The noise-to-signal ratio matters enormously when time is the constraint.

The Structural Cost: Storage and Retention

Log retention policies are often set to match compliance requirements — 90 days, 1 year, 7 years depending on the regulatory context. When you're storing 10x the necessary log volume, you're paying 10x the storage cost for the entire retention period.

Example: HIPAA audit log retention (6 years)

Over-logged:  500GB/day × 365 × 6 = ~1.1 PB storage
Governed:      50GB/day × 365 × 6 = ~110 TB storage

Delta: ~990 TB. At $0.023/GB (S3 standard), that's ~$22,700/month in storage alone.

The Compliance Cost: Data You Didn't Mean to Keep

This is where over-logging intersects with governance. Every byte of log data you store is potentially in scope for compliance frameworks — HIPAA, GDPR, PCI DSS, and SOC 2 all have specific requirements around sensitive data retention, access controls, and breach notification.

When developers log more than necessary, they often inadvertently include data that expands their compliance scope. A request payload logged for debugging purposes might contain a PHI field that the team didn't intend to persist. Now that data is in your SIEM, potentially replicated to cold storage, and retained for years.

What 'Governed Logging' Means in Practice

Governed logging isn't the same as minimal logging. The goal isn't to log as little as possible — it's to log with intention. Every log event should have a defined purpose: diagnostic, audit, performance telemetry, or error tracking.

• DEBUG logs should not reach production sinks — they should be suppressed at emission, not filtered downstream.
• Structured fields should be explicitly declared, not implicitly serialized from objects.
• Exception logs should have a defined maximum context depth to prevent payload capture.
• Hot-path log calls should be measured for volume and reviewed against ingestion costs periodically.

Starting the Conversation

The easiest way to make the case for governed logging internally is to pull your last 3 months of log ingestion costs and sort by service. In most organizations, 20% of services account for 80% of log volume. Those services are usually the ones with the loosest logging practices — and the highest compliance risk.

Logging is not free. Every event you emit has a cost: ingestion, storage, retention, and potentially compliance scope. Governance isn't about logging less — it's about ensuring that every event you pay for is worth paying for.