Laravel Http Logger Laravel Package

Product Decisions This Supports

• Build vs. buy for request-level observability. The package answers "do we need to build our own request logger?" with a clear no: it's a thin middleware (~one class plus a config file) that captures method, URI, request body, and headers for non-GET requests and writes them to the Laravel log channel. Any custom build would reproduce this in an afternoon but then need ongoing maintenance — this is a low-cost "buy" (free, MIT) that we can drop in and forget.
• Feature scope for lead-generation and other critical submission flows. The README frames the package explicitly as an "extra safety net for critical user submissions, such as forms that generate leads." That makes it a concrete, cheap risk-mitigation decision for any form where a lost payload means lost revenue: if a downstream job, third-party API call, or validation step fails after the request arrives, we still have the original payload to recover or replay.
• Production incident triage / support workflow. When a customer reports "I submitted the form and got an error," the current options are asking them to reproduce it or digging through application logs that may not include the body. This package makes the raw inbound request available after the fact — a direct reduction in mean time to resolution and in support escalations.
• Security and privacy posture decisions. The config exposes exactly the levers a PM needs to make a go/no-go call: an except list (defaults to password and password_confirmation), a sanitize_headers list (e.g. Authorization, Cookie, Set-Cookie), a dedicated log_channel, a log_level, and an enabled flag bound to HTTP_LOGGER_ENABLED. That means we can ship this with a defensible redaction story rather than "we log everything and hope."
• Cost and noise control as a product decision, not an afterthought. Three independent throttles: (1) global on/off per environment via env var, (2) a swappable LogProfile that decides which requests get logged, and (3) per-route middleware attachment so we can enable it only on high-value endpoints (checkout, lead forms, webhooks) instead of the whole app. This lets us choose "log everything in staging, log only the 4 revenue-critical endpoints in prod."
• Roadmap sequencing for observability work. Because it is a single middleware with a stable, tiny interface (LogProfile::shouldLogRequest, LogWriter::logRequest), it functions well as a stopgap on the roadmap — ship in a sprint, buy time, and defer investment in a proper structured audit/event pipeline until there's evidence of need. Replacing it later is a config change plus a custom writer class, not a migration.
• Standards alignment decisions. 1.12.0 adds the QUERY HTTP method to LogNonGetRequests alongside POST/PUT/PATCH/DELETE, and the release history tracks every Laravel major (L9 through L13). For a PM, that's evidence the package follows the framework's direction, so picking it doesn't create a "stuck on an old Laravel" decision later.
• Vendor/concentration risk assessment. Spatie-maintained, MIT, active changelog and releases, documented interfaces for extension. The trade-off to weigh: 673 stars and a listing of zero dependents is a small ecosystem signal — fine for a package this thin (we could fork and own it in a day), but a reason not to build a compliance program on top of it.

When to Consider This Package

• Adopt when the need is forensic, not analytical: you want to answer "what exactly did this user send at 14:32?" for a small set of write endpoints, and you're comfortable reading that out of a log file or your log aggregator.
• Adopt when the alternative is nothing. If today you have no record of inbound POST bodies and an incident costs you real money per occurrence, the marginal value here is high and the integration cost is one composer require plus one middleware registration.
• Adopt when you need it scoped narrowly. Route-level middleware attachment is the recommended pattern for teams worried about volume or PII exposure — start with lead forms and webhooks only.
• Adopt when you're on Laravel 12+/PHP 8.3+ if you want the current 1.12.x line; note the 1.12.0 release explicitly dropped older PHP and Laravel versions, so pin accordingly if you're behind.
• Adopt when low lock-in matters. The whole integration surface is two interfaces and a config array; exit cost is near zero.
• Look elsewhere when you need a queryable audit trail — this writes flat log lines to a log channel. If the requirement is "list every state change to record X for the last 24 months, filterable by user," you want a database-backed audit/activity log (e.g. spatie/laravel-activitylog or an in-house audit_events table), not file logs.
• Look elsewhere when the requirement is compliance-grade. No retention policy, no tamper-evidence, no integrity guarantees, no automatic PII classification beyond a static except list. Log files rotate and disappear; that is not an audit record a regulator or auditor will accept.
• Look elsewhere when you need response logging, latency metrics, sampling, tracing, or correlation IDs across services. This captures inbound requests only — pair it with (or replace it by) OpenTelemetry/APM tooling or a structured event pipeline if the actual goal is observability rather than forensics.
• Look elsewhere when volume is high and body sizes are large. Full request bodies (including file uploads, per the changelog history) landing in log files can be a real storage and cost line item, and can degrade log-aggregator performance more than it's worth.
• Be cautious when the data is regulated (health, payment, government IDs). The default redaction covers passwords only — you must own the except list and sanitize_headers configuration, and you should get security sign-off before enabling it on endpoints carrying sensitive fields.

How to Pitch It (Stakeholders)

For executives (one paragraph): We lose revenue when a customer's submission fails and we can't reconstruct what they sent. This is a free, MIT-licensed, Spatie-maintained Laravel package that records the details of incoming form and API submissions to our existing logs — it's the difference between "the customer says they submitted the form" and "here is exactly what they submitted." Integration is roughly one dependency and one line of middleware registration, it can be switched off entirely per environment with a single setting, and it can be limited to just the handful of endpoints that generate revenue. It is not a compliance audit system and it is not a replacement for our monitoring; it's a cheap safety net that pays for itself the first time we recover a lost lead without asking the customer to resubmit.

For engineering (the short version): Add spatie/laravel-http-logger, register Spatie\HttpLogger\Middlewares\HttpLogger — globally if you want broad coverage, or per-route on the endpoints that matter. By default it logs POST/PUT/PATCH/DELETE/QUERY to the default log channel; override log_profile to narrow that, log_writer to change the output format or destination, log_channel and log_level for routing, and except/sanitize_headers for redaction. Gate it with HTTP_LOGGER_ENABLED so it's off in local and on in production. It's stable, tracks every Laravel major through 13, and the entire extension surface is two interfaces — if we ever outgrow it, a custom LogWriter that writes to a table is a contained change, not a rewrite.

The honest caveat to state up front: this produces log lines, not a database. It is a debugging and lead-recovery tool with a small footprint and a small community (673 stars, no listed dependents), which is proportionate to its size but means we should treat it as a utility we can comfortably fork, not a platform. If the business requirement turns out to be auditability, retention, or reporting, that's a separate and larger initiative.