Laravel Horizon Prometheus Exporter Laravel Package

Product Decisions This Supports

• Queue reliability as a measurable product attribute. The package exposes Laravel Horizon's queue telemetry (jobs processed, queue wait time, throughput, failed jobs per queue) on a Prometheus-scrapeable endpoint. That turns "are background jobs healthy?" from a support-ticket-driven question into a dashboard and an alert.
• SLOs / SLIs for asynchronous work. Enables concrete targets like "p95 queue wait < 30s" or "failed-job rate < 0.5%" for exports, notifications, webhooks, and billing jobs — areas that are otherwise invisible until they back up.
• Capacity planning and cost trade-offs. Queue depth and wait-time trends give a defensible basis for right-sizing worker pools and justifying (or cutting) infrastructure spend, instead of guessing at Horizon's maxProcesses.
• Build vs buy. A narrow, single-purpose bridge. The alternative is building a custom metrics exporter in-house (maintenance burden) or buying a higher APM tier for queue-specific telemetry (recurring cost). This is a low-cost third option.
• Roadmap and process inputs. Useful for incident postmortems ("did the queue backlog cause the outage?"), on-call runbooks, canary/rollback gating, Horizon migration or queue-topology changes, and multi-tenant fairness decisions.
• Scope limit to be explicit about: it provides aggregate metrics, not per-job tracing or job lineage. Decisions about individual stuck jobs still need logs or a tracer.

When to Consider This Package

Adopt when:

• The product runs on Laravel with Horizon (Redis-backed queues) — Horizon is a hard prerequisite; without it there is nothing to export.
• Prometheus + Grafana (or a Prometheus-compatible scrape target) is already the observability standard, so this is additive rather than a new vendor.
• You need queue depth, wait time, and failure visibility wired into alerts, and you want it without touching application code.
• You value a small dependency surface and a maintained project over a bespoke exporter.

Look elsewhere when:

• You are not on Horizon — SQS, database, or Beanstalkd queues won't be covered; use native cloud metrics or a generic queue exporter.
• Your observability strategy is standardized on OpenTelemetry rather than pull-based Prometheus scraping; an OTel bridge (metrics + spans) fits better and avoids a second pipeline.
• A managed APM already instruments queue latency and failures — duplicating telemetry adds cost and creates two competing sources of truth for the same SLI.
• You need per-job tracing, job-level attribution, or span-level debugging; this package won't deliver that.

Note on this release (v1.8.3): This is a narrow Laravel 13.x compatibility release — no breaking changes, no configuration or API changes, no deprecations. For a PM the signal is maintenance health and forward compatibility: adopting now does not create a blocker for a Laravel 13 upgrade, and the maintainer is keeping pace with framework majors. One caveat worth flagging to engineering: the compatibility work arrived via a community contribution, so verify it against your exact Laravel/Horizon versions in staging before relying on it in production. It does not change the adoption calculus above, but it does lower the "will this be abandoned?" risk that would otherwise argue for waiting.

How to Pitch It (Stakeholders)

For executives (one paragraph): Background job failures are invisible to customers until they surface as missing emails, delayed payouts, or stale data. This is a small, low-risk open-source dependency that makes our queue health measurable using tooling we already run, so we can set reliability targets for background processing and catch degradation before it becomes an incident — without buying additional monitoring. The v1.8.3 release confirms it stays compatible with our planned Laravel upgrade, so it is not a blocker to the platform roadmap.

For engineering (the practical case): A single Composer dependency that exposes Horizon's existing metrics in Prometheus format; you add a scrape target and a Grafana dashboard, and write alerts against metrics you already collect internally. No application code changes, no new infrastructure. It gives you queue wait time, depth, throughput, and failure counts per queue — the signals you currently reconstruct from logs during an incident. Be clear on the boundary: it is aggregate metrics only, so keep your tracer for per-job debugging. Risk is low and reversible; validate the Laravel 13 path in staging since the compatibility patch came in from a community PR.

Ask: Timeboxed spike — one engineer, roughly a day — to stand up the exporter in staging, wire a dashboard, and define two or three candidate SLIs. Decision gate: if the metrics match what we can already see in Horizon, promote; if they duplicate an existing APM signal, drop it and avoid the second pipeline.