Laravel Monitor Laravel Package

Product Decisions This Supports

Ship monitoring to production with real customer data — yes/no. The single biggest blocker to turning on request/error telemetry in a customer-facing app is "what leaves the process?" This release closes three concrete leak paths that would otherwise have been our liability: headers we didn't think to scrub, tokens straddling the truncation boundary, and route parameters (reset tokens, verification hashes) sitting in reported URLs. That materially changes the risk calculus from "we'd need a bespoke review before enabling" to "defensible with a documented config."

Build vs. buy — buy. The changelog is the argument. Header masking by name-list, hard-cut truncation, and shape-based token detection are exactly the defects a homegrown redaction layer ships with, and they're invisible in testing because they only fail on the one request shape nobody wrote a test for. Building this in-house means owning a security-sensitive parser forever, with no changelog to learn from.

Roadmap: monitoring moves from "internal nice-to-have" to a sellable capability. With an allow-list for outgoing headers, credential masking by shape (queued path included), and encoded-URL masking through ValueRedactor, we can answer security questionnaires with specifics rather than assurances. That unlocks the regulated segments (fintech, health, public sector) whose DPIA process will ask precisely these questions.

Positioning and packaging. "Self-hosted, privacy-first Laravel monitoring" is only credible if the redaction story holds up. v0.6.0 is the evidence for that claim — worth citing in marketing/security pages, not just the changelog.

Operational ownership decision. monitor.request_headers is now a first-class config surface. Someone must own it: the visitor IP headers (x-forwarded-for, forwarded, etc.) are deliberately not on the allow list, and enabling them requires a legal basis plus removal from scrub. This is a policy artifact, not a toggle. If we adopt, we assign an owner before go-live.

Upgrade planning. v0.6.0 requires the core at ^0.6.0, and PayloadBuilder takes a sixth constructor argument (headers sent in clear; null falls back to PayloadBuilder::HEADERS). Any custom integration or subclass touching that constructor needs a coordinated bump — schedule it, don't discover it in CI. Also note the published config now writes 'redact' => null, and previously published copies listing ['email','iban','nir','card','phone'] are read as that default, so existing installs keep masking without edits.

Support/churn hygiene. Because the published config no longer names package classes, uninstalling never leaves a fatal file behind — a small thing that removes a recurring class of support ticket.

When to Consider This Package

Consider it when:

• You run a Laravel app handling customer PII and want production telemetry that doesn't ship raw request context to a third-party SaaS.
• A security review or DPIA will ask "what data leaves the application, and how is it masked?" — and you want a documented, auditable answer.
• Your platform team is small and you have no appetite to build and maintain a redaction pipeline (header allow-lists, credential shape detection, truncation-safe masking) as a side project.
• You already have (or plan to have) your own log/observability backend and just need the collection, masking, and transport layer.
• You need request context and log collection — not full APM, tracing, or session replay.
• You can absorb pre-1.0 churn: pin an exact version, read each changelog, budget upgrade time per release.

Look elsewhere when:

• You need distributed tracing, profiling, front-end/browser monitoring, session replay, or mature alert routing. This is a redaction-and-transport layer, not an APM suite.
• You require a stable 1.0 API contract, a vendor SLA, or a vendor-issued SOC 2 report. Pre-1.0 means minor versions can break you — v0.6.0 changed a constructor signature and raised a hard dependency floor.
• You have no process owner for scrub / monitor.request_headers. The allow list is only as good as the review behind it; an unowned config drifts into either over-collection or blind spots.
• You want IP-based geolocation or abuse analytics out of the box. Visitor IP headers are excluded by design and require a legal basis to enable — if that's a core requirement, this package will fight you.
• Your team lacks the Laravel version parity or upgrade cadence to track a fast-moving pre-1.0 dependency and its core package in lockstep.

How to Pitch It (Stakeholders)

For executives — one paragraph: We're evaluating a self-hosted monitoring package for our Laravel services. The new release (v0.6.0) is almost entirely a security hardening release: it stops request headers being sent unless explicitly allow-listed, masks credentials and reset tokens by their shape rather than by guessing at names, fixes a truncation bug that could leak half a token, and keeps all of this applied on the queued delivery path too. In plain terms: the failure mode where our own error reports quietly become a data leak has been largely engineered out, and we can now answer customer security questionnaires with specifics. The trade-off is that this is pre-1.0 software — upgrades require deliberate scheduling.

For engineering:

• Upgrade is coordinated, not drop-in: core must be ^0.6.0, and PayloadBuilder gained a sixth constructor argument (headers sent in clear; null uses PayloadBuilder::HEADERS). Check for any construction of it outside the package's own wiring.
• Previously published configs are safe: a file listing ['email','iban','nir','card','phone'] is interpreted as the old default, and the new template writes 'redact' => null so config no longer references package classes.
• Request context above the server's 65,535-byte limit is replaced with the server's marker before masking rather than scanned whole — relevant if we rely on very large payloads for debugging.
• Masking order changed: soft-cut at whitespace past 8,192 chars, mask whole, then cut hard. Verify our log-line expectations if any tooling parses truncated payloads.
• IP headers (forwarded included, since it masks x-forwarded-for by substring) are opt-in only — do not enable without legal sign-off.

The ask: approve a time-boxed pilot on one non-critical service, pin the exact version, assign a named owner for the redaction config, and review each release changelog before bumping. Success criteria: security review signs off on the data egress story, and the upgrade cost per release proves manageable over two cycles.