Laravel Http Logger Laravel Package

Product Decisions This Supports

• Build vs. buy for observability plumbing: This package covers a narrow but recurring need — HTTP request/response logging with sane defaults — so it removes a "should we build our own middleware?" debate from the roadmap. Adopt it as a dependency rather than allocating engineering time to a bespoke logger.
• Compliance and data-handling decisions: The header allowlist with sensitive-header masking and body field sanitization/truncation make it materially easier to answer "are we logging PII or auth tokens?" That directly informs whether logging can be enabled in regulated or customer-facing environments, and reduces the scope of a privacy review.
• Incident response and support readiness: Route and status-code filtering let you turn on verbose logging for specific surfaces (e.g. api/*) or failure classes (5xx) without drowning in noise or spiking log storage costs — a lever product/support can pull during a live incident or customer escalation.
• Cost and infrastructure decisions: Filters plus a dedicated log channel mean log volume is a tunable input to observability spend rather than an all-or-nothing switch. Useful when justifying retention tiers or per-environment logging budgets.
• Rollout scoping: Because config is env-driven via a single publishable config/http-logger.php, you can ship it dark in production, enable it per-environment, and evaluate before committing — a low-risk way to standardize logging conventions across services.

When to Consider This Package

Consider it when:

• You're on Laravel and need request/response visibility for debugging, audit, or support triage, and you don't already have a structured logging layer covering it.
• You need selective logging — specific route patterns, specific status classes — rather than logging everything.
• Sensitive data (auth headers, tokens, PII in bodies) is in flight and you need masking/truncation as a first-class feature rather than custom code per project.
• Your team is small enough that maintaining a homegrown middleware listener isn't a good use of time.
• You want one config surface with env overrides so behavior differs cleanly per environment.

Look elsewhere when:

• You need full distributed tracing, span propagation, or APM-grade instrumentation — this is logging, not tracing.
• You require guaranteed shipping/backpressure to an external sink (e.g. buffered async delivery, retries, sampling at scale); you'd want a dedicated observability SDK or log shipper.
• You have strict audit requirements needing tamper-evident, immutable records and retention controls beyond a log channel.
• You're not on Laravel, or you're on a version where the RequestHandled listener pattern isn't available.
• Your needs are already met by existing middleware or a platform-provided gateway/CDN access log.

Caveats worth flagging: This is a 0.1.0 initial release. Public API and config keys should be treated as unstable; pin the version and expect breaking changes before 1.0. The stated "full test coverage" is self-reported — verify it in CI before depending on it in production paths.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost dependency that gives us production-grade HTTP logging without building it ourselves. It ships with privacy guardrails — sensitive headers and body fields are masked, long payloads truncated — so we can enable logging in customer-facing environments without a lengthy data-handling review. Filtering by route and status means we control log volume and therefore cost. Risk is low and contained: it's an early-stage (0.1.0) package, so we'll pin the version, enable it in non-production first, and validate test coverage in our own CI before broader rollout.

For engineering: Drop-in Laravel listener that logs requests/responses through a dedicated channel with a [HttpLogger] prefix. Configuration is a single publishable file with env support: route pattern filters (api/*), status-range filters (1xx–5xx), header allowlists with masking, and body field sanitization plus truncation. Everything is opt-in and environment-scoped, so we can enable it dark and tune before committing. Action items: pin to 0.1.0, confirm the claimed unit/feature/integration tests run in our pipeline, and agree on default masking rules for our domain before enabling in production.