Laravel Http Logger Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin, single-purpose Laravel middleware (Spatie\HttpLogger\Middlewares\HttpLogger) that captures inbound request metadata and body, then hands it to a LogWriter for emission through Laravel's native logging stack. There is no service, queue, database schema, or external dependency introduced — it sits entirely inside the existing HTTP kernel and Log facade, which makes it architecturally low-impact and easy to reason about in a design review.
• Its stated purpose is a forensic safety net for high-value submissions (lead-gen forms, checkouts, applications) rather than general observability. That framing matters: it is not an APM, not an audit trail with integrity guarantees, and not a substitute for structured request logging in Datadog/Sentry/Pulse. Treat it as a replay buffer for "what exactly did the user send before we 500'd."
• Two seams make it genuinely extensible: LogProfile::shouldLogRequest() controls whether to log, and LogWriter::logRequest() controls how. Both are interface-bound and config-swappable, so custom redaction, JSON-structured output, tenant tagging, or queued writes can be introduced without touching vendor code. This is the package's main architectural asset and the reason it survives compliance review better than a hand-rolled Log::info() in middleware.
• Weak fit for teams already running Telescope, Pulse, or an APM with request-body capture — you would be paying duplicate log volume and duplicate PII exposure for largely overlapping capability. The differentiator only appears when body payloads must survive a hard failure (fatal error, timeout, container crash) where in-memory debug tooling loses the request.

Integration feasibility

• Extremely low effort: composer require, optional config publish, one middleware registration (global via ->withMiddleware() on Laravel 11+, or a single route/group). A competent Laravel engineer can have it running in staging in under an hour; hardening the redaction config is the real work.
• No migration, no schema, no data backfill, no API surface change. Rollback is deleting one line of middleware registration plus the composer entry.

Technical risk

• PII/compliance exposure is the dominant risk, not technology. Defaults exclude only password and password_confirmation, and sanitize_headers ships empty. Any endpoint carrying emails, phone numbers, addresses, national IDs, card-adjacent fields, free-text support messages, or bearer tokens will land in log storage verbatim unless explicitly configured. Log storage typically has different access controls and retention than the primary datastore, which is exactly the pattern regulators flag.
• Version cliff at 1.12.0: PHP < 8.3 and Laravel < 12 are dropped. Teams on Laravel 10/11 must pin 1.11.x and forgo the QUERY-method support added in 1.12.0. This is a hard compatibility gate to resolve before adoption, not after.
• Synchronous write in the request path. Logging happens inline before the response completes; a slow or blocking log channel (network syslog, remote HTTP handler, saturated disk) directly adds latency and can convert a successful request into a 500 if the handler throws. Most Laravel log handlers propagate exceptions.
• Unbounded payload capture. No size cap, no sampling, no field-level truncation in the default writer. Large multipart submissions or verbose JSON bodies inflate log volume and storage cost nonlinearly with traffic.
• Weak signal on ecosystem validation. 673 stars is respectable for a utility, but zero listed dependents and a small code surface mean you get little third-party battle-testing. The mitigating factor is that the entire package is small enough to fork or reimplement in-house (~50 lines of middleware) if Spatie ever abandons it.
• Key questions to resolve before approval: Which endpoints and HTTP verbs are in scope? What is the log retention period and who can read it? Does the log channel have the same data-residency posture as the application? Is an exception in the log writer allowed to fail the request (it should not)? Is there a payload size cap? How are uploaded files serialized, and do file metadata or contents leak? Is HTTP_LOGGER_ENABLED wired per-environment in the deployment manifests?

Integration Approach

Stack fit

• Native fit for any Laravel 12+/PHP 8.3+ application, which is where the current release line lives. Laravel 11 shops should pin ^1.11 and accept the feature freeze. Laravel ≤10 is effectively out of scope.
• Requires a deliberate decision on log channel. Defaulting to the application's stack channel mixes request bodies into general application logs, which is bad for both retrieval and retention policy. The recommended pattern is a dedicated channel (e.g., http-logger → daily-rotated file or a separate log sink) with its own retention rule and access boundary, selected via LOG_CHANNEL or the log_channel config key.
• Works cleanly alongside existing observability; it complements rather than conflicts with Telescope/Pulse/Sentry, provided the team agrees on the non-overlap rationale up front.

Migration path

