- What is bezhansalleh/filament-exceptions used for?
- It is a Filament plugin that captures Laravel exceptions into a database table owned by your application and gives you a searchable, filterable page inside the admin panel to review them. Each record includes the stack trace, request context, and user details, plus a resolve action and an unresolved-count badge in the navigation. The goal is to shorten the path from something broke to someone owns it, without digging through log files.
- How do I install and register bezhansalleh/filament-exceptions?
- Install the package with Composer, publish the config and migration, run the migration, then register the plugin on your target Filament panel. There is no external service, no credentials, and no Node build step, so realistic effort is about half a day for a single-panel app. After registering it, throw a test exception in staging and confirm it shows up in the list page with a stack trace before you rely on it.
- Does this plugin support Filament v4, and which Laravel versions work?
- The 4.x line of the plugin tracks Filament v4, so match the release you install to your panel major and check the release notes. Version coupling is the main structural cost: every Filament major upgrade becomes a coordinated two-package upgrade, which is a predictable calendar item rather than a surprise. Confirm the Laravel constraint in composer.json for the specific tag you pick.
- Is it a replacement for Sentry, Flare, or Bugsnag?
- No. It offers no alerting, no grouping intelligence beyond recurrence counts, no tracing, and no release-health correlation. It is a complement to an APM or error-tracking service, and positioning it as incident detection sets an expectation your team will discover at the worst possible moment. Treat it as a lightweight triage inbox inside the panel your team already opens daily.
- How do I stop the exceptions table from growing forever?
- Retention is yours to schedule; the package does not prune by default. Stack traces are fat rows and growth is linear with error count, and both the list page and the navigation badge count query degrade as the table grows, which quietly taxes the whole admin panel. Schedule a pruning command before launch instead of retrofitting it once the table is already large.
- Does it store sensitive data like tokens, cookies, or emails?
- By default it can capture stack traces, request bodies, headers, cookies, and Authorization values, which routinely carry tokens, emails, and internal paths. Keeping that in your primary database expands your compliance surface for GDPR and DSAR responses, backup scope, and database access control. Specify redaction and retention before launch, and get sign-off from whoever owns data handling rather than letting a tooling choice become a silent data-handling default.
- How do I control who can see exceptions in the Filament panel?
- Access is governed by a policy or gate you define, so you limit visibility to the roles that actually triage errors instead of every panel user. Realistically that means support, QA, ops, or the technical founder. Review the gate as part of your launch checklist alongside the data-handling review, since the detail view exposes request context and user information.
- What happens if the database write fails while an exception is being logged?
- Capture runs inside Laravel's exception handler, so a failing write risks masking the original exception or, worse, a recursive capture loop that turns a single failure into an outage. Validate this explicitly in a sandbox by dropping the table and confirming the package fails closed. A package that does not fail safely here is disqualified regardless of how good the UI is.
- Does capturing exceptions slow down production during an exception storm?
- Capture happens on the request path, so write amplification during a storm from a bad deploy can degrade a service that is already failing. It is fine at modest error volume, but you want a measured answer for your workload rather than an assumption. Load-test the capture path if you expect high error rates, and pair it with aggressive retention.
- Is bezhansalleh/filament-exceptions actively maintained, and how hard is it to remove?
- It is MIT licensed with roughly 200 stars, zero dependents, and a single maintainer with a healthy Dependabot and CI posture. Lock-in is low, since removing the plugin and dropping the table is a clean exit, so it is a cheap bet. Still, log the bus-factor-of-one and thin dependent base as accepted risk with a re-evaluation trigger instead of waving it through.