Nova Horizon Laravel Package

Product Decisions This Supports

• Build vs. buy for internal queue observability. If the product already runs Laravel Nova and Laravel Horizon on Redis, this is hours of integration glue versus a sprint or more of custom admin UI. The real PM decision is not "do we need queue visibility" but "do we spend design and engineering time here, or on customer-facing roadmap work?" This package makes the buy side cheap and reversible.
• Broadening the audience for operational health. Horizon is an engineer's dashboard; Nova is where support, ops, and CS actually live. Embedding queue health where those teams already work is a support-deflection decision: can a Tier 1 agent answer "is this export stuck, or just slow?" without paging an engineer or acquiring Redis/Horizon access?
• Async-first roadmap justification. If exports, imports, report generation, bulk actions, webhooks, or AI/LLM jobs are on the roadmap, queue visibility becomes a product requirement rather than an ops nicety. Background work is invisible by default; this tool gives those features a visible safety net at low incremental cost.
• Support tiering and escalation design. Decide what support may see and act on: queue depth, oldest job age, failed count, retry status. Engineers still need /horizon for worker/supervisor detail and full failed-job traces. If the package cannot express granular views, gate the whole tool to support supervisors rather than exposing job payloads and stack traces broadly.
• Incident-response workflow inside the admin. Choose whether failed jobs are triaged in the tool the team already has open, or whether triage requires a context switch to /horizon and a "only one person has credentials" dependency. This is a workflow decision as much as a tooling one.
• Release-gate checklist item. A cheap, repeatable post-deploy check: open the Nova tool, confirm queue depth returns to baseline within the normal window, confirm no new failures in the last 15 minutes. Its value is that someone who did not write the code can run it.
• Dependency and ownership decision. Treat this as vendored glue, not a strategic platform bet. Ten stars, zero dependents, a single maintainer, and a Nova 4 compatibility fix that arrived as a community patch in 0.6.1. If adopted, budget explicit ownership, version pinning, source review, and a likely fork.

When to Consider This Package

Adopt when all of these are true:

• You already run Laravel Nova and Laravel Horizon against Redis. If either half is missing, the package has no job to do — it is glue, not a product.
• You need non-engineers — support, ops, account managers — to see queue and job health without handing them Horizon's raw dashboard or Redis access.
• You are on Nova 4. Release 0.6.1 exists specifically as the Nova 4 compatibility fix. Nova 5 and future major versions are unverified and should be treated as unsupported until proven otherwise.
• You are comfortable treating it as vendored glue: pin Nova, Horizon, and this package together as a set; keep a fork branch; budget roughly half a day to read the source end-to-end and own the integration.
• You have answered the authorization question before rollout. Nova's canSee and Horizon's viewHorizon gate are independent systems. Make Nova visibility a strict subset of Horizon's gate, and test with a non-admin account — otherwise you have a silent privilege escalation, not a cosmetic bug.
• You keep /horizon reachable as the fallback and the deep-dive UI. This tool should be an entry point, never the only path to queue visibility.

Look elsewhere when:

• You are not on Nova. Use Horizon directly, or evaluate Laravel's first-party Pulse on Laravel 11+. If Pulse already covers queue throughput and failure visibility, the better decision is likely "build a small Nova view onto Pulse" rather than taking on this dependency.
• You need alerting, SLOs, retention, or historical reporting. This is a dashboard, not a monitoring product. Horizon metrics are a short rolling window and get trimmed; pair with Sentry, Bugsnag, Oh Dear, or your APM for detection and history.
• Your queues are not Redis. Horizon is Redis-only and this package inherits that constraint silently. Mixed-backend estates will get a misleading, over-trusted picture — label it clearly or skip those environments.
• You need vendor support or a security-review trail. Procurement will ask about bus factor. Small maintainer footprint and zero dependents are continuity signals to plan around, not quality judgments.
• The only consumers are engineers. Then the wrapper inserts a layer between engineers and the real tool for no audience gain. Bookmark /horizon.
• There is an unresolved authorization question. If the tool does not deliberately consult Horizon's viewHorizon gate, do not roll it out. That is a data-exposure finding.
• Audience scaling cost is unclear. Each viewer adds Horizon Redis polling plus a Nova asset bootstrap. A handful of operators is free; opening it to the entire CS org may not be.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost integration that puts background-job health — the queues behind exports, imports, reports, and integrations — inside the admin panel our support team already uses. The value is not new capability; it is deflecting support tickets and shortening incident triage by letting non-engineers answer "is this stuck?" without pulling an engineer off the roadmap. It requires Nova and Horizon on Redis, supports Nova 4, and should be treated as vendored glue with a named owner rather than a strategic platform dependency. Recommend a feature-flagged rollout to a limited support/ops audience, keeping /horizon as the fallback, and measuring success by support tickets deflected, time-to-triage on queue incidents, and whether the post-deploy "did the queue drain" check actually gets run. If the answer to those measures is weak, rollback is one line and no data migration.

For engineering: This is a thin bridge between two systems you already operate — no schema, no runtime coupling, no queue changes. Three prerequisites must hold before anyone touches Composer: Nova reachable at /nova, Horizon actually running on Redis (php artisan horizon:status returns running), and Nova 4 specifically. The work is not writing code; it is reading the package source to confirm whether it iframes /horizon or re-hosts assets, and where it consults Horizon's viewHorizon gate. Gate the tool on Horizon's gate so Nova visibility is a strict subset, register it in tools() rather than dashboards(), and keep /horizon bookmarked in the incident runbook. Pin Nova, Horizon, and this package as a set; re-validate on every Nova major and any Horizon minor that touches front-end assets. Do not force resolution with --ignore-platform-reqs, and do not use this for alerting — pair it with Sentry or Oh Dear. Expect to own a fork: the codebase is small enough that forking is hours, not days, and the maintainer has accepted narrow reactive patches before.

For support/ops leads: You get a read-only window into whether a customer's export, import, or report is queued, running, or failed — without Redis access and without an engineer in the loop for the first question. Success in phase one is narrow: queue depth, oldest job age, failed count, and a copy-pasteable response template ("your export is queued behind N jobs"). Anything requiring full job payloads or exception traces still escalates to engineering with a link to /horizon/failed/{uuid}.