Filament Queue Monitor Laravel Package

Product Decisions This Supports

• Build vs. buy for failed-job operations. This package supplies the read/retry/delete layer over Laravel's failed_jobs table plus a list_limit-bounded list view. A PM can treat that as "solved" and redirect engineering effort toward product differentiation rather than an internal admin screen.
• Support matrix and version strategy. v0.1.1 explicitly covers Laravel 10, 11, and 12, including the database-uuids failer path. That gives a defensible answer to "which Laravel versions can we promise at GA?" and lets you sequence framework upgrades without freezing customer-facing work.
• Reliability and support-cost forecasting. Failed-job visibility is an on-call and support-ticket lever: retry/delete in-product reduces "please requeue my job" escalations. Use it to argue for or against investing in first-party queue dashboards (Horizon, Telescope) versus this narrower tool.
• Pre-1.0 risk budgeting. At v0.1.x the API and UI surface are still unsettled. Roadmap planning should assume churn, pin the version, and avoid making it a hard dependency of a customer-facing contract.
• Scope decisions on observability. The package is a maintenance/ops surface, not a metrics or alerting product. It informs where you draw the line between "operator tooling we adopt" and "observability we build or buy elsewhere."

When to Consider This Package

• You run Laravel 10–12 with the database queue driver (or any setup using the failed_jobs table) and want retry/delete without standing up Horizon or Telescope.
• Your team needs an operator-facing failed-jobs screen faster than an internal build, and the failure volume fits behind a list_limit cap.
• Adopt when the UUID-based failer (database-uuids) is in play — v0.1.1 fixes the Laravel 12 mismatch where the list keyed by numeric id while the failer looked up by uuid, which broke view/retry/delete with 404s. If your app is already on that failer, earlier versions were effectively unusable on Laravel 12 and this release is the first viable one.
• The fix also applies list_limit in SQL on Laravel 10/11 instead of loading the whole table, so adoption is reasonable for large failed_jobs tables — but still verify limits at your peak backlog rather than assuming.
• Look elsewhere if you need scheduled-job monitoring, alerting, throughput metrics, or multi-queue supervisors (Horizon/Telescope territory); if you are pre-Laravel 10 or on a non-database queue without a failed_jobs table; or if you require a stable, versioned public API — pre-1.0 semver gives no compatibility guarantee.
• Treat as not yet production-critical until the 0.x line stabilizes: pin an exact version, gate behind an internal/admin route, and keep a manual SQL fallback for requeueing.

How to Pitch It (Stakeholders)

Executives: A small, low-cost operator tool that puts failed background jobs back under human control — retry or clear them from a list instead of filing an engineering ticket. The v0.1.1 release fixes two real defects: on Laravel 12 the list and the underlying lookup disagreed on identifiers, so the screen 404'd and the buttons did nothing; on Laravel 10/11 it loaded the entire failed-jobs table instead of respecting the configured cap. Both are correctness and scalability fixes, not new scope. It is pre-1.0 and pinned; we adopt it to avoid building an internal admin screen, and we do not extend it into monitoring or alerting.

Engineering: Failed-jobs list view over failed_jobs with view/retry/delete. v0.1.1 corrects key alignment with the database-uuids failer on Laravel 12 (numeric id vs. uuid caused 404s and no-op actions) and pushes list_limit into SQL on Laravel 10/11 rather than hydrating the full table. No breaking changes or deprecations in this release. Known constraints: pre-1.0, no stable API contract, no metrics/alerting, and still requires you to validate behavior against your own failer configuration and backlog size before rollout.