The hidden cost of no error logging: a real-world example

When I start working with a new PHP platform, one of the first things I do is look at the error logs. Not because I'm expecting to find anything dramatic — but because in my experience, there's almost always something there that nobody has looked at in a while.

What bad logging looks like

There are two failure modes, and they're equally problematic:

Too much noise. Logs that capture everything — every deprecation notice, every informal warning, every routine third-party message — become impossible to read. Developers learn to ignore them. When a genuine error appears, it doesn't stand out. The team is effectively flying blind even though the data is technically there.

No logging at all. Worse than noise. Errors happen, leave no trace, and the only way to diagnose a failure is to reproduce it — which is often impossible, especially for intermittent issues. This is the situation where a bug exists in production for months and nobody finds it until a user reports it.

What we changed

Logging configuration should be restructured to surface only actionable errors — genuine failures that indicate something went wrong and needs attention. Deprecation notices and informational warnings were suppressed. The remaining log output then becomes something you could actually read and act on.

What good logging actually looks like

Good error logging has a few properties:

• Signal over noise — only errors that indicate real problems should appear. Suppress deprecation notices and warnings that you're not going to act on.

• Readable format — timestamps, error type, file and line number, stack trace where relevant. Enough context to act on it without having to guess.

• Log rotation — logs that grow forever fill disks. Configure rotation so old logs are archived or deleted on a schedule.

• Someone actually reads them — this is the part that gets skipped. A well-configured log that nobody checks is only marginally better than no log at all. Build a habit of reviewing error logs regularly, or set up alerting for critical errors.

The wider point

The cost of poor error logging isn't just the time spent diagnosing issues when they become visible. It's the compounding cost of problems that go undetected and untreated. A memory leak that's been running for six months. A database query that's getting slower as the table grows. A third-party integration that's been failing silently on 5% of requests.

Good logging doesn't prevent problems. But it means you find out about them sooner — and sooner almost always means cheaper.

When did you last read your error logs?

If the honest answer is "I'm not sure where they are", that's worth addressing. If you'd like a second pair of eyes on your platform's logging setup — or a broader infrastructure review — get in touch. It's usually a short piece of work with a clear return.