PHP 8.6 Deprecations: Why Your Logs (and Bill) Will Spike

#php #laravel #monitoring #devops

PHP 8.6's mass deprecation vote just closed: 35 separate RFCs, most of them passing. Nothing breaks in 8.6 itself: deprecated functions keep working, they just start warning. That's exactly what teams tend to underestimate, and it's worth walking through why.

Effect #1: Log volume becomes a cost problem

On a live Laravel project with notice logging enabled, every deprecated call in a hot path turns into log volume: disk, ingestion into Loki/ELK, money. The symptom shows up as "logging costs went up," not "time to fix the code," which means it often gets triaged by the wrong team, at the wrong layer, weeks after the actual cause shipped.

A rough mental model: if a deprecated function sits in a hot path called thousands of times per minute, you're not looking at a handful of warnings, you're looking at a sustained, compounding log stream that ingestion pipelines have to process and store indefinitely.

Effect #2: Deprecations you don't control

You'll fix your own code fast. The harder problem is vendor packages without an 8.6-ready release: they'll keep making noise in your logs until the upstream maintainer ships a fix, and that timeline isn't yours to control. On a dependency-heavy Laravel stack, this can mean weeks of irreducible noise even after your own codebase is clean.

(as one commenter pointed out on the LinkedIn version of this post, Rector automates a big chunk of the fixing work, but only for code you own. It won't touch vendor internals, so it complements the CI gate below rather than replacing it.)

You don't have to upgrade right now.
PHP 8.5 is supported for years to come, and deprecations by themselves aren't urgent: they won't break anything until they eventually become removals, often years later. If you're not planning an 8.6 bump soon, none of this is time-sensitive.

The scenario below is for whenever that upgrade does happen, this month, or in a few years. The failure mode doesn't change based on timing: whenever you bump the version, the vendor-deprecation noise shows up the same way, so the CI-gate approach is worth having in place before that day arrives, not scrambling to add it after.

The order that actually works

The trap is discovering deprecation noise in production logs after the fact, then reverse-engineering which release caused it. The order that avoids that:

Bump the PHP version in CI first, not in production.
Set error_reporting to treat E_DEPRECATED as an error in CI, so warnings fail the build instead of silently passing.
Fix what breaks, your own code first; for vendor deprecations, check if a newer package version resolves it, or track the upstream issue.
Only then ship the version bump to production.

A minimal CI-side snippet for the second step:

// In a CI-only bootstrap or phpunit bootstrap file
error_reporting(E_ALL);
set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    if ($errno === E_DEPRECATED || $errno === E_USER_DEPRECATED) {
        throw new \ErrorException($errstr, 0, $errno, $errfile, $errline);
    }
    return false; // fall back to default handler for everything else
});

This turns deprecation warnings into hard failures during your test suite run, cheap to add, and it moves the discovery point from "someone notices the Loki bill" to "the build fails on the PR."

The dependency case

For vendor deprecations specifically, worth checking before assuming you're stuck waiting on upstream:

Is there a newer major/minor version of the package that's already 8.6-ready?
Is the deprecated call actually reachable in your usage, or dead code you can just remove?
Can you suppress just that specific warning at the call site (via @, sparingly) while tracking the upstream issue, rather than disabling the CI gate entirely?

Takeaway

Nothing forces you to fix deprecations the moment they're announced. But treating them as a CI concern, not a production logging concern, is the difference between a five-minute PR fix and untangling a spike in your observability bill three weeks later.

How does your team handle this: hard CI gate, lower log verbosity, or something else?

If posts like this are useful, follow for more on Go, PHP, and production backend engineering.

DEV Community