Laravel Http Logger Laravel Package

Getting Started

Install the package and let Laravel's package discovery register it:

composer require dragon-code/laravel-http-logger

Publish and inspect the configuration before writing any code:

php artisan vendor:publish --provider="DragonCode\LaravelHttpLogger\ServiceProvider"

Open config/http-logger.php and confirm the essentials: whether logging is enabled, where records are written (a Laravel log channel or a database table), and which paths can be excluded. Then register the package middleware. In Laravel 11+ this typically means adding it to the appropriate middleware group in bootstrap/app.php; on older versions, add it to app/Http/Kernel.php. For a first use case, scope it to an API route group rather than globally:

Route::middleware('http-logger')->group(function () {
    Route::get('/orders/{order}', [OrderController::class, 'show']);
});

Make one request, then verify the output in the configured destination—tail the dedicated log file or query the logging table. If nothing appears, check middleware registration, config cache, and the package's enabled flag before assuming the package is broken.

Version 1.6.0 adds Laravel 13 compatibility, so the package tracks current framework releases and is a reasonable default choice on new Laravel versions. Still apply a normal constraint ("dragon-code/laravel-http-logger": "^1.6") rather than a floating dev-main, and skim the middleware and service provider once so you know exactly what it writes.

Implementation Patterns

Scope middleware deliberately. Global logging is convenient for audits but noisy. Prefer route groups: log api/* and authenticated web routes, exclude /up, health checks, Telescope, Horizon, asset routes, and webhook endpoints that already have their own audit trail.

Use a dedicated channel. Route HTTP request logs to their own channel rather than stack/single. A daily channel with a JSON formatter gives you searchable records without mixing request noise into application error logs:

// config/logging.php
'http' => [
    'driver' => 'daily',
    'path' => storage_path('logs/http.log'),
    'level' => 'info',
    'days' => 14,
],

Then point the package config at that channel.

Add request correlation. Generate or accept an X-Request-ID in a lightweight middleware that runs before the logger, and include it in the log context. This lets you join an HTTP request log to application exceptions and downstream service calls.

Redact aggressively. Request payloads routinely contain passwords, bearer tokens, session IDs, and personal data. Configure the package's ignored/except fields—or wrap the logging middleware with your own sanitizer—so password, password_confirmation, authorization, token, and similar keys never reach disk. Review this again before enabling logging on login or payment routes.

Control volume. High-traffic endpoints can generate enormous logs. Use path exclusions, sampling, or a separate low-retention channel for noisy routes. If the package supports queued or deferred writing, use it for non-critical audit logs; otherwise keep the middleware on a fast channel and rotate logs aggressively.

Test the integration. In feature tests, fake the log facade or spy on the configured channel and assert that a request produces the expected record. Also disable HTTP logging in the testing environment so test output and assertions are not polluted.

Keep it separate from business auditing. This package logs incoming HTTP traffic; it is not a substitute for domain event logging. If you need “who changed this order,” emit an application event or use a model-audit package rather than parsing request logs.

Pin and upgrade deliberately. Minor bumps have so far been additive (1.6.0 = Laravel 13 support, LICENSE/banner housekeeping), but run your integration tests after each upgrade—especially across a major Laravel jump, where middleware registration in bootstrap/app.php is the most likely thing to need attention.

Gotchas and Tips

• Verify maintenance cadence per release. 1.6.0 ships Laravel 13 support, which is a good signal, but the release also consists largely of automated housekeeping commits. Check the changelog and open issues before adopting it for anything compliance-sensitive, and read the diff of a minor release before bumping.
• Middleware order matters. The logger sees only what has already been parsed. If it runs before authentication, user_id will be empty; if it runs after, you get identity but may log more sensitive context. Choose deliberately and document it.
• Response logging and termination. If the package logs responses, remember that terminable middleware runs after the response is sent. Exceptions thrown there can be invisible or awkward to debug; check storage/logs and the Laravel log for middleware failures.
• Config cache. After publishing or editing config/http-logger.php, run php artisan config:clear (and config:cache in production). A stale cached config is the most common reason “the package isn’t logging.”
• Missing logs checklist: confirm the middleware is actually in the route’s middleware stack (php artisan route:list -v), confirm the package is enabled for the current environment, check file permissions and disk space, and verify the configured channel exists in config/logging.php.
• Log rotation and disk pressure. Daily logs plus request bodies can fill a disk quickly. Set retention, monitor storage/logs, and avoid logging full payloads for file uploads or large JSON bodies.
• Octane and long-running workers. Avoid relying on request-scoped state stored in singletons. If you customize the logger, resolve per-request context inside the middleware rather than at container bind time.
• Extension points. The cleanest customization is usually a thin middleware around the package: generate request IDs, sanitize input, add tenant/user context, then delegate to the package logger. Prefer that over editing vendor code, which makes future upgrades harder.
• Keep an adapter boundary. Even with active maintenance, wrap the package behind your own middleware alias or a small adapter class so you can swap in an alternative—or a few lines of Log::channel('http')->info(...)—without touching every route definition.