Filament Exceptions Laravel Package

Product Decisions This Supports

• Build vs. buy for error visibility. The central decision this package forces: is "see what broke and who owns it" a table-stakes capability we assemble from free OSS inside the admin we already run, or a recurring SaaS line item (Sentry, Bugsnag, Rollbar, Flare)? At 200 stars, MIT, and zero dependents, this is a low-stakes bet that lets us defer the spend — not an argument to cancel the category. The decision should be logged with an explicit trigger for revisiting it.
• Whether an ops/support triage epic earns roadmap space. The package hands us a ready-made shape for that epic: exception list, filters for unresolved, a detail view with stack trace, request context, and highlighted source, a resolve action, and a navigation badge that answers "does anyone need to look at this right now?" If that shape matches what support is already doing in spreadsheets and Slack threads, the epic is far cheaper than it looks.
• Who is allowed to triage. Because the viewer lives inside the panel, support leads, QA, and technical PMs can see and resolve errors without a developer opening a monitoring tool. That is a staffing and escalation-path decision, not just a tooling one — and it requires a permission gate to be safe.
• Data-residency and vendor-review avoidance. Shipping stack traces and request payloads to a third party triggers a DPA, a security questionnaire, and possibly procurement. Keeping exception rows in our own database sidesteps that — at the cost of owning retention, redaction, and access control ourselves.
• MVP and pre-scale sequencing. For low error volume and a small team, adopting this defers a paid APM commitment until alerting, grouping, and trend analysis actually matter. It buys time; it should be treated as a time-boxed decision, not a permanent architecture.
• Client-facing admin differentiation. If we ship Filament panels to customers or as an agency handover, a built-in error inbox is a small, cheap credibility feature — it reads as operational maturity even though the engineering cost is roughly half a day.
• Release cadence as a vendor-risk signal. 4.2.1 is a pure maintenance patch: Dependabot bumps to CI actions, a docs badge-link fix, and one behavioral fix delegating getNavigationBadgeColor() to the plugin. No features, no migrations, no deprecations. The maintainer is keeping the lights on — a mild positive for "safe to depend on," and nothing that should consume sprint capacity.

When to Consider This Package

Consider it when all of the following hold:

• The stack matches. Laravel application with a back-office already on Filament v4. It's a panel plugin, not a standalone service — outside Filament it delivers nothing, and the 4.x line is functionally pinned to Filament's major version.
• The audience is already in the panel. Support, QA, ops, or a technical founder who lives in the admin UI. If triage happens in Slack or a ticketing tool, this adds a destination nobody visits.
• Volume is modest and workflow matters more than analytics. You want "mark resolved, filter unresolved, show a count" — not grouping intelligence, release health, regressions, or tracing.
• There's a reason to keep traces in-house — DPA friction, security review cost, data-residency rules, or simply not wanting another vendor.
• The panel is properly access-controlled. Exception records routinely contain PII, request bodies, headers, tokens, and internal file paths. Treat read access as a privileged permission enforced on both list and detail pages, and budget for retention/pruning before launch rather than after the table grows.
• You can absorb a coupled upgrade. Every Filament major becomes a two-package upgrade — a recurring, predictable cost to plan for, not a surprise.

Look elsewhere — or pair it with a real tracker — when:

• You need alerting, tracing, release/regression tracking, or trend dashboards. This is a viewer, not an APM. It will not page anyone at 2 a.m., and positioning it as incident detection is the single most common way this adoption goes wrong.
• Error volume is high enough that an unpruned table becomes a database problem. Stack traces are fat rows, growth is linear with error count, and the list page plus the navigation badge (a count query on every panel render) degrade with it.
• You run multiple services, queues, workers, or non-PHP components whose failures never reach this Laravel app.
• You're under SOC 2, HIPAA, or PCI expectations around retention guarantees, access audit trails, and vendor-backed support on error data.
• The panel isn't Filament, or the team has no appetite for plugin upgrades riding alongside framework upgrades.
• You need multi-tenant scoping — exceptions aren't tenant-tagged out of the box, so admins could see cross-tenant errors unless you build that boundary yourself.

How to Pitch It (Stakeholders)

To executives: This is a free, self-hosted, MIT-licensed plugin that puts an error inbox inside the admin tool our team already uses. It shortens the gap between a customer hitting a bug and someone owning the fix, and it avoids a new SaaS contract, security review, and DPA. The cost is engineering setup time plus a retention policy and a permission gate; the honest trade-off is that it does not alert anyone — it complements real monitoring, it doesn't replace it. It also carries essentially no lock-in: it writes to an app-owned table, so removal is "drop plugin, drop table." The latest release, 4.2.1, is routine maintenance — dependency bumps, a docs link fix, and one small correctness fix for navigation badge color. No breaking changes, nothing to migrate, no action required. The decision in front of us is whether in-panel triage is worth half a day of engineering now, or a monitoring subscription later.

To engineering: A Filament v4 plugin that persists exceptions to a database table and renders them as a panel resource — list, filter, resolve, badge count — with configurable retention and badge behavior. Adoption is Composer install, plugin registration, publish and run one additive migration, and a policy gate. Roughly half a day for a single-panel app. The 4.2.1 change only matters if you override getNavigationBadgeColor(): badge color resolution now delegates to the plugin, so verify any local override still wins. Before rollout, three things need an owner: retention/pruning of the exceptions table (a scheduled job we own and monitor), redaction of request bodies, headers, and auth/cookie data before persistence, and a permission gate on both list and view. Two risks to validate explicitly in a sandbox — that a failed write during capture fails open rather than masking or recursing on the original exception, and that capture latency stays bounded during an exception storm from a bad deploy. Position it as an internal triage convenience layer, with a documented trigger for revisiting paid APM: sustained error volume, the first revenue-impacting incident, or the point where alerting and trend analysis start getting asked for.