1. Pin the version against the framework matrix; record the ceiling imposed by 1.12.0's PHP 8.3 / Laravel 12 floor.
2. Publish config/http-logger.php into version control so redaction is code-reviewed rather than environment-dependent.
3. Author a custom LogWriter if structured JSON output, tenant identifiers, or async dispatch is required — this is the single highest-leverage customization and should not be deferred past the pilot.
4. Extend except with every PII-bearing field per endpoint, and populate sanitize_headers with Authorization, Cookie, Set-Cookie, and any internal auth tokens.
5. Register the middleware route-scoped on a small set of critical POST endpoints first, then promote to global only if volume and latency measurements support it.

Compatibility

• The one breaking boundary is the 1.12.0 platform floor. Secondary compatibility surface: sanitize_headers requires ≥1.10.2, configurable log_level ≥1.10.0, configurable log_channel ≥1.8.0, request-file handling ≥1.4.0, header capture ≥1.6.0. Anything older lacks the redaction and channel controls that make this acceptable from a risk standpoint — do not adopt below 1.10.x.
• Dev tooling moved to Pest 4, which only affects contributors, not consumers.

Sequencing

• Phase 1 (week 1): version pin, dedicated log channel, hardened except and sanitize_headers, HTTP_LOGGER_ENABLED=false in local and test.
• Phase 2 (week 2): route-scoped pilot on two or three highest-value write endpoints in staging; measure added p95 latency, log bytes per 1k requests, and confirm redaction by inspecting real log lines.
• Phase 3 (weeks 3–4): production pilot on the same routes, with a runbook for querying the log during incident triage.
• Phase 4: decide on global promotion or permanent route-scoping based on measured volume and whether the forensic value materialized in at least one real incident. Do not promote by default — most teams will find route-scoping sufficient and far cheaper.

Operational Impact

Maintenance

• Near-zero: no schema, no migrations, no background workers, no versioned API. Upgrades track Laravel major releases via laravel-shift PRs, which historically land promptly.
• Real maintenance burden is config drift: as new endpoints ship, except and sanitize_headers silently fall out of date. Assign ownership to the team that owns the endpoint inventory, and add a PR checklist item requiring review of http-logger.php whenever a form or write endpoint changes. This is the single most likely way the package becomes a liability.

Support

• MIT, Spatie-maintained, active enough to have shipped Laravel 13 and QUERY-method support. Small code surface means in-house patching is trivial; a fork is a realistic fallback and should be noted in the risk register as "abandonment: low impact."
• Support boundaries to set explicitly: the platform team owns the config and channel; application teams own their endpoint's redaction coverage; security owns retention and access review.

Scaling

• Log volume scales linearly with write traffic and payload size, with no sampling or trimming built in. At high volumes this becomes a storage-cost and log-rotation problem before it becomes a performance problem.
• Mitigations, in order of preference: route-scope instead of global; cap payload size in a custom LogWriter; push writes to a queue in the custom writer to decouple from request latency; narrow LogProfile to specific URIs rather than all non-GET verbs; set the log channel to a rotating handler with an explicit retention window.
• The default LogNonGetRequests profile will capture webhooks, health-check POSTs, and internal service calls if applied globally — a common source of surprise volume.

Failure modes

• Log channel unreachable or misconfigured → exception mid-request, user-facing 500 on an otherwise valid submission. Highest-severity failure. Require a custom writer that wraps emission in a try/catch and swallows (or downgrades to a metric), and test the failure path with the channel deliberately broken.
• Disk exhaustion from unbounded logging → cascade failure across the node, not just degraded logging. Needs rotation and retention configured before the pilot, not after.
• PII leakage into logs → compliance incident discovered during an audit or subject-access request, typically months after the fact. Mitigate with a staging redaction review that inspects actual emitted lines.
• Log flooding masking signal → the forensic channel becomes unusable exactly when it's needed. Mitigate with sampling or strict route scoping.
• Silent drift after config changes → new fields added to a form are logged unredacted. Mitigate through the PR checklist noted above.

Ramp-up

• Engineer productivity cost is genuinely low: one hour to install and register, half a day to harden config, one to two days to write and test a custom LogWriter if structured output or async dispatch is wanted. No training program required.
• The non-engineering ramp is the real cost: security/compliance sign-off on what is captured, where it lives, how long it is retained, and who can read it. Budget one to two weeks of review for a regulated environment, and expect that review to drive further redaction scope reduction.
• Overall recommendation: approve as a narrowly scoped, route-level forensic tool for a defined set of high-value write endpoints on Laravel 12+/PHP 8.3+, contingent on (a) a dedicated log channel with explicit retention, (b) a reviewed and tested redaction config, and (c) a custom LogWriter that cannot fail the request. Reject any proposal to enable it globally with default configuration — the default redaction posture is not defensible for production PII, and the latency and volume characteristics are unmeasured.