Weave Code
Laravel Log Enhancer Laravel Package
freshbitsweb/laravel-log-enhancer
Laravel Log Enhancer automatically enriches every log entry with useful request context—logged-in user ID, request URL, IP address, input and session data—so you can debug production issues faster. Quick to install and configure, no code changes needed.
Make debugging easier by adding more data to your laravel logs (Laravel 5.6+)
Frequently asked questions about Laravel Log Enhancer
- What does freshbitsweb/laravel-log-enhancer actually add to my Laravel logs?
- It enriches each log entry with request-scoped context such as the authenticated user ID, request URL, IP address, and optionally input and session data, so a log line tells you who hit which endpoint and what they sent. It works by decorating Laravel's existing Monolog pipeline rather than replacing it, so there are no migrations, tables, routes, or facade calls to sprinkle through your code. It is meant to speed up debugging in staging and production, not to replace an APM or structured logging platform.
- How do I install laravel-log-enhancer in a Laravel application?
- Run composer require freshbitsweb/laravel-log-enhancer, then publish the package config with php artisan vendor:publish and adjust the environment toggle. No application code changes are required because the package hooks into Laravel's logging configuration. Run a quick smoke test after install to confirm the enriched context actually appears in the channel you use.
- Which Laravel and Monolog versions does laravel-log-enhancer support?
- The package advertises support for Laravel 5.6 and above. Because Monolog's context and processor APIs changed in Monolog 3, confirm compatibility with your current Laravel 11 or 12 install and Monolog major version before adopting it. Check the composer.json constraints and run a short proof of concept on your exact framework version.
- Can I control which data laravel-log-enhancer captures?
- Capture is controlled through the published config file and an environment toggle, so you can disable the enhancer entirely or limit what gets appended. Treat request input and session capture as opt-in for anything sensitive, since richer payloads increase both PII exposure and log volume. Review the config defaults before enabling it on a production channel.
- Does laravel-log-enhancer work correctly with Laravel Octane or queued jobs?
- This is the item to validate rather than assume: under long-lived workers like Octane or Swoole, statically held request context can bleed between requests if it is not reset. Queue workers and scheduled commands also lack a real HTTP request, so URL, IP, and session fields may be empty or stale there. Write a test that fires two consecutive requests and asserts the second log line does not contain the first request's context.
- What is the performance and log volume impact of enriching every log entry?
- Each enriched line is materially larger, and on high-RPS endpoints that becomes a direct ingestion cost with your log aggregator. Runtime overhead is usually small relative to I/O, but payload size on large form or file-upload requests deserves measurement. Benchmark a representative endpoint and set retention or sampling policies before rolling it out broadly.
- Does laravel-log-enhancer redact passwords, tokens, and PII from logs?
- The package's documented purpose is adding context, not scrubbing it, so do not assume recursive redaction of nested arrays or JSON bodies. If request input or headers are captured, tokens, cookies, and customer data will land in log storage with a different access and retention model than your database. Disable input capture where possible and add your own Monolog processor for allowlisting if you need guarantees.
- Will it conflict with existing Monolog taps, JSON formatters, or my Sentry handler?
- It decorates the existing pipeline through a Monolog processor or tap, so it generally coexists with stack channels and third-party handlers, but ordering matters. Verify how it registers relative to your custom processors in config/logging.php and test both single-line and JSON formatters. A config change to your logging channels can silently disable the enhancer, so keep an owner and a smoke test.
- How do I verify laravel-log-enhancer is actually working?
- Trigger a request that writes a log entry and inspect storage/logs/laravel.log, or the equivalent for your configured channel, for the added user, URL, IP, and session fields. If nothing changes, confirm the enhancer is registered on the channel you are actually using rather than just the default stack. A small automated test asserting the presence of those context fields makes this a durable check instead of a one-off.
- Is laravel-log-enhancer actively maintained, and what are the alternatives?
- It is a small, single-purpose package with a modest GitHub following, so treat it as a single-maintainer dependency and review release cadence before adopting it for production logs. Lighter alternatives include Laravel's built-in Log::withContext for manually scoped context and a custom Monolog processor you control directly. Broader observability needs are better served by Sentry, Datadog, or structured JSON logging with an explicit field schema.
Weaver
How can I help you explore Laravel packages today?