In Laravel 13, how do you log PHP and framework deprecation warnings, and why do none appear in a freshly installed app?

## What counts as a deprecation A **deprecation** is a notice that a feature still works but will be removed or changed: PHP raises `E_DEPRECATED` for language features on their way out, and libraries, including Laravel and its dependencies, raise `E_USER_DEPRECATED` through `trigger_error()`. They are the early warning for the next PHP or framework upgrade. ## How Laravel handles them During bootstrap Laravel installs its own PHP error handler. For most PHP errors it throws an `ErrorException`, so a warning in your code becomes a real exception. Deprecations are the exception to that rule: 1. The handler sees `E_DEPRECATED` or `E_USER_DEPRECATED`. 2. It does not throw. It resolves the log manager and makes sure a `deprecations` channel exists. 3. It writes a **warning**-level entry to that channel: `<message> in <file> on line <n>`, or, with tracing on, the message plus an `ErrorException` so the formatter prints a stack trace. 4. Any failure while logging is swallowed, so a deprecation can never break a request. ## Why Laravel logs rather than throws Turning deprecations into exceptions would make every upgrade of PHP or of a dependency a potential outage: a library raising a new `E_USER_DEPRECATED` notice from inside its own code would crash requests that did nothing wrong. Logging keeps behaviour unchanged while still recording the signal. The trade-off is that the signal is easy to ignore, which is why deprecations need a deliberate destination and a periodic review rather than being left on the `null` channel forever. ## Why nothing appears by default The skeleton's `config/logging.php` contains: ```php 'deprecations' => [ 'channel' => env('LOG_DEPRECATIONS_CHANNEL', 'null'), 'trace' => env('LOG_DEPRECATIONS_TRACE', false), ], ``` and `.env.example` sets `LOG_DEPRECATIONS_CHANNEL=null`. The `null` channel uses Monolog's `NullHandler`, which discards everything. Deprecations are processed and then thrown away, which keeps production logs quiet. ## Turning them on There are two ways, and one takes priority: - **A channel literally named `deprecations`** under `channels`. If it exists, Laravel always uses it, whatever `logging.deprecations` says. It is the tidy option when deprecations need their own file. - **`LOG_DEPRECATIONS_CHANNEL=daily`** (or any configured channel). Laravel copies that channel's config into a `deprecations` channel at runtime, so entries go wherever the named channel writes. Options worth knowing: | Setting | Effect | |---|---| | `LOG_DEPRECATIONS_TRACE=true` | Attaches an `ErrorException`, so entries carry a stack trace showing the caller | | `LOG_DEPRECATIONS_WHILE_TESTING` set | Logs deprecations during the test suite, which are otherwise skipped | | Target channel `level` | Must be `warning` or lower; a `critical`-only channel drops every deprecation | ## Using them before an upgrade A practical routine before moving to a new PHP or Laravel release: - send deprecations to their own file in staging, with tracing on, so each entry names the calling code; - run the test suite with `LOG_DEPRECATIONS_WHILE_TESTING` set, since tests exercise paths production rarely hits; - group the entries by message and fix your own code first; notices raised inside vendor packages usually mean upgrading that package; - turn tracing off again afterwards, because traces make each entry large. ## What an entry looks like With `LOG_DEPRECATIONS_CHANNEL=daily` and tracing off, a PHP 8.4+ deprecation raised when a class is compiled appears as a single warning line: ``` [2026-09-29 09:02:11] staging.WARNING: App\Services\FareQuote::price(): Implicitly marking parameter $promo as nullable is deprecated, the explicit nullable type must be used instead in /var/www/app/Services/FareQuote.php on line 42 ``` The message comes from PHP; Laravel appends the file and line. Many deprecations repeat each time their code path runs, so a busy app logs the same message many times: group by message when reviewing, rather than reading line by line. With `LOG_DEPRECATIONS_TRACE=true` the line keeps only the message, and the formatter prints the attached exception's stack trace underneath, which is what you need when the deprecated call sits inside a vendor package and you must find which of your calls reached it. ## Pitfalls - Pointing `LOG_DEPRECATIONS_CHANNEL` at an alert channel such as Slack at `critical`: warnings never pass its level, so nothing arrives, and at a lower level the chat floods. - Pointing it at the default stack, which mixes thousands of repeated notices into the main application log. - Expecting deprecations to fail tests; Laravel never turns them into exceptions.