Weave Code
Horizon Exporter Laravel Package
renoki-co/horizon-exporter
A Prometheus exporter for Laravel Horizon that exposes queue, job, and worker metrics from Horizon's Redis data via a metrics endpoint, making it easy to monitor Horizon in Grafana and alert on queue health.
Export Laravel Horizon metrics using this Prometheus exporter.
Frequently asked questions about Horizon Exporter
- How do I install renoki-co/horizon-exporter in a Laravel app?
- Install it with Composer, publish the package config, and register the metrics route (optionally with the package's route middleware) so Prometheus has a URL to scrape. There is no schema change and no data migration, because the exporter reads the queue and worker state Horizon already writes to Redis. After that, point a Prometheus scrape job at the endpoint and verify the metric output before building dashboards.
- Does horizon-exporter support Laravel 8?
- Version 2.0.0 requires Laravel 9 and dropped Laravel 8 support, while the 1.x line remains installable for applications still on Laravel 8. Because this is a Composer constraint issue, a Laravel 8 service simply cannot install 2.x. Migrate per application rather than trying to run both versions inside one dependency graph.
- Does this package replace Laravel Horizon?
- No. Horizon remains the source of truth for queue and worker state, Redis stays the backing store, and the exporter only adds a Prometheus-scrapeable HTTP surface on top. It is read-only instrumentation, not a queue driver and not a Horizon replacement. If you are not running Horizon, the package has nothing to export.
- How do I secure the Horizon exporter metrics endpoint?
- Treat it like any internal metrics route: apply middleware or bind it to an internal-only network path instead of public ingress. Unauthenticated queue metrics can leak operational details such as job names, queue volumes, and worker counts. Check the route middleware option when publishing the config, and confirm your public load balancer does not expose the route.
- What metrics does horizon-exporter expose to Prometheus?
- It exposes Horizon's queue, job, and worker telemetry, which is what you need for queue wait times, job throughput, failed-job rates, and worker saturation. The exact metric names and labels effectively become a public API once your dashboards and alerts depend on them, so pin them down before broad adoption. Verify the output against your Horizon version, since collection reads Horizon's Redis data.
- Can I use horizon-exporter with Grafana?
- Yes. The exporter only produces Prometheus-format output, and Grafana reads that data from Prometheus like any other metric. The real work is on your side: scrape configuration, label strategy, dashboards, and Alertmanager rules. Teams already standardised on Prometheus and Grafana get the most value with the least integration effort.
- Does the exporter add load to Redis or slow down queue workers?
- It is a read-only exposition layer that sits beside Horizon rather than in the job dispatch or worker path, so it does not change how jobs are processed. The cost is Redis reads at scrape time, which scales with queue count multiplied by scrape interval. At large Horizon fleets, measure that load before shortening scrape intervals.
- What are the production risks of using horizon-exporter?
- It is a small, single-maintainer package, and that is the main risk: Horizon's internal APIs and Redis key layout are not a stability contract, so a Horizon major release can silently break metric collection. Adopting the exported metric names also makes them an API for your dashboards and alerts. Keep a fork-and-patch contingency and read Horizon upgrade notes before bumping it.
- How do I upgrade horizon-exporter from 1.x to 2.x?
- 2.0.0 is a constraint bump rather than a rewrite: update the Composer constraint, re-publish or merge the config in case route or middleware defaults changed, and re-run a metrics endpoint smoke test. Upgrade each application's Laravel version first, then bump the exporter, so no service straddles both. Audit any shared package or starter template pinned to ^1.0, because it will block Laravel 9 upgrades.
- What are alternatives to horizon-exporter for monitoring Laravel queues?
- Alternatives include Horizon's own dashboard for human inspection, Laravel queue events feeding your own Prometheus client, or broader APM tooling that reports queue behaviour alongside traces. The exporter's advantage is turning existing Horizon Redis telemetry into Prometheus metrics without adding a runtime dependency to the request or worker path. If you already run Prometheus and Grafana, it is one of the cheaper observability integrations available.
Weaver
How can I help you explore Laravel packages today?