€0.00 — free as in speechtonight's forecast: clear skies over production Cache: warm · Deploys: fair, 0% rollbacks expectedset by moonlight, shipped before dawn · deploy freely Page A2

The Daily Commit The Nightly Build

Dev news, typeset daily — PHP · AI · The Wider Stack

The developer's evening paper — PHP · AI · The Wider Stack

Thursday, August 20, 2026 Vol. I — No. 373 · Morning editionLate edition EN DE FR ES

PHP · News

PHP 8.6 Deprecation Wave Could Inflate Your Logging Costs

PHP 8.6's mass deprecation vote closed with 35 RFCs, most passing.

curated by Heiko

Nothing breaks immediately, but deprecated calls keep warning — and on busy Laravel apps that means sustained log volume, higher ingestion bills, and noise from vendor packages you cannot fix yourself.

PHP 8.6's mass deprecation vote has closed, covering 35 separate RFCs, most of which passed. Deprecated functions continue to work in 8.6 itself — they merely start emitting warnings. That sounds harmless, but it has two practical consequences.

First, log volume becomes a cost issue. On a production Laravel project with notice-level logging enabled, a deprecated function sitting in a hot path called thousands of times per minute produces a continuous, compounding stream of log entries: disk usage, ingestion into systems like Loki or ELK, and ultimately money. The symptom appears as "logging costs went up," which often gets triaged by the wrong team, weeks after the code that caused it shipped.

Second, some deprecations are outside your control. You can clean up your own code quickly — tools like Rector automate much of that work — but vendor packages without an 8.6-ready release will keep generating noise until the upstream maintainer ships a fix, a timeline you do not control. On a dependency-heavy stack that can mean weeks of irreducible log noise.

There is no urgency: PHP 8.5 remains supported for years, and deprecations only become breaking changes when they eventually turn into removals. But whenever the upgrade does happen, the failure mode is the same, so the recommended defense is to treat deprecations as a CI concern rather than a production logging problem: bump the PHP version in CI first, make E_DEPRECATED and E_USER_DEPRECATED fail the build via a custom error handler that throws an ErrorException, fix your own code, update or track vendor packages, and only then deploy the version bump to production.

For stubborn vendor deprecations, the author suggests checking whether a newer package version is already 8.6-ready, whether the deprecated call is actually reachable in your usage or removable dead code, and — sparingly — suppressing a specific warning at the call site with @ while tracking the upstream issue, rather than disabling the CI gate entirely. The payoff: a five-minute PR fix instead of untangling an observability bill spike three weeks later.

Read the original source ↗

Rate this article: 0

Readers’ Forum

No contributions yet — open the debate.

The Daily CommitThe Nightly Build — Page A1