Filament Failed Jobs Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Filament panel plugin that surfaces rows from Laravel's failed_jobs table as an admin UI. It does not introduce new infrastructure, queue drivers, or persistence — it reads what the framework already writes. That makes it architecturally low-risk: it slots into the existing Filament admin panel alongside other resources, and its blast radius is limited to the panel's authorization surface. It is a convenience layer over php artisan queue:failed, not a queue management system.

Integration feasibility. Integration is the standard Filament plugin pattern: composer require amvisor/filament-failed-jobs, then register the plugin in the relevant PanelProvider (->plugin(...)). No migrations are expected beyond the framework's own failed_jobs table (php artisan queue:failed-table / queue:failed migration). Feasibility is high if the Filament major version matches; that is the single gating check.

Technical risk.

• Version drift (high). Filament's plugin API changed materially between v2, v3, and v4. With a 0-star, 0-dependent package, assume the maintainer has not tracked the latest Filament release. Composer resolution against a current Filament install is the first thing to test.
• Abandonment (high). Single-maintainer, no dependents, no visible release cadence. Treat as vendored/throwaway code, not a long-term dependency.
• Data exposure (medium). Failed job payloads contain serialized job properties — which frequently include customer identifiers, email addresses, API tokens, or full model snapshots. Exposing this view to every panel user is a data-governance issue; access must be gated by policy, not just by "is logged into the admin panel."
• Connection coverage (medium). failed_jobs is keyed by queue connection. Apps using multiple connections (e.g., redis for default, sqs for integrations) will see only one connection's failures unless the package exposes a connection selector.
• Action completeness (low/medium). "Viewer" implies read-only. Retry, retry-all, and delete may be absent or may bypass Laravel's queue:retry semantics. Verify before promising ops a self-service tool.

Key questions.

1. Which Filament major versions are supported, and is there an active compatibility constraint in composer.json?
2. Does it read failed_jobs directly via Eloquent, or shell out to queue:failed? (Affects connection handling and testability.)
3. Are retry/delete/forget actions implemented, and do they respect the queue.failed config and per-connection UUIDs?
4. How is authorization enforced — Filament policy, gate, or nothing?
5. Is payload display truncated/sanitized, or is the raw payload column rendered?
6. What is the license, and is the code small enough (~a few hundred lines) to fork and own?

Integration Approach

Stack fit. Assumes Laravel 9/10/11 + Filament v3 (verify) + a queue whose failures are recorded to the database (database, redis, sqs, beanstalkd all support this when failed_jobs is configured). Apps on Horizon already have a failed-job UI for Redis queues — this package only adds value where Horizon is absent, or where non-Redis connections are in play.

Migration path. Effectively none: no schema changes beyond failed_jobs, no data backfill, no queue restart required. Rollback is composer remove plus deleting the plugin registration line. This is the package's strongest TPM argument — it is a reversible, hours-scale experiment.

Compatibility. Pin the package version explicitly and add a Composer constraint on the Filament major. Test against the exact Laravel/Filament/PHP matrix in CI before merging. If composer resolution fails on the current Filament version, do not force it with --ignore-platform-reqs; fork instead.

Sequencing.

1. Spike in a branch: install, register plugin, confirm the page renders against a seeded failed_jobs table.
2. Confirm authorization behavior and add a gate/policy if the package does not ship one.
3. Validate against a non-default queue connection if the app uses more than one.
4. Security review of rendered payload (redaction, truncation, copy-to-clipboard).
5. Ship behind a feature flag to a staging or internal-only panel first; promote to production admin after one on-call cycle.

Operational Impact

Maintenance. The realistic posture is "adopt-and-own." Budget for a fork or a vendored copy; expect to patch Filament compatibility yourself at each major upgrade. Do not add it to a critical path. If the team cannot accept owning ~a few hundred lines of Blade/Livewire, the correct alternative is a first-party Filament Resource over a FailedJob model — roughly a day of work, full control, same outcome.

Support. No vendor support, no SLA, no issue-triage expectation. Internal ownership must be assigned (typically the platform/backend team that owns the queue). Document the fork point and the upgrade procedure in the runbook.

Scaling. Negligible runtime cost — it is a paginated read against an indexed table, hit by a handful of admins. The real scaling concern is table growth: failed_jobs is unbounded by default. Pair this with a retention policy (queue:prune-failed --hours=168 on a schedule) regardless of whether the package is adopted. Large payload columns plus a full-table count can slow the listing page in the tens-of-thousands of rows; confirm the package paginates rather than loading all.

Failure modes.

• Filament major upgrade breaks the plugin at deploy time → pin versions; test upgrades in CI.
• Payload contains secrets and the page is visible to a broad admin group → gate access; redact.
• Multiple connections: failures invisible because the viewer assumes default → verify or extend.
• Retry action (if present) leaves the job failing repeatedly, filling the table → expose failure reason and attempt count; pair with alerting.
• failed_jobs table not created in a given environment → page errors instead of rendering empty; check migration state per environment.
• Silent abandonment: package stops receiving updates and a future Laravel release changes the failed-job schema → the fork is the mitigation.

Ramp-up. Very low for a Filament-fluent engineer (under an hour to evaluate). Low for on-call: it changes where failed jobs are inspected, not how they are remediated — queue:retry, queue:forget, and queue:flush remain the source of truth. Critically, this package is a viewer, not monitoring: it does not alert on failure, does not surface failure-rate trends, and does nothing for you until someone opens the page. Keep existing failed-job alerting (Sentry, Horizon wait-time/failure notifications, or a scheduled queue:failed check) in place and position this as an ergonomics improvement for humans, not a reliability control.