Filament Failed Jobs Laravel Package

Product Decisions This Supports

• Ops visibility without engineering time. Failed jobs are currently only inspectable via php artisan queue:failed or raw DB access. A Filament resource turns that into a support-facing screen, which is a real MTTR reduction if async work (emails, webhooks, exports, billing sync) is customer-visible.
• Build vs. buy for internal tooling. The honest baseline is "a developer writes a Filament resource over the failed_jobs table in 1–2 days." This package is a shortcut to that outcome, not a capability you can't otherwise get. The decision is dependency vs. 200 lines of owned code, and at 0 stars / 0 dependents the package is effectively unvetted, so weigh it as a reference implementation first.
• Reliability roadmap input. Surfacing failure counts and exception classes by job name tells you which integrations are flaky — that prioritizes work on retry/backoff policy, idempotency, and third-party contracts instead of guessing.
• Support-tier definition. Deciding whether support agents get a retry button, a read-only view, or nothing at all is a product/policy call about blast radius and permissions, not a technical one. This package forces that conversation early.
• Pre-release hygiene. A "check queue health" step before/after deploys is cheap insurance for teams shipping async-heavy features weekly.

When to Consider This Package

Adopt-or-evaluate when all of these hold:

• You already run Filament in production and your ops/support staff live in that panel.
• You use the database queue driver (no Redis), so Horizon isn't an option — or you're on Redis but don't want Horizon's footprint for a small team.
• Failed-job volume is low to moderate; you need eyeballs and a retry button, not SLOs, alerting, or trend analytics.
• You can accept a low-trust dependency: read the source (it's small), confirm Filament v3/v4 compatibility, license, PII redaction of payloads, an authorization gate on the resource, and whether retry/delete actions exist. Pin the version and be prepared to fork.

Look elsewhere — or build in-house — when:

• You need alerting and trend data, not a table view. Use Sentry/Bugsnag or Horizon's metrics; this package won't page anyone.
• You have PII or secrets in job payloads. A naive viewer that renders serialized payloads is a compliance problem, and you need this reviewed before it's exposed to non-engineers.
• Job volume is high, you need bulk retry with backoff control, multi-tenant scoping, or audit trails of who retried what.
• The repo shows no recent commits, no tests, no license clarity. With zero dependents, you are the first user — treat that as the cost of adoption, not a footnote.

How to Pitch It (Stakeholders)

To executives: This is a small, free admin-panel add-on that lets support see and retry failed background jobs without escalating to engineering. Expected value is lower MTTR on customer-visible async failures and fewer "please re-run that export" tickets. Expected cost is one spike, not a procurement cycle. It is not a monitoring or alerting product — we still need error tracking for that.

To engineering: Evaluate as a 1-day timeboxed spike, not a commitment. Read the source, confirm Filament version support, verify payload redaction and an authorization gate, and decide between (a) adopting with a pinned version and a fork plan, (b) copying the approach into our own resource, or (c) skipping in favor of Horizon/error tracking if we're already covered. Default recommendation given the package's maturity signals: use it as a design reference, ship our own 200-line resource, and revisit if the package gains maintainers.