Skyline for Laravel vs Laravel Queue Monitor

Laravel Queue Monitor, by Roman Zipp, has been around since 2018 and is one of the most installed queue packages for Laravel. It and Skyline for Laravel are often weighed against each other because both promise a better view of your jobs than the framework gives you. They get there from opposite directions. Laravel Queue Monitor writes the jobs you opt in to a table in your database, on any queue driver. Skyline replaces laravel/horizon on Redis and works on the live queue.

This page describes Laravel Queue Monitor as of version 5.5.0, released in October 2026.

What each one records#

Laravel Queue Monitor records a job only if its class uses the IsMonitored trait. Each run of that job becomes a row in a queue_monitor table: its status, queue, attempt number, start and finish times, the full exception trace if it failed, a progress percentage the job can report, and any data you attach. The rows stay until you delete them, so a month later you can still ask when an import last finished and how long it took.

Skyline records every job on your Redis queues without touching a job class, because it is the Horizon install those queues already run under. That history lives in Redis for Horizon's trim windows, which are measured in hours, so it is gone long before a month has passed. What Skyline adds is the live side: alerts when the queue stops working, and controls to act on it while it is still broken.

At a glance#

A log of job activity#

Its maintainer describes the dashboard as "more a backlog of job activity rather than a dashboard", and that is the right way to read it. Each attempt is its own row, so a job that failed twice and then succeeded shows up three times. A job whose worker was killed mid-run stays marked as running until the queue-monitor:stale command marks it stale. Nothing is pruned on its own: you schedule queue-monitor:purge with the retention you want, or tell a job class to delete its row when it succeeds.

The page at /jobs is off by default, and its route ships without the web middleware group or any authentication. Add both to ui.route.middleware before you enable it in production.

Where Laravel Queue Monitor is the better answer#

• You are not on Redis. It records jobs from the database driver or SQS, or from anything else that fires Laravel's queue events. Skyline, like Horizon, is Redis only.
• You need history that outlives Redis. Rows sit in your own database for as long as you keep them, and Eloquent scopes such as failed() and today() make them easy to query.
• You want a progress bar on long jobs. A job can report 0 to 100 percent as it runs and attach its own data, which you can then filter the list by. Skyline has no equivalent.
• Budget is the constraint. It is free, MIT-licensed, one table and one page.

Where Skyline is the better answer#

• You need to hear about it. Laravel Queue Monitor has no notifications. Skyline checks the live fleet every minute for Horizon being down, a stalled queue, failure spikes and crash-looping workers, and sends a recovery message when each one clears.
• 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, works on Redis state that a table of past runs cannot reach.
• You do not want to edit every job class. A job without the trait is invisible to Laravel Queue Monitor. Skyline sees every job on the queues it runs.
• The job never ran at all. A dispatch skipped by a held ShouldBeUnique lock leaves no row in any table, and neither does a scheduled task that was due and never started. Skyline's Locks & Limits and Schedule screens exist for exactly those.
• You want queue length and worker status. Laravel Queue Monitor shows the jobs it recorded, not how many are waiting or who is working on them. That is Horizon's dashboard, which Skyline keeps.

Can you run both?#

Yes, and that is a reasonable setup for a team that wants long-term history on a few important job classes. Laravel Queue Monitor listens for Horizon's JobPushed event when Horizon is installed, and Skyline keeps the Laravel\Horizon namespace and fires the same events, so it should behave the same way it does beside upstream Horizon. The two use separate storage and separate pages, /jobs and /horizon.

Choosing between them#

If the question you keep asking is "what happened to that job last week?", or you are not on Redis, Laravel Queue Monitor answers it for free. If it is "why did nobody notice the queue had stopped?", that is Skyline.