Error Log Bundle Laravel Package

Product Decisions This Supports

• Observability roadmap item: whether error capture/retention is a "build it, buy it, or adopt a package" decision this quarter. A DB-backed error log covers the internal-tooling and support-triage use case without an APM contract.
• Build vs buy: replaces a recurring custom task (error table + exception listener + admin viewer) with a maintained dependency. The alternative spend is Sentry/Flare/Rollbar seats or ~1–2 engineer-weeks of in-house code that then needs owning.
• Feature bets it unlocks cheaply: "recent errors" panels in admin, support ticket triage with real stack traces, audit trail for failed jobs/webhooks/integrations, per-tenant error isolation via joins on your own tables.
• Data governance: errors stay in our database — relevant if we have residency/PII constraints that make third-party error SaaS a legal review.
• Maintenance cost line: pre-1.0 versioning (v0.1.1 → v0.2.0) means upgrade churn is a standing roadmap tax, not a one-off.

When to Consider This Package

Adopt when:

• Laravel app with modest-to-moderate traffic and no existing error-tracking vendor.
• You specifically want errors queryable alongside your domain data (users, orders, tenants) — the thing SaaS tools are bad at.
• Small team, low appetite for maintaining custom exception-handling plumbing.
• Data-residency or procurement friction blocks a third-party SaaS.

Look elsewhere when:

• High-volume production: per-error DB writes and unbounded table growth become a real cost; prefer Sentry/OpenTelemetry with a dedicated store and retention policy.
• You need alerting, release/regression tracking, source maps, or tracing — this is a log, not an APM.
• Policy requires 1.0+ dependencies with documented backward-compatibility guarantees. This is 0.x; under semver, a 0.x minor bump may legitimately contain breaking changes.
• Diligence flag on this release: v0.2.0 ships with no human-readable notes — only a compare link. Treat the changelog as unread until engineering has diffed v0.1.1...v0.2.0 for schema migrations, config key renames, and listener signature changes. Also confirm actual Laravel support: the ...Bundle naming is Symfony convention, so framework compatibility must be verified before it enters a Laravel build.

How to Pitch It (Stakeholders)

Executives: A small, self-hosted error-logging package for our PHP stack. Low adoption cost, no per-seat licence, and error data stays in our own database — which shortens security review and removes a vendor from the procurement queue. It also retires a "we should really build this ourselves" backlog item. The trade-off is maturity: it's pre-1.0, and this release shipped without release notes, so we position it as a time-boxed evaluation, not a platform standard.

Engineering: Pin an exact version — no caret ranges on a 0.x package. Before merging: review the v0.1.1...v0.2.0 diff, check for migration/config breaking changes, and confirm the supported Laravel versions. Wrap usage behind a thin internal interface (ErrorRecorder) so swapping to Sentry/Flare later is a one-file change. Add a retention/pruning job from day one, and ask upstream for a real changelog as a condition of continued adoption.

Recommendation: Approve a scoped spike (one service, one sprint). Re-assess to "adopt" once release notes are legible and a 1.0 or explicit BC policy appears; re-assess to "reject" if the diff shows unannounced breaking changes or Laravel support is absent.