Product Decisions This Supports
- Where queue observability lives in the admin surface. The core decision is whether queue health belongs inside Nova — the surface support, ops, and non-engineering staff already use — or in a separate ops dashboard. If the people asking "is this customer's job stuck?" already have Nova access and never touch Horizon or a terminal, this package turns operational visibility into a small, reversible feature rather than a roadmap project with its own budget line.
- Build vs. buy vs. pilot for internal tooling. This is a thin Nova card over Horizon's already-computed metrics; a realistic in-house build is roughly 1–2 days. Adoption is the "buy" path, but frame it as a timeboxed pilot: if the card covers ~80% of the need, keep it and fork for patches; otherwise rebuild a custom Nova card with your own policies, query cost, and upgrade safety. The real decision is "convenience layer vs. policy control," not a capability trade — the capability already exists in Horizon.
- Validating concrete use cases. On-call triage without VPN/SSH; support leads checking whether a specific customer's job is backed up or failing; eng or product leads watching backlog during launches, migrations, or traffic spikes; read-only queue visibility for people who must not hold server credentials. If none of these are real for your team, the value is marginal and the honest answer is to skip it.
- Prioritization evidence for an "ops dashboard" initiative. Usage signal — daily, weekly, or never — is cheap to gather behind a staging spike and either justifies or kills a larger observability investment before you commit engineering time. This package is a low-cost probe for a decision you'd otherwise make on intuition.
- Risk and ownership posture. MIT license, zero license cost, but 77 stars and 0 dependents means vendor risk is effectively "we maintain it." That's a resourcing decision — a named owner plus review time at every Nova and Horizon major — not a procurement one.
When to Consider This Package
Adopt when:
- You run Laravel + Nova + Horizon on Redis, and versions actually line up. Verify the Nova 4/5 and Horizon 4/5 compatibility matrix, last commit date, and open-issue responsiveness before committing. At this scale of package, maintenance signals matter far more than stars.
- The audience is people with Nova access but not Horizon or server access — that is where the ergonomic win is real. If only two or three engineers use Nova and they already live in
/horizon, the value is marginal and the maintenance cost is not justified.
- The need is read-only, point-in-time metrics (throughput, wait time, backlog, failed jobs). Horizon samples on roughly a one-minute interval, so treat this as a snapshot, never as a real-time or historical source of truth.
- You can absorb maintenance: pin exact versions, plan to fork on the first compatibility break, and add a documented re-validation step to the Nova/Horizon upgrade runbook.
Look elsewhere or build in-house when:
- You are not on Horizon (database/SQS queues) or not on Nova — zero value, no integration path. Stop before touching Composer.
- You need alerting, SLOs, incident routing, or long-term retention. Horizon's native notifications plus Sentry, Pulse, or Datadog/Grafana is the correct answer; this card would be a duplicate, less authoritative source of truth.
- You need fine-grained authorization or audit over who sees queue data and job payloads. Failed-job and exception views routinely contain request bodies, IDs, and sometimes tokens. A custom Nova card gives you policy control this package does not cleanly offer, and policy control is not something you can retrofit onto a card you don't own.
- Security policy restricts lightly maintained third-party code in admin paths — Nova cards run inside the admin panel, so read the source before shipping.
- A platform team already owns observability, or you are mid-migration to Laravel Pulse. Do not fragment ownership for a convenience card.
Diligence checklist before adoption: confirm the compatibility matrix against your pinned Nova/Horizon; confirm it consumes Horizon's public contracts (Laravel\Horizon\Contracts\*) rather than reaching into raw Redis keys; inspect the queries it runs so it does not add load on the queue backend; confirm it respects a Nova gate or policy beyond viewNova; verify it renders correctly against real multi-supervisor, multi-connection, environments configs; and check that it degrades gracefully — an isolated card error, not a 500 that takes down the wider dashboard — when Horizon or Redis is unavailable.
How to Pitch It (Stakeholders)
Executives: "A small, free (MIT) add-on that surfaces queue health inside the admin panel our support and ops teams already use. It closes a real blind spot — 'is this customer's job stuck?' — without a new dashboard project or a license cost, and rollback is trivial: remove the tool registration and the dependency. The risk is low but real: it is a small community package with minimal adoption and zero dependents, so we would pilot it in staging, pin the version, keep Horizon's native dashboard as the authoritative fallback, and assume we maintain it ourselves. Budget expectation is a one-to-two-day spike plus roughly half a day per Nova or Horizon major upgrade, with a named internal owner."
Engineering: "It is a thin Nova tool/card over Horizon's repositories — no new infrastructure, no schema changes, no job-payload changes, one Composer dependency, and a clean rollback. The value is convenience, not capability; Horizon already holds the data and remains the authoritative surface for doing anything about a failure. Two things we must get right: gate the tool to an ops/support role so failed-job payloads and traces don't leak to every Nova user, and treat version coupling as the dominant risk — no Nova or Horizon major upgrade ships without re-validating the card's numbers against /horizon on a real environment, because silently wrong metrics are worse than no metrics. Keep alerting wired to Horizon's native notifications; this card is a glance, not a pager."