Skyline

Skyline for Laravel vs Cbox Queue Monitor

Cbox Queue Monitor keeps a database row for every job attempt, on any driver, with percentiles and replay. Skyline replaces Horizon on Redis, alerts when the queue stops and lets you act.

Updated · Boring Observability

[ the bottom line ]

Cbox Queue Monitor is the most complete free queue monitor for Laravel, and it is ahead of Skyline on record-keeping: a database row for every attempt, CPU and memory per run, percentiles per job class, replay of any stored job, and support for any queue driver. What it lacks is a way to tell you: its alert conditions show up when someone opens the dashboard, and it sends no notifications. Skyline replaces Horizon on Redis, sends an alert when Horizon stops or a queue stalls, and adds controls Cbox does not have, such as pausing one queue. Off Redis, or for history and percentiles, take Cbox. On Redis, when the problem is finding out late, take Skyline.

Cbox Queue Monitor
A free package that records every job attempt in a database table on any driver, with a companion metrics package, a web dashboard, a terminal UI and an API. Free, MIT
Skyline for Laravel
A commercial fork of Laravel Horizon that replaces the package and adds alerting and production queue operations. $139 one time · MIT-licensed source

Cbox's Laravel Queue Monitor is a free, MIT-licensed package that records every attempt of every job in a database table, on any queue driver, and pairs it with a companion package, Laravel Queue Metrics, for aggregate numbers. It is the most thorough free queue monitor for Laravel we know of, and on several points it is ahead of Skyline for Laravel. Skyline replaces laravel/horizon on Redis, alerts when the queue stops working and lets you act on it.

This page describes Queue Monitor 1.12.1 and Queue Metrics 3.5.2, the releases current in November 2026.

Two packages, one dashboard#

Queue Monitor listens to Laravel's queue events and writes one row per attempt to a queue_monitor_jobs table: the job, its queue and server, its outcome, its duration, the exception if it failed, and the CPU and memory it used. A retried job keeps its whole chain, so you can see each attempt and where it ran. The rows feed a web dashboard and a terminal UI.

Queue Metrics adds the numbers that are not about any one job: queue depth and the age of the oldest waiting job, worker heartbeats, throughput, health scores and a Prometheus endpoint. It stores them in Redis by default, or in the database for small setups, and it registers scheduled commands, so the scheduler has to be running.

At a glance#

Capability Cbox Queue Monitor Skyline
Relationship to laravel/horizon Runs beside it, or on any driver without it Replaces it
Queue drivers Database, Redis, SQS, Beanstalkd and custom drivers Redis
Job history A database row per attempt, 7 days by default Redis, for Horizon's trim windows
CPU and memory For each job run Per job class, and for the worker fleet
p50, p95 and p99 durations Per job class, queue and server No
Replay a job from its payload Any stored job, singly or in bulk Failed jobs, and Perform Now on delayed or retrying ones
Queue depth and oldest job age Yes, through Queue Metrics Yes
Worker status Heartbeats through Queue Metrics Yes, from Horizon's supervisors
Alert conditions Four, shown when you open the dashboard or call the API Seventeen, checked every minute
Notifications None built in; you write a listener Mail, Slack, SMS or a webhook, with recovery messages
Alert when Horizon itself stops No Yes, horizon:check runs outside the fleet
Prometheus endpoint Yes Yes, with a Grafana dashboard
Health checks and a readiness lint for CI Yes No
Pause a single queue No Yes
Scheduled task runs, including missed ones No Schedule screen
Held ShouldBeUnique locks and rate-limiter releases No Locks & Limits screen
Interfaces Web dashboard, terminal UI, REST API Horizon's dashboard and a read-only MCP server
Requirements PHP 8.3+, Laravel 11 to 13, a database, the scheduler PHP 8.0+, Laravel 9.21 to 13, Redis
Price Free, MIT $139 once, a year of upgrades

Where Cbox Queue Monitor is the better answer#

  • You are not on Redis. It works on the database driver and SQS as well as Redis, and Skyline, like Horizon, does not.
  • You want every attempt on record. One row per attempt, with its server, exception, CPU and memory, gives you a retry timeline Skyline does not keep, in a database you can query.
  • You track latency by percentile. p50, p95 and p99 per job class, queue and server, and a pickup-SLA percentage per queue, are things Skyline does not report.
  • You want to re-run a job that succeeded. Replay works on any job whose payload was stored, in bulk if needed. Skyline retries failed jobs and runs delayed ones early, nothing more.
  • Budget is the constraint. Both packages are free and MIT-licensed.

