Skyline for Laravel vs Laravel Horizon
Skyline is a fork of Horizon. Everything Horizon does still happens; the difference is what you can do about it.
Updated · Boring Observability
[ the bottom line ]
Keep Horizon if watching your queues is all you need — it is free, official, and Skyline changes none of it. Choose Skyline when you keep needing to act on what the dashboard shows: pause one queue during an incident, run a retrying job now, drain a backlog, weight a queue without starving the rest. Or when what you need is not on the dashboard at all — a ShouldBeUnique lock silently swallowing every dispatch, a job that failed before it ran, or which job class is eating the memory your workers keep restarting over.
- Laravel Horizon
- The official Laravel queue dashboard, and the project Skyline is forked from. Free, MIT
- Skyline for Laravel
- A commercial fork of Laravel Horizon that replaces the package and adds production queue operations. $99 one time · MIT-licensed source
Skyline for Laravel is a commercial fork of Laravel Horizon that keeps every part of Horizon intact and adds an operations layer on top of it. Horizon shows you what your Redis queues are doing; Skyline shows you the same thing, plus the things Laravel does quietly — a dispatch dropped over a held unique lock, a job failed before it ever ran — and gives you the buttons to act on both: pause a queue, release a stuck lock, run a delayed job now, drain a backlog, jump a job to the front. Everything below is additive: Skyline removes or changes no Horizon feature.
At a glance#
| Capability | Horizon | Skyline |
|---|---|---|
Drop-in for laravel/horizon (same config, same namespaces) |
It is Horizon | Yes |
| Throughput, runtime & failure metrics | Yes | Yes |
| Supervisors, balancing strategies, autoscaling, tags, notifications | Yes | Yes, unchanged |
| Trigger a delayed or retrying job immediately | No | Perform Now |
| Drill into the jobs waiting inside a queue | No | Per-queue drill-down |
| Delete a job, or empty a queue, from the UI | No | Yes, with guards |
| Pause & resume a single queue | No, all-or-nothing | Per queue |
| Proportional queue priority without starvation | No, strict priority only | Weighted queues |
| Ad-hoc front-of-queue dispatch | No | onFront() |
| Search jobs by class name or argument value | No | One box over every listing, e.g. checkout_id: 3 |
| Scheduled and retrying jobs told apart | No, one delayed list | Separate tabs, split on attempt count |
| Structured job lifecycle logging | No | Every transition, incl. silent drops |
See which ShouldBeUnique locks are held, and release a stuck one |
No, find the key with redis-cli |
Locks & Limits screen |
| Dispatches skipped because a unique lock was held | Not recorded anywhere | Counted per job, hourly and daily |
ShouldBeUnique lock released on out-of-band removal or a pre-start failure |
No, the lock wedges | Released, owner-checked |
| Jobs held back by a rate limiter or throttle | A release looks like any other | Counted per limiter, with the reason |
| Queue failures Laravel handles silently | No, or a misleading error | RetryWindowExpired, expired reservations |
| What each job class costs in memory and CPU | No, runtime only | Peak memory, heap growth, CPU |
| Why workers are being replaced | No | Restarts by reason, and fleet memory & CPU |
| Prometheus scrape endpoint & Grafana dashboard | No | Both, bundled |
| Let an AI agent inspect queues, jobs and metrics | No | Read-only MCP server |
| Price | Free, MIT | $99 once, a year of upgrades |
What is identical#
Skyline is a rebased fork: its main is a recent upstream Horizon tag with the Skyline commits
replayed on top, and upstream releases are merged within 14 days. The parts of Horizon you already rely on run the
same code as upstream, with no reimplementation to behave subtly differently:
- The
Laravel\Horizon\namespace, and every class in it. config/horizon.php, including supervisors, balancing, autoscaling andtrim.- Every
php artisan horizon:*command. - The dashboard's mount point,
/horizon, and theviewHorizongate that protects it. - Metrics snapshots, tags, long-wait notifications.
The official Horizon documentation applies to Skyline in full, and this site documents only the differences.
When switching is worth it#
Horizon is the free, official package, and it does its job well. If watching your queues is all you need, keep it: Skyline changes nothing about that job, so paying for it would buy you nothing.
The case for switching usually shows up as a recurring frustration:
- You have SSH'd into a worker box during an incident to stop one queue, because the dashboard's only pause button stops all of them.
- You have waited out a backoff window after deploying a fix, watching a retrying job sit there because there is no way to say "run it now".
- You have written a one-off Artisan command to inspect or drain a queue, because the dashboard can count the backlog but not show you what is in it.
- You have a queue that starves under strict priority, and turning balancing on to fix it costs you a floor of idle workers you do not need.
-
You have had a job stop running with no error at all — a
ShouldBeUniquelock left held by a cleared queue or a job that failed before it started, silently swallowing every dispatch after it. Horizon shows nothing, because a skipped dispatch never reaches the queue. - You have watched workers restart all day without being able to say which job class was eating the memory, because Horizon measures runtime and nothing else.
In each case Horizon shows you the problem — or, in the last two, does not show it at all — and the fix happens in a terminal. Skyline covers all six.
Where an APM fits#
Skyline controls queues and collects no telemetry. It runs entirely on your own servers, with no agent and no data sent to a vendor. Tools like Laravel Nightwatch, Datadog or Sentry tell you that something is wrong across your whole application. Skyline works alongside them on the queue itself, so you can pause it, drain it or jump a job to the front once the alert has fired.
What the difference costs#
Horizon is free and MIT-licensed. Skyline is a one-time $99 purchase that includes twelve months of upgrades. Two details of that licence usually go unstated in commercial forks:
- There is no runtime licence check. The licence authenticates Composer against a private registry. Nothing in the shipped package phones home or can interrupt job processing, so an expired upgrade year cannot take your queues down — every version published during it stays installable, and only releases made after it stop resolving until you renew.
- The source is MIT-licensed, as Horizon's is. What you are buying is access to the registry and the maintenance behind it.
Keeping up with upstream#
A fork can leave you stranded two Laravel majors behind if it quietly stops tracking upstream. Skyline is kept as a rebase, so taking a new Horizon release means replaying a small, known set of commits onto a new tag, and upstream releases are merged within 14 days. Skyline-only features are built on top of that current base.
The cost of switching, and of switching back#
Because Skyline declares replace: laravel/horizon and keeps the namespace, adopting it is a Composer
change and a redeploy — no code changes, no migrations. Rolling back is the same operation in reverse, and it loses
nothing but the Skyline-only views: there is no schema to unwind, and your queues and jobs are untouched. See
Migrating from Laravel Horizon.
Common questions
Should I use Laravel Horizon or Skyline for Laravel?
Use Horizon if monitoring is all you need — it is free, official, and Skyline changes none of it. Choose Skyline when you find yourself needing to act on what the dashboard shows: pausing one misbehaving queue during an incident, running a retrying job immediately after deploying the fix, draining a backlog, or giving one queue priority without starving the others.
Is Skyline for Laravel a drop-in replacement for Laravel Horizon?
Yes. Skyline keeps the Laravel\Horizon\ namespace and declares replace on laravel/horizon in Composer, so your existing config/horizon.php, service-provider customisations, gate definitions and horizon:* Artisan commands all keep working. The dashboard still mounts at /horizon. There are no migrations and no application code changes.
Will Skyline for Laravel keep up with Laravel Horizon releases?
Skyline is a rebased fork rather than a divergent one: its main branch is a recent upstream Horizon tag with the Skyline commits replayed on top, and upstream releases are merged within 14 days. New Horizon versions, bug fixes and Laravel compatibility updates land on a current base rather than instead of one.
Can I roll back from Skyline to Horizon?
Yes, and it is the same operation in reverse: require laravel/horizon again and drop the Skyline package. Skyline adds no database schema and stores its extra tracking data under the same Redis prefix, so a rollback loses the Skyline-only views and leaves your queues and jobs untouched.
What does Skyline for Laravel show that Horizon cannot?
The failures Laravel handles without saying anything. A dispatch skipped because a ShouldBeUnique lock is held never reaches the queue, so Horizon has nothing to show; Skyline lists the held locks, flags the stranded ones, counts the dispatches each has skipped and gives you an owner-checked Release button. Jobs released by a rate limiter or throttle look like any other release to Horizon; Skyline attributes them per limiter. A job refused on pickup after its retryUntil() deadline is reported as RetryWindowExpired rather than "has been attempted too many times". And with insights enabled it records what each job class costs in memory and CPU, what the whole worker fleet is using, and why workers are being replaced — none of which Horizon measures.
How is Skyline different from Laravel Nightwatch or an APM?
Skyline is queue control, not telemetry. It runs entirely on your own servers — no agent, no data egress. An APM tells you something is wrong; Skyline is the hands-on layer that lets you do something about it. They pair rather than compete.