Nova Horizon Stats Laravel Package

Technical Evaluation

Architecture fit. The package is an observability add-on for Laravel Horizon: it registers dashboard cards inside the existing Horizon UI rather than introducing a parallel monitoring stack. v0.3 adds a Workload card that surfaces current Horizon workload and supports queue-level filtering. Architecturally this is a read-only, presentation-layer extension — it should not participate in job dispatch, queue configuration, or supervisor lifecycle. That keeps it well isolated from the critical path, which is the right shape for a monitoring package. The trade-off is that the value is entirely derived from Horizon's own metrics collection; if Horizon's autoScaling/metrics snapshots are not configured, the card can only render whatever partial data Horizon already holds.

Integration feasibility. Low-to-moderate. Requirements are effectively: Laravel with Horizon installed, Redis available (Horizon's metric store), and the package's service provider registered. The queue filter in this release implies either a config-driven allowlist or a UI selector — this matters for integration because a config-driven filter becomes deployment configuration, while a UI filter is user state and may need per-user persistence. The package is at v0.3 and pre-1.0; API surface and configuration keys should be treated as unstable, so integration should be pinned to an exact version rather than a floating constraint.

Technical risk. Rated low on blast radius, moderate on stability.

• Low: read-only card rendering; worst case is a broken dashboard view, not broken job processing.
• Moderate: 0.x versioning means breaking changes between minor versions are normal and expected; config key or card-registration signature changes will require code edits on upgrade.
• Moderate: undocumented interaction between the Workload card's queue filter and Horizon's tagged/measured queues. A filter that references a queue not present in Horizon's workload snapshot may render as empty rather than erroring, producing a silently misleading dashboard — a real operational hazard for anyone using the card to make scaling decisions.
• Low: no indication of any write path to Redis beyond reading metrics.

Key questions.

1. Does the Workload card reuse Horizon's existing workload API, or does it perform its own metric aggregation (extra Redis reads per dashboard poll)?
2. Is the queue filter persisted per user, per session, or via config? What is the default when unset?
3. What is the rendering behavior when Horizon metrics are stale, disabled, or Redis is unreachable — empty state, error card, or dashboard-wide exception?
4. Is there a documented upgrade policy or deprecation notice ahead of v1.0?
5. Does the card respect Horizon's existing authorization gate, or does it need its own access control?

Integration Approach

Stack fit. Natural fit for any Laravel application already running Horizon as its queue supervisor. Applications using the database or SQS driver without Horizon are out of scope entirely — this is a hard prerequisite, not a soft one. Teams running multiple Horizon supervisors or multi-tenant queue segmentation will get the most value from the new filtering capability, since a single unfiltered workload view is noisy at scale.

Migration path. No migration required — this is a new dashboard surface, not a change to existing behavior. Onboarding is: install, publish config (if applicable), register the provider, and confirm the card renders against the target environment's Horizon instance. Because the package is additive, a rollback is a composer removal with no data cleanup. The one caveat is that if the card is ever evaluated in a shared Horizon dashboard used by on-call staff, its removal is a visible change to a familiar view and should be communicated.

Compatibility. Verify Horizon major version support explicitly — Horizon's internal dashboard extension points have changed across Laravel majors, and a 0.x package may only target a narrow window. Also confirm PHP and Laravel version constraints, and whether the card assumes the Redis metrics feature is enabled. Test in the lowest and highest supported Horizon versions in the fleet rather than assuming homogeneity across environments.

Sequencing.

1. Install pinned version in a non-production environment with real Horizon traffic.
2. Validate the Workload card renders with metrics enabled and with metrics disabled, to establish the empty-state behavior.
3. Exercise the queue filter against actual queue names, including a queue with zero workload, to confirm no misleading empty render.
4. Confirm authorization parity with the existing Horizon dashboard.
5. Roll to production behind no feature flag (low risk) but with a named owner watching the first week for dashboard exceptions.

Operational Impact

Maintenance. Low ongoing effort, bounded by 0.x churn. Budget for a review on each minor release rather than treating it as set-and-forget; a pre-1.0 package with dashboard extension points is exactly the category that breaks quietly on a Laravel or Horizon major upgrade. Pin the version and let dependency updates be deliberate.

Support. No vendor support expectation at 0.x — treat it as community or internal ownership. Someone on the platform team should be the named owner, capable of reading the package source if a card misbehaves. Documentation in the repo should capture the queue filter semantics, since that is the newest and least understood configuration surface.

Scaling. The card reads Horizon's existing workload data; the marginal cost is dashboard polling, which scales with the number of people watching the dashboard, not with job throughput. Risk emerges only if the card performs its own aggregation over large key spaces on each poll — this needs to be confirmed, ideally by watching Redis command rate with the dashboard open across several supervisors and many queues.

Failure modes.

• Redis unreachable → card fails while Horizon itself degrades; confirm it fails gracefully rather than taking down the dashboard.
• Metrics disabled or stale → card renders empty or stale workload, which on-call staff may misread as "no load." This is the most consequential failure mode, because it feeds a scaling decision with incorrect information.
• Queue filter referencing a renamed or removed queue → silent empty state after a queue rename.
• Package/Horizon version mismatch → dashboard-wide exception if card registration throws during provider boot.
• Unfiltered default in a high-queue-count environment → card noise that pushes users back to Horizon's native view, negating the package's value.

Ramp-up. Minimal for engineers already fluent in Horizon — the card is a familiar visual idiom and the filter is self-explanatory. The real ramp-up cost is on-call interpretation: the team needs a short note on what "current workload" means in this card, its refresh cadence, and the fact that it reflects Horizon's snapshot rather than live queue depth. Recommend a brief runbook entry before on-call starts relying on it.