Things to know before you rely on its numbers#

Its success rate is counted per row, and each row is an attempt. A job that fails twice and then succeeds counts as two failures and one success, so a queue with healthy retries reads worse than its jobs did. The attempt column can also read "3/1" on a released job, because the maximum is taken from the job's $tries property alone and ignores the worker's --tries and retryUntil().

Several features are off outside the local environment by default, for good reasons: payload storage, which replay needs, and the REST API. Job arguments are redacted on the dashboard unless you take command out of the sensitive keys. Pruning is a command you schedule yourself.

Where Skyline is the better answer#

  • You need to be told. Cbox's alert conditions appear when someone opens the dashboard or calls the API. Skyline checks every minute and sends each alert over mail, Slack, SMS or a webhook, routed by severity, with a recovery message when it clears.
  • Horizon itself stops. Queue Metrics can show stale workers on its dashboard, but nobody hears about it until they look. Skyline's horizon:check runs from the scheduler, outside the fleet, and sends the alert.
  • You need to act on a live queue. Pausing one queue during an incident or running a retrying job the moment the fix is deployed are operations on Redis that only the Horizon install can perform.
  • The job never ran. A dispatch skipped by a held ShouldBeUnique lock leaves no row, and neither does a scheduled task that was due and never started. Skyline's Locks & Limits and Schedule screens show both.

Can you run both?#

Yes. Queue Monitor installs beside Horizon and reads extra data from it when it is present, such as supervisors and workload, and Skyline keeps the Laravel\Horizon namespace those reads go through. Cbox would keep the attempt history and percentiles, and Skyline the alerts and controls. Note that it takes a job's tags only from the job's own tags() method, not from the tags Horizon adds automatically.

Expected, not yet certified

We have run Cbox Queue Monitor beside stock Horizon, not beside Skyline. Try the pairing on staging first.

Choosing between them#

If you are off Redis, or what you want is a detailed record and percentiles, Cbox Queue Monitor is free and very good at it. If you are on Redis and the problem is finding out late, then needing to do something about it, that is Skyline.

Common questions

Does Cbox Queue Monitor send alerts?

Not on its own. As of version 1.12.1 it computes four alert conditions (stuck jobs, a high error rate over the last hour, a large backlog of queued rows and many slow jobs), and they appear when you open its dashboard or call its API. It has no notification channels; its docs show how to write your own listener. Skyline checks seventeen conditions every minute and sends each alert over mail, Slack, SMS or a webhook, with a recovery message when it clears.

What is the difference between Cbox Queue Monitor and Queue Metrics?

Queue Monitor keeps the per-job record: one database row per attempt with its outcome, duration, exception, server, CPU and memory, plus replay, a web dashboard, a terminal UI and a REST API. Queue Metrics, which Queue Monitor requires, keeps the aggregates: queue depth, oldest job age, worker heartbeats, throughput, health scores and a Prometheus endpoint, stored in Redis by default.

Does Cbox Queue Monitor work with Horizon?

Yes, beside it. It records jobs through Laravel's queue events on any driver and reads extra data from Horizon when it is installed, such as supervisors and workload. Tags come only from a job's own tags() method, not from the tags Horizon adds. Skyline keeps the Laravel\Horizon namespace, so the pairing is expected to work, though we have not certified it.

How does Cbox Queue Monitor count success rate?

Per row, and each row is one attempt. A job that fails twice and then succeeds counts as two failures and one success, so a queue whose retries work as intended reads worse than its jobs did. Keep that in mind when you compare its error rate with a per-job figure such as Horizon's failed jobs count.

How long does Cbox Queue Monitor keep job history?

Seven days and at most 500,000 rows by default, enforced by a queue-monitor:prune command you schedule yourself. Skyline keeps Horizon's Redis history for Horizon's trim windows, which are measured in hours.

What does Cbox Queue Monitor require?

PHP 8.3 or newer, Laravel 11 to 13, a database for its table, and a running scheduler for Queue Metrics' commands. Both packages are free and MIT-licensed. Skyline needs PHP 8.0 or newer, Laravel 9.21 to 13 and Redis, and costs $139 once.

Queue control, not just queue monitoring.

Skyline is a drop-in replacement for Laravel Horizon that lets you act on what you see — pause a queue, jump a job to the front, drain a backlog. $139 once, every app you run it on.

Buy Skyline — $139 once

Secure checkout by Anystack. 30 days to change your mind.