Laravel Http Logger Laravel Package

Product Decisions This Supports

• Build vs. buy for request observability. The core question this package forces is whether inbound HTTP logging is a differentiated capability or commodity plumbing. It is commodity: a single middleware that writes request metadata to a log channel. Release 1.6.0 does not change this — a Laravel 13 compatibility bump is a line of glue code, not a platform capability. We're still buying ~150 lines of code and a config file.
• Whether to instrument now or wait for an APM investment. Request logging is the cheapest first step toward observability. Adopting something like this lets us answer "what traffic hit us at 14:02 when the customer complained?" without committing budget to Datadog/Sentry/New Relic. It buys time and data to justify (or kill) a larger APM purchase.
• Support and incident-triage capability. Concretely enables: reproducing a customer bug from their request payload and headers, confirming whether a 500 was our fault or malformed input, and auditing which endpoints are actually used before we deprecate them.
• Roadmap sequencing for compliance/audit features. If a customer or auditor asks for an access trail, this is a scoping input: "request-level logging exists as a pattern; a compliance-grade audit log (immutable storage, PII redaction, retention policy, legal hold) is a separate, larger workstream."
• Deprecation and API-sunset decisions. Aggregated request logs per route give usage evidence to retire endpoints without guessing.
• Ecosystem validation signal — unchanged in substance. 1.6.0 is one functional commit (Laravel 13 support) alongside three automation commits (license year, preview, banner). That is a compatibility pulse, not a maintenance commitment. Treat this as a reference implementation, not a dependency decision; the real product decision remains "do we write our own middleware modeled on this?"
• Upgrade-path risk for our next Laravel major. This release is a small but real data point: when Laravel 13 landed, someone shipped a fix. That marginally reduces the "we'll be stranded on an old major" scenario for a fork-and-own posture, and it is worth noting as evidence that the pattern survives framework churn.

When to Consider This Package

Consider it when:

• We need inbound request logging in a small-to-medium Laravel app and want a working reference for middleware structure, channel configuration, and what fields are worth capturing (method, path, status, duration, IP, user agent).
• We want to avoid pulling a full APM or Laravel Telescope into a production path — Telescope is a dev tool with its own storage and performance profile, and it is not a substitute for durable request logs.
• The team is comfortable forking/vendoring MIT code and owning it. This remains the only responsible posture given the thin maintenance surface.
• Scope is internal tooling, a staging environment, or a low-traffic service where a simple log channel is proportionate.
• We are on, or planning to move to, Laravel 13 and want a reference that has at least been touched for that major. 1.6.0 is the first release that clears this bar.

Look elsewhere when:

• We need a real maintenance and security-response commitment. This is the dominant criterion. 1.6.0 does not establish a support policy, a security disclosure process, or a maintainer SLA, and the commit mix is dominated by automation. Re-verify the repository's current archived/active status before relying on it — a compatibility release is not, by itself, evidence that the project is actively maintained. Any adoption is really an adoption-and-fork.
• We need production scale or retention. Log-file-based request logging degrades under volume, complicates PII handling, and offers no query interface. Use structured logs shipped to a log aggregator, or an APM.
• We need compliance-grade auditing. Requirements like tamper-evidence, defined retention, redaction of tokens/PII, and access controls are out of scope for a logger like this.
• We need field evidence of compatibility across Laravel majors, not a single patch commit. One Laravel 13 commit with no published compatibility matrix or CI signal is weaker assurance than it appears; test against our version ourselves.
• We already run Telescope, Sentry, or an OTel pipeline. Duplicative; consolidate rather than add a fourth sink.
• The logging requirement is a one-liner. If we only need "log slow requests over 500ms," write ten lines of middleware and skip the dependency entirely.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed utility for recording inbound HTTP requests. It is not a strategic dependency and should not be budgeted as one. The 1.6.0 release adds Laravel 13 compatibility — a genuine but minimal signal of life, delivered mostly by automation with a single functional contribution. There is still no support commitment, and community adoption remains negligible, so we would own the code regardless. Recommendation: do not add it as a maintained dependency; use it as a design reference and have engineering implement the equivalent in-house — roughly one day of work — so we control compatibility, PII redaction, and retention. This delivers the immediate triage and audit value at effectively zero vendor risk, and defers any real observability spend until we have data to justify it.

Engineering: Treat this as sample code. It is a middleware that writes request metadata to a configured log channel — useful as a checklist for which fields matter and how to wire channels. 1.6.0 confirms the pattern still compiles against Laravel 13, but it does not give us a security-response commitment or a compatibility matrix across majors. Either vendor the middleware into app/Http/Middleware with tests, or reimplement it; if you vendor it, pin the version you copied and record the commit hash. Non-negotiables if we ship this: redact Authorization, cookies, and known PII fields; exclude health checks and static assets; sample high-volume endpoints; and route to a channel with rotation and retention rather than a single unpinned file. Pair it with a decision on where logs ultimately live — if the answer is a log aggregator or APM, build toward that sink now instead of migrating twice.