Laravel Queue Monitor Nova Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. The package answers a narrow question: do we build a custom admin screen for queue health, or drop in an existing Nova tool? At MIT license and near-zero install cost, it is a cheap "buy" candidate against weeks of internal dashboard work.
• Where queue observability lives. It forces a decision about whether queue/job status is an engineering-only concern (logs, Horizon, APM) or an operations-wide concern surfaced in the admin panel for support and ops staff who don't have SSH or server access.
• Support workflow design. Failed-job triage, backlog inspection, and job-duration review become self-service inside Nova rather than a ticket to engineering — a concrete reduction in escalation load.
• Platform standardization. Adoption implicitly commits the team to Laravel Nova and romanzipp/laravel-queue-monitor. That is a real roadmap constraint: it raises the switching cost if you later evaluate Filament or a hosted observability vendor, so treat it as part of the admin-stack decision, not a standalone utility.
• SLA / capacity inputs. Historical job runtimes and failure rates are useful for capacity planning and for setting realistic expectations on async work — but only if the underlying monitor is retained long enough to be meaningful.

When to Consider This Package

Adopt only when all of the following hold:

• You already run Laravel Nova on a compatible major version (this is a Nova tool; it is useless and uninstallable without a paid Nova license).
• You already run romanzipp/laravel-queue-monitor with a populated queue_monitor table — this package is a thin presentation layer over that data, not a monitoring engine.
• You have no existing queue dashboard (Horizon, Datadog, Sentry, Bugsnag, custom Grafana) covering the same ground.
• You need read-oriented visibility for non-engineers and are comfortable relying on Nova policies for access control.
• You can accept maintenance risk: 3 stars, 0 dependents, a single maintainer, and a dependency on two separate upstream release cadences. Budget for pinning versions and being prepared to fork.

Look elsewhere when:

• Laravel Horizon is in use. Horizon already provides job metrics, retries, tagging, and failure inspection — this package is largely redundant and adds a second source of truth.
• You need alerting, SLOs, or trend analysis. This is a viewer, not an alerting system. Pair with Sentry/Datadog or build notifications on top of the monitor package directly.
• You don't have a Nova license. The Nova subscription cost dwarfs any value here; a Filament or Blade admin page is a better trade.
• Job volume is high. The monitor writes a row per job lifecycle; at scale you need sampling, retention policy, and probably a dedicated store — evaluate the base monitor package's overhead before layering a UI on it.
• You need multi-tenant scoping, audit trails, or fine-grained RBAC beyond what Nova resources and policies give you out of the box.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed admin panel add-on that puts queue and background-job health in front of support and operations staff. It costs nothing to license and hours to trial; the only prerequisite is the Laravel Nova license we may already hold. The realistic upside is faster detection of failed background jobs — fewer customer-visible delays and fewer engineering interruptions for routine triage. Treat it as a tactical convenience, not a platform investment: the project is small and single-maintainer, so we should pilot it in a non-production environment first and avoid depending on it for anything customer-critical.

For engineering: Small Nova tool wrapping laravel-queue-monitor's existing tables — no new infrastructure, no schema changes beyond the base package. Install, register the tool, done. Caveats: it inherits the base package's write-per-job overhead and its retention behavior, and it inherits Nova's upgrade cadence. If we already pay for Horizon or Datadog, skip it — the marginal visibility isn't worth a second dashboard to keep in sync. If we don't, this is the cheapest way to get non-engineers out of our queue logs.