# Skyline for Laravel vs Laravel Nightwatch

> Nightwatch records what your whole application did and sends it to Laravel's hosted service. Skyline watches the live queue on your own servers, alerts when it stops and lets you act.

Source: https://boring-observability.dev/skyline/vs/nightwatch
Section: Comparisons — Skyline for Laravel
Updated: 2026-11-11

---

**Bottom line:** Nightwatch and Skyline answer different questions, and they pair well. Nightwatch is Laravel's hosted monitoring service: it records requests, queries, exceptions and jobs across your whole application, links each job to the request that dispatched it, and opens an issue for exceptions and slow jobs. It does not read queue length or worker status, and it cannot act on a queue. Skyline replaces Horizon on your own servers, alerts when Horizon stops or a queue stalls, and gives you the controls to fix it. If you can only add one, look at your last few incidents: exceptions and slow pages point to Nightwatch, and queues that stopped without anyone noticing point to Skyline.

[Laravel Nightwatch](https://nightwatch.laravel.com) is Laravel's own hosted monitoring service. An agent process on your server collects what your application does (requests, queries, outgoing HTTP calls, jobs, scheduled tasks, mail, cache and logs) and sends it to Nightwatch, where each record becomes a billable event. Skyline for Laravel is a fork of Horizon that runs on your own servers and covers the queue and the scheduler, nothing else.

They are compared often because both claim to tell you when your jobs go wrong. They mean different things by it, and most teams who run queues seriously end up wanting both. This page describes Nightwatch as of November 2026 (package version 1.30.6).

## Two different questions

Nightwatch answers "what happened, and why?" across the whole application. A slow checkout page leads to the job it dispatched, that job's attempts, and the queries and HTTP calls each attempt made. Exceptions are grouped into issues you can assign and resolve.

Skyline answers "what is the queue doing right now, and what can I do about it?". It reads Horizon's live state in Redis, such as how many jobs are waiting and which workers are running. It alerts on that state and gives you the controls to change it.

## At a glance

| Capability | Laravel Nightwatch | Skyline |
| --- | --- | --- |
| What it covers | The whole application | Queues and the scheduler |
| Where your data goes | To Nightwatch's hosted service, through an agent on your server | It stays in Redis on your own servers |
| Queue drivers | Any that fires Laravel's queue events | Redis |
| Job attempts with duration, memory and exceptions | Yes, linked to the request that dispatched them | Yes, with [memory and CPU per job class](https://boring-observability.dev/skyline/docs/insights) when insights are on |
| Queries, HTTP calls and logs inside each job | Yes | No |
| Which jobs are recorded | Those whose dispatcher was sampled, and any that throw | Every job on your Redis queues |
| Queue length, wait time and worker status | No | Yes |
| History | 14 to 90 days, by plan | Horizon's Redis trim windows, measured in hours |
| Exception tracking with an issue workflow | Yes | No |
| Alert when a job class runs slower than a threshold | Yes | No; it alerts on a class that keeps [timing out](https://boring-observability.dev/skyline/docs/alerts) |
| Alert when a queue stalls or backs up, or Horizon stops | No | [Yes](https://boring-observability.dev/skyline/docs/alerts), with `horizon:check` [running outside the fleet](https://boring-observability.dev/skyline/docs/alerts#horizon-down) |
| Alert on failure rate per queue or job class | No; each new exception opens an issue | [Yes](https://boring-observability.dev/skyline/docs/alerts#failure-rate) |
| Alert channels | Email, Slack, a webhook, Linear | Mail, Slack, SMS, a webhook |
| Retry, pause, delete or run a job now | No, it reports only | [Yes](https://boring-observability.dev/skyline/docs/dashboard-operations) |
| Scheduled tasks | Each run with its status and duration | [Each run, missed runs marked, with Pause and Run now](https://boring-observability.dev/skyline/docs/scheduled-tasks) |
| Held `ShouldBeUnique` locks | No | [Locks & Limits screen](https://boring-observability.dev/skyline/docs/locks-and-limits) |
| Requirements | PHP 8.2+, Laravel 10+, a running agent process | PHP 8.0+, Laravel 9.21 to 13, Redis |
| Price | Free tier, then $20, $60 or $300 a month by event volume | $139 once, a year of upgrades |

## What Nightwatch sees of a queue

Nightwatch records events. Every dispatch and every job attempt is one: the class, queue, attempt number, status, duration and peak memory, plus the exceptions, queries, logs and HTTP calls that attempt produced. The Jobs panel turns those into counts of queued, processed, released and failed runs per job class, with average and p95 durations. For finding out why a job is slow or what it touched before it failed, that is better than anything a queue dashboard shows.

It does not read the queue itself. Nothing in its documentation or its package reports how many jobs are waiting or which workers are running, and it has no view of Horizon's supervisors. Its alerts are issues, opened by an exception or by a duration threshold you set on a route, job, command or scheduled task. A queue that has stopped moving throws no exception and runs no slow job, and Horizon not running produces no events at all, so neither has anything to open an issue from.

It also cannot act. The actions in Nightwatch are on issues, such as assigning and resolving them. Retrying a failed job or pausing a queue happens somewhere else.

## Sampling and jobs

Jobs in Nightwatch have no sampling setting of their own. A job follows the sampling decision of whatever dispatched it, so if you sample requests (the docs suggest a rate of 0.1 or lower), most of the jobs those requests dispatch are not recorded unless they throw. You can sample jobs separately in a `Queue::before` callback, and Nightwatch's docs warn that this gives a less complete view. Skyline is not sampled: as the Horizon install, it sees every job on your Redis queues.

## Where Nightwatch is the better answer

- **Your incidents start outside the queue.** A slow query or an exception in a controller is where Nightwatch is strongest, and Skyline sees none of it.
- **You need to know why a job failed.** The trace of a failed attempt, with its queries, HTTP calls, logs and the request that dispatched it, beats an exception message and a stack trace.
- **You are not on Redis.** Nightwatch records jobs from any queue driver that fires Laravel's events.
- **You run many applications.** Every plan allows unlimited applications and seats, and there is a free tier.

## Where Skyline is the better answer

- **The queue stops quietly.** Skyline checks the live fleet every minute for Horizon being down, a stalled queue, a backlog that is not draining and crash-looping workers, and says when each one recovers.
- **You need to act, not only to know.** Pausing one queue or releasing a stuck unique lock is an operation on Redis that only the Horizon install can perform.
- **The job never ran.** A dispatch skipped by a held `ShouldBeUnique` lock creates no event anywhere. Skyline counts those skips per lock, and its Schedule screen marks the runs your scheduler missed.
- **Your data has to stay on your servers.** Skyline keeps its data in your own Redis, and there is no agent to keep running.
- **You would rather pay once.** Skyline is a one-time payment that does not grow with your traffic. Nightwatch is billed by event volume, and a busy queue produces a lot of events.

## Running both

This is the setup we would recommend to a team that can afford both. Nightwatch starts recording jobs inside `horizon:work` processes, and Skyline keeps Horizon's commands and events, so Nightwatch sees Skyline's workers the way it sees upstream Horizon's. Let Nightwatch own exceptions and slow requests, and let Skyline own the alerts about queue state and the buttons that change it.

## Choosing between them

If you can only add one, look at your last few incidents. If they were exceptions and slow pages, start with Nightwatch, on its free tier. If they were queues that stopped and nobody noticed until a customer did, start with Skyline.


## Common questions

### Does Laravel Nightwatch alert when a queue stops processing?

Not directly. Nightwatch's alerts are issues, opened by an exception or by a duration threshold on a route, job, command or scheduled task, and its documentation describes no alert for a stalled queue, a growing backlog, a failure rate or Horizon not running. A queue that has stopped throws no exception and runs no slow job. Skyline checks the live queue every minute for those conditions and sends each alert over mail, Slack, SMS or a webhook, with a recovery message when it clears.

### Does Nightwatch show queue length or wait time?

No. Nightwatch records job events: each dispatch and attempt with its class, queue, status, duration and memory, summarised per job class with average and p95 durations. Nothing in its documentation or package reads how many jobs are waiting or which workers are running. Horizon's dashboard shows both, and Skyline keeps it.

### Can Nightwatch retry, pause or delete jobs?

No. Nightwatch reports; the actions it offers are on issues, such as assigning and resolving them. Skyline, as your Horizon install, can pause a single queue, run a delayed or retrying job now, delete waiting jobs and release a stuck ShouldBeUnique lock.

### Does Nightwatch record every job?

Not if you sample. Jobs have no sampling setting of their own: a job follows the sampling decision of whatever dispatched it, and an exception forces capture. With requests sampled at the 0.1 or lower the docs suggest, most jobs dispatched from requests are not recorded unless they throw. Skyline is not sampled and sees every job on your Redis queues.

### How much does Laravel Nightwatch cost?

As of November 2026: a free tier with 300,000 events a month and 14 days of history, then Pro at $20 a month (7.5 million events, 30 days), Team at $60 (30 million, 60 days) and Business at $300 (180 million, 90 days), with extra events billed per 100,000. Every plan allows unlimited applications and seats. Skyline is $139 once, with a year of upgrades.

### Can I use Nightwatch and Skyline together?

Yes, and it is the setup we would recommend to a team that can afford both. Nightwatch records jobs inside horizon:work processes, which Skyline keeps, so it sees Skyline's workers the way it sees upstream Horizon's. Let Nightwatch own exceptions and slow requests, and Skyline the alerts about queue state and the controls that change it.