Filament Sentry Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side Sentry configuration: this package turns Sentry setup (DSN, environment, sample rates, breadcrumbs/tracing toggles) into a Filament panel surface instead of .env-only configuration, which removes a full deploy/DevOps ticket from the loop when support or on-call staff need to adjust capture behavior.
• Feature scoping for "observability in the admin panel": a low-effort, high-perceived-value differentiator. If you already run Filament, this is a same-day add for error visibility rather than a quarter-long APM project.
• Roadmap gating on Filament major version: v2.0.x is the Filament v4-era line (the "start of 2.x" work landed in v2.0.0). This release is a patch (2.0.1) with no new user-facing features and no breaking changes relative to v2.0.0 — treat v2 as the target line and v1 as legacy for Filament v3 panels. Decide your upgrade window based on Filament v4 adoption, not on this release.
• Permissions/roles architecture: the changelog's "update UserResource to use ShieldFacade" signals the plugin's bundled resource is now authorized through Filament Shield rather than ad-hoc policies. If your admin panel standardizes on Shield, that's one less custom policy to maintain; if you use a different ACL approach (e.g., plain Laravel policies, Spatie roles only, or a custom panel guard), plan to verify access control after install.
• Reducing MTTR: shipping a Sentry integration into the panel gives non-engineer stakeholders a credible answer to "how fast would we know if checkout broke?" without committing headcount.

When to Consider This Package

Adopt when all of these hold:

• You are on Filament v4 (this is the 2.x line) and are already committed to Sentry as your error-tracking vendor.
• You want Sentry configuration manageable from the panel by admins, not buried in environment variables — useful for multi-tenant or multi-environment setups, staging/production parity checks, and handing tuning to on-call.
• You are comfortable with a single-maintainer, small-surface plugin by a well-known Filament contributor. The code footprint is thin, so the audit cost is low and the exit cost (rip out the provider, keep .env) is near zero.
• You have, or plan to have, Filament Shield in place — the 2.0.1 change aligns the plugin's resource authorization with Shield, so mismatched ACL stacks mean extra verification work.

Look elsewhere or stay hands-off when:

• You are on Filament v3 — stay on the 1.x line; do not mix majors.
• You need Sentry configuration only, not panel UI. Plain sentry/sentry-laravel plus env vars is a smaller dependency and removes a plugin from your upgrade surface entirely.
• You require vendor SLAs, guaranteed release cadence, or formal security review of every dependency — this release's sparseness (3 PRs, one chore) is a signal of maintenance tempo, not a product roadmap you can plan against.
• Your Sentry governance is intentionally locked down to platform engineering. A panel-editable DSN is a configuration-as-permission decision; confirm you want that before adopting.
• You need richer observability features (dashboards, tracing UX, alert routing, log aggregation) — this is an integration/configuration seam, not an APM product.

Upgrade guidance for this release: v2.0.1 is a routine patch. No migrations, no deprecations, no breaking changes called out. Safe to take within the 2.x line at normal cadence; the only behavior change worth a QA pass is the Shield-based authorization on the bundled UserResource — smoke-test "who can see and edit the Sentry settings page" for each role.

How to Pitch It (Stakeholders)

For executives (one line): A small, low-risk plugin that puts error-monitoring configuration inside the admin panel we already run, so we can see and fix production failures faster without a deploy — a same-day implementation with effectively no lock-in.

For engineering leads:

• Scope is narrow and the blast radius is small: it wires Sentry into Filament and exposes a settings surface plus permission-aware access via Shield. There is nothing to architect around.
• v2.0.1 is a patch on the v2/Filament-v4 line. No breaking changes, no migration work. Budget a half-day for install, env/DSN verification, and a role-based access smoke test.
• The one real change to test is the ShieldFacade-based authorization on the resource — confirm your role matrix maps cleanly, or add a policy override.
• Exit plan is trivial: remove the plugin, keep .env configuration, retain sentry/sentry-laravel.
• Risk to flag honestly: single maintainer, thin release notes, and a panel-editable DSN widens who can change error-capture behavior. Mitigate by restricting the settings page to a named admin role and keeping production DSN values under platform-engineering control until the permission model is proven.

Recommendation: Adopt as a contained, reversible convenience layer for Filament v4 + Sentry shops; take v2.0.1 as a routine patch. Do not treat it as an observability strategy or plan roadmap commitments around its release cadence.