adrolli/filament-job-manager
A Filament plugin for managing Laravel queues from your admin panel: monitor pending, running, and failed jobs, inspect payloads and exceptions, retry or delete failed jobs, and track batches with ease.
Architecture fit — The package is a thin Filament plugin over Laravel's native queue tables (jobs, failed_jobs, job_batches). It does not replace queue infrastructure, workers, or Horizon; it is a read/inspect UI with mutation actions (retry, delete). That makes it architecturally low-coupling: it sits inside the existing admin panel and depends only on Filament panel registration plus the standard Laravel queue schema. The trade-off is that it inherits every limitation of the underlying queue driver and the schema — anything Horizon-specific (Redis metrics, tags, supervisord visibility, throughput charts) is out of scope unless the package explicitly layers on it.
Integration feasibility — High for any project already on Laravel + Filament. Typical path is composer require, register the plugin in the PanelProvider, publish config, and optionally publish assets. No service container gymnastics or custom driver work is implied. The main feasibility gate is version alignment: the package tracks a Filament major version (the 5.x line strongly suggests Filament 5), so the real question is whether our Filament pin matches. Secondary gate is driver support — database and Redis-backed queues store failed jobs in failed_jobs, but SQS/Beanstalkd behavior around payload inspection and retry semantics can diverge.
Technical risk — Adoption signal is weak (71 stars) relative to the blast radius of an admin tool that can retry and delete production jobs. Specific risks: (1) single-maintainer abandonment — mitigated by MIT license and the fact that the value is mostly UI over data we already own; (2) authorization model — mutations must be gated by a policy/gate, not just panel access, otherwise any admin-panel user can mass-delete failed jobs; (3) payload rendering — large serialized payloads and stack traces can blow up page memory or leak secrets (env vars, tokens) to whoever can view the panel; (4) upgrade coupling — Filament majors move fast, and a lagging plugin can block panel upgrades; (5) query cost — failed-jobs tables in noisy systems can be millions of rows, so listing/filtering behavior matters.
Key questions
database queues?job_batches and do they work with Bus::batch on all drivers?failed_jobs?Stack fit — Best fit is a Laravel 11/12 application on Filament 3/4/5 with database or Redis queues and a small platform/DevOps team that currently shells into the server or uses Horizon to triage failures. It is a poor fit where Horizon already provides the operational surface and leadership wants one pane of glass, or where the panel is exposed to non-engineer admins without strict authorization.
Migration path — Treat it as additive, not a replacement. Phase 1: install in a staging panel, point at a staging queue, verify payload rendering, retry, delete, and batch views behave against real failed jobs. Phase 2: add the authorization gate and confirm non-privileged panel users cannot reach the resource. Phase 3: promote to production with retry/delete initially disabled or restricted to a named ops group, running alongside existing Horizon/tooling for a sprint before deciding whether to sunset the old workflow.
Compatibility — Confirm three axes before committing: Filament major version pin, Laravel version range, and queue driver. Batch support requires the job_batches table and Laravel's batch APIs; if we do not use batches, that feature is inert but harmless. If we run Horizon, verify the two UIs do not disagree on job state (they read the same tables for failures, so agreement is likely, but Redis-only job metadata may not surface).
Sequencing — Publish and review config first (navigation label, authorization callback, widget toggles, polling interval), then wire the gate, then enable mutations. Do config and authorization in the same PR so no window exists where the resource is reachable with default permissive settings. Follow with a runbook entry and a short internal demo before enabling for the wider on-call group.
Maintenance — Small dependency footprint, so day-to-day maintenance is low; the real cost is version-tracking Filament majors. Pin to an exact minor version, watch releases (5.0.12 is a UI/PHPStan fix, indicating active but small-scale maintenance), and keep a fork-and-patch contingency since MIT permits it. Budget a few hours per Filament upgrade cycle to validate.
Support — Community, MIT, no SLA. Ownership should sit with the platform/backend team, not DevOps alone, since authorization and payload exposure are application concerns. Expect to self-diagnose issues; the escape hatch is that the package is replaceable with ~a day of custom Filament resource work if it is abandoned.
Scaling — Behavior degrades with failed_jobs volume rather than with traffic. Ensure the table is indexed as Laravel ships it, prefer server-side filtering and pagination, and avoid default views that eager-load full payloads. Widgets that poll counts should use cached or aggregate queries if the table is large. Batch views scale with the number of active batches, which is usually modest.
Failure modes — (1) Mass delete or mass retry by an unauthorized or mistaken user — mitigate with gate plus a confirmation step and audit logging; (2) retry storms re-enqueuing a poison job repeatedly — mitigate with a policy of triage-then-retry, not bulk retry; (3) secret leakage via payload/exception rendering — mitigate with redaction config or restricted access; (4) Filament upgrade blocked by a lagging plugin — mitigate with a pinned fork; (5) silent abandonment — mitigate with a documented fallback to a hand-rolled resource; (6) driver mismatch producing misleading state for SQS/Redis-with-Horizon deployments.
Ramp-up — Very low for engineers fluent in Laravel and Filament: roughly half a day to install, configure, and validate in staging, plus a one-hour walkthrough for on-call. Non-Filament developers need the authorization model explained, not the code. The main onboarding artifact is a short runbook covering who may retry/delete, how to read a payload, and when to escalate to the queue owner.
How can I help you explore Laravel packages today?