Skyline

Queue control

Front-of-queue dispatching

Send an urgent job to the head of the queue so a worker picks it up next.

A dispatched job is normally appended to the tail of its queue and processed in FIFO order. Skyline can also prepend a job to the head of the queue, so it is the next job a worker picks up — ad-hoc prioritisation without standing up a dedicated high-priority queue.

Usage

Add the InteractsWithFrontOfQueue trait to the job, then call onFront() on the pending dispatch:

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Laravel\Horizon\InteractsWithFrontOfQueue;

class ProcessPodcast implements ShouldQueue
{
    use Dispatchable, InteractsWithFrontOfQueue, Queueable;

    // ...
}
// Jump to the front of the queue:
ProcessPodcast::dispatch($podcast)->onFront();

// Composes with the usual dispatch options:
ProcessPodcast::dispatch($podcast)->onFront()->onQueue('media');

When you are working with raw payloads, reach for the underlying queue method directly:

Queue::connection('redis')->pushRawOnFront($payload, 'media');

How it works

A Redis queue is a list. Dispatching normally RPUSHes the payload onto the tail while workers LPOP from the head. onFront() flags the job, and Skyline's RedisQueue then LPUSHes it onto the head instead — so the next worker to pop takes it.

A front-pushed job still fires the usual JobPending and JobPushed events, so it appears on the dashboard and in metrics exactly like any other job.

Why the trait is required

Illuminate\Foundation\Bus\PendingDispatch is not macroable, so onFront() cannot be registered globally. It is provided by the trait and reached through PendingDispatch's __call proxy, which forwards unknown methods to the underlying job. That is why the job class itself must use InteractsWithFrontOfQueue — without it, the call has nowhere to land.

Caveats

Front-of-queue dispatch is a deliberate escape hatch. It buys latency for one job by breaking a property the rest of the system quietly assumes.

  • Immediate dispatch only. Delayed jobs (->delay(...)) live in a sorted set ordered by their available-at time, so onFront() has no effect on them until they migrate onto the ready queue.
  • It breaks FIFO ordering. Prepending is a priority side-channel. For stable, configuration-driven priorities prefer several queues served in order — or weighted queues.
  • It skews wait-time metrics. Skyline estimates a queue's actual wait time from the job at the head of the list, on the assumption that it is the oldest. A freshly prepended job sits at the head, so actual wait time and long-wait notifications can under-report the true backlog on queues that receive front-pushed jobs. There is no cheap fix for this once FIFO is broken.
  • Redis only. The behaviour relies on Redis list semantics and does not apply to the sync or database queue drivers.
Use it sparingly

If most of your jobs go to the front, none of them do. Front-of-queue dispatch works best as a rare, operator- or incident-driven action — the "this one customer's export is on fire" lever — not as a standing property of a job class.

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.

Sign up for early access