Horizon Laravel Package

Product Decisions This Supports

• Feature scope for async work: Horizon makes queue behaviour visible (throughput, runtime, wait times, failures, retries, delayed jobs, batches), which turns "should we make this async?" from a guess into a measured decision. PMs can approve moving work to the queue only when the team can show p95 runtime and failure rate for comparable jobs.
• SLO and reliability targets: Supports defining and defending user-facing commitments (e.g. "invites delivered within 60s", "webhooks retried for 24h") because Horizon surfaces max runtime, max throughput, wait time and failure counts per queue — the raw inputs for an internal SLA.
• Roadmap prioritisation of platform work: Repeated incidents in the same queue, chronic pending backlog, or retry storms become concrete, evidenced backlog items ("split the notifications queue", "add dedicated supervisor pool") rather than vague "scale infra" epics.
• Build vs buy: Effectively a buy decision that costs nothing — MIT, first-party Laravel, no licence or seat fees. The real comparison is Horizon vs. building an internal queue dashboard (weeks of eng time, permanent ownership) or vs. paid APM/observability (Datadog, Sentry, New Relic) for the same signals. Horizon removes the in-house build option from the table almost entirely.
• Launch readiness / go-live gates: A reusable checklist item — supervisor config in source control, queue prioritisation defined, failed-job handling reviewed, dashboard access gated. Useful as a template for every future feature that adds background work.
• Capacity and cost decisions: Throughput and runtime telemetry support right-sizing worker counts and Redis capacity, which is where queue infrastructure spend actually accumulates.
• Support and escalation policy: Job tags and monitored-job filtering let PM/support reason about a specific customer's stuck job or failing integration without a database query, shortening escalation paths.
• Risk decisions about self-hosting: The dashboard is part of your app's attack surface; deciding who can access it (gate/authorisation, tunnelling in local env) is a product-security call, not just an infra one.

When to Consider This Package

Adopt when:

• The product runs Laravel on Redis-backed queues — Horizon is purpose-built for this and is first-party, so version compatibility (Laravel 10 through 13, PHP 8.5) is handled by the maintainers rather than by you.
• Background work is user-visible or revenue-relevant (emails, webhooks, payments, media processing, exports) and today's visibility is "logs and hope".
• You want worker topology under code review — the single config/horizon.php file means supervisor/queue configuration gets PR review, rollback and environment parity instead of hand-edited server state.
• Your team is small and ops-constrained: the value per engineering hour is high because there's no instrumentation work to write.
• You need to diagnose failures during incidents — job-level inspection, tags, retries and batch views materially cut mean time to resolution.
• Delivery cadence matters: the package ships frequent patch releases (Redis Cluster support, PHP/Laravel compatibility, race-condition and memory-usage fixes) and is maintained by the framework vendor, so upgrade risk is low.

Look elsewhere or supplement when:

• Queues are not Redis — database, SQS, Beanstalkd or RabbitMQ drivers fall outside Horizon's scope; you need driver-level tooling or a different observability product.
• You need long-horizon analytics, cross-service tracing, or alerting: Horizon's metrics are trimmed on a schedule and it is a dashboard, not an alerting system. Pair it with external alerting/APM for paging, retention and distributed traces.
• Multi-tenant or high-compliance environments where a self-hosted dashboard with job payloads visible needs strict access control, data-residency or audit guarantees beyond a simple gate.
• You have no Redis operational maturity — Horizon adds a dependency on Redis availability and correctly-sized supervisors; if the team can't operate Redis, adopting Horizon hides rather than solves the problem.
• You are not on Laravel (or are on a legacy version outside support) — the value is tightly coupled to the framework.
• The org already standardises on a single observability vendor with queue instrumentation; adding Horizon is then a local convenience, not a strategic tool — acceptable, but scope it as a dev-only aid.

Adoption caveats to plan for: treat the metrics retention window and trim settings as a design choice, not a default; decide dashboard exposure (auth gate, tunnel restrictions) before rollout; and note the "0 dependents" figure in package metadata is an artefact of counting, not a signal of low adoption — Horizon is a standard part of the Laravel production stack.

How to Pitch It (Stakeholders)

For executives (one paragraph): Horizon is a free, officially maintained dashboard and configuration layer for our Laravel background processing. It gives us visibility into whether customer-facing async work — emails, webhooks, payments, exports — is succeeding, how long it takes, and what's failing, and it moves worker configuration into code review. It carries no licence cost and is maintained by the Laravel core team rather than by us, so the decision is low-cost and low-lock-in: we adopt it, get production visibility within days, and keep a real APM tool only where we need paging and long-term analytics. The measurable return is fewer silent failures, faster incident diagnosis, and better-sized infrastructure spend.

For engineering (summary): First-party, MIT, actively maintained (frequent patch releases, Laravel 13 and PHP 8.5 compatible, Redis Cluster support). Single config/horizon.php for supervisors, queues, balancing and trimming — versioned, reviewable, environment-parity by default. Provides job-level inspection, tags, batches, retries, metrics and a horizon:listen/horizon:clear-metrics command surface. Operational requirements: Redis, a process manager, dashboard access gated, and an explicit decision on metric retention. Explicitly not a replacement for alerting or tracing — budget a thin external alerting path alongside it. Known upstream churn in RedisQueue::later() and phpredis metric-clearing has been fixed in recent patches, so pin to a current release and keep dependency updates flowing.