Laravel Request Logger Laravel Package

Product Decisions This Supports

• Request-level auditability vs. no audit trail. always-open/laravel-request-logger is a middleware-layer request/response logger: it captures inbound HTTP traffic into Laravel's log channels. The product decision it unlocks is "do we need a durable, queryable record of who called what, when, and with which payload/status" — which is an audit/compliance requirement, not an observability nicety.
• Build vs. buy for request logging. The alternative is a 30–80 line custom middleware plus a logging channel config. This package is only worth adopting if it saves you that work and handles the parts teams get wrong: log rotation, channel configuration, request body capture, and redaction hooks. If your needs are one-off, building is cheaper than a dependency.
• Tiering the observability stack. This is not an APM. It does not do tracing, latency percentiles, or error aggregation. The decision it supports is scoping: use this for compliance/audit retention, and keep Sentry/Datadog/Telescope for debugging and performance. Choosing this package should explicitly mean "we are not buying an APM for audit purposes."
• Compliance posture for regulated customers. SOC 2 / HIPAA / financial-services buyers ask for access logs. A supported, versioned package with an active maintainer is a materially easier security review than "we wrote it ourselves and forgot about it."
• Roadmap signal from v4.0.0. This release is framework-compatibility work only (Laravel 13 support, FLUX-911). Read that as: the package is maintained but feature-stable. Plan accordingly — it is a low-innovation, low-risk dependency, not a platform bet.
• Upgrade-window planning. A major version bump gated on a new Laravel major usually implies dropping support for older framework versions. That makes this a scheduled maintenance task tied to your Laravel upgrade calendar, not an ad-hoc change.

When to Consider This Package

Consider adopting when:

• You have a concrete audit, compliance, or customer-contract requirement for request logs with retention.
• You are on Laravel 13 (or planning to be within the next two quarters) — v4.0.0 is the version that tracks the current framework.
• You are already centralized on Laravel's logging stack (Monolog channels, daily/stack drivers, external sinks like Papertrail or CloudWatch) and want request capture to flow through the same pipe.
• You want a maintained dependency rather than an in-house middleware that no one owns after the original author leaves.
• Your request volume and payload sizes are modest enough that synchronous log writes will not dominate request latency.

Look elsewhere when:

• You need PII handling guarantees. Confirm in a spike — not from the README — that the package redacts the fields you care about (auth headers, tokens, card numbers, health data). Request logging that captures bodies verbatim is a compliance liability, and a security review will block it.
• You are on Laravel 10 or 11 with no upgrade path. v4.0.0 is pinned to Laravel 13 support; stay on v3.1.0 and accept that you are on an unsupported line, or do not adopt.
• You need performance observability. Use OpenTelemetry, Sentry, or Laravel Telescope. This package stores text; it does not give you traces or dashboards.
• You need guaranteed, tamper-evident delivery. Application logs are best-effort and local-disk-by-default. If the requirement is "immutable audit log with delivery guarantees," you need a dedicated audit service (e.g., an append-only store or a SIEM), with this package at most as a feeder.
• You are high-throughput. Logging every request body synchronously will show up in p95. Benchmark before committing.
• The dependency surface is disproportionate. Check composer.json for transitive weight. A logging middleware pulling in a large tree is a poor trade.

Assessment caveat: this review is based on the v4.0.0 release notes alone — a single framework-support change. The above is framed around the package's category and the upgrade signal; validate redaction behavior, throughput characteristics, and maintenance cadence (commit frequency, open issue response) directly before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small, focused open-source library that records every inbound HTTP request to our application's log. The business value is auditability — it gives us a defensible answer to "who accessed what, and when," which is a recurring question in enterprise security reviews and compliance audits. The newly released v4.0.0 does one thing: it keeps the library compatible with the current version of our PHP framework. That signals a maintained but stable dependency — low risk, low ongoing cost. The decision is not "should we buy an observability platform"; it is "do we adopt a maintained component for audit logging, or keep maintaining our own."

For engineering leadership:

• Scope: request/response capture into existing Laravel log channels. No APM, no tracing, no UI. Deliberately narrow.
• Cost: one Composer dependency plus a middleware registration and log channel config — roughly half a day to instrument, plus retention/storage costs that scale with traffic.
• Risk: the primary risk is PII landing in logs. That must be resolved with explicit redaction config and a verification test before this goes anywhere near production.
• v4.0.0 is a major version bump for Laravel 13 support only. Treat it as a maintenance upgrade. Expect that older Laravel versions are no longer supported on this line — sequence the upgrade with our own framework upgrade, not independently.
• Recommendation: adopt on a non-critical service first, measure latency impact at realistic traffic, and gate production rollout on a redaction test passing.

For security/compliance:

• The package provides the capture mechanism; retention, access control, encryption at rest, and immutability are our responsibility, configured at the log sink.
• Request bodies may contain regulated data. The control is redaction at the middleware boundary — we must be able to demonstrate which fields are excluded.
• Logs are best-effort by default. If the requirement is evidentiary-grade, this package is a feeder into a proper audit store, not the store itself.