Laravel Skyline vs Laravel Horizon
Feature by feature: what the fork adds, what is identical, and when switching is worth it.
Laravel Skyline 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 and gives you the buttons to act on it — pause a queue, run a delayed job now, drain a backlog, jump a job to the front. Everything below is additive: there is no Horizon feature Skyline removes, renames or changes.
At a glance#
| Capability | Horizon | Skyline |
|---|---|---|
Drop-in for laravel/horizon (same config, same namespaces) |
— | 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 | No | Across pending, completed, retried and failed |
| 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 |
ShouldBeUnique lock released on out-of-band removal |
No — lock wedges | Released |
| Price | Free, MIT | Annual subscription |
What is identical#
Skyline is a rebased fork rather than a divergent one: its main is a recent upstream Horizon tag
with the Skyline commits replayed on top, and upstream releases are merged within 14 days. The practical consequence
is that the parts of Horizon you already rely on are not reimplementations that might behave subtly differently —
they are the same code.
- 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 therefore applies to Skyline in full, and this site documents only the differences.
When switching is worth it#
Horizon is free, official, and genuinely good at what it does. 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 is a specific one, and it shows up as a recurring frustration rather than a missing feature:
- 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.
Each of those is a place where Horizon tells you something is wrong and then hands you a terminal. Skyline is the layer that closes that loop.
Skyline is not an APM#
A recurring question, so it is worth stating plainly: Skyline is queue control, not telemetry. It runs entirely on your own servers — no agent, no data egress, nothing shipped to a vendor. Tools like Laravel Nightwatch, Datadog or Sentry tell you that something is wrong across your whole application. Skyline is the hands-on layer for the queue specifically: pause it, drain it, jump a job to the front. They pair; they do not compete.
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.
That symmetry is deliberate. A fork of a package this central to an application should not be a one-way door, and a trial that you cannot reverse is not a trial.