[13.x] Laravel Framework: Introduce WorkerInterrupted Event

@jackbayliss merged PR #59848 into laravel/framework for the 13.x branch, introducing a new WorkerInterrupted event that fires when a worker process receives a termination signal from infrastructure.

The Gap WorkerStopping Leaves

Laravel already has a WorkerStopping event, but it only fires when a worker finishes processing its current job and then exits cleanly. That is the happy path. In practice, infrastructure (Kubernetes, ECS, a plain old SIGKILL) does not always wait for a job to complete before pulling the rug.

When a worker is killed mid-job, WorkerStopping never fires. There is no built-in signal that anything unusual happened. You find out from a failed job, a missing metric, or not at all.

What WorkerInterrupted Adds

The new event fires at the point the worker receives the signal, before it has any chance to finish the current job. That gives you an early hook for logging, alerting, or calling an external service the moment infra starts shutting things down.

1use Illuminate\Queue\Events\WorkerInterrupted;
2 
3Event::listen(WorkerInterrupted::class, function (WorkerInterrupted $event) {
4    Log::warning('Worker received interrupt signal', [
5        'worker' => getmypid(),
6    ]);
7 
8    // Ping Slack, update a dashboard, flush a buffer, etc.
9});

The event is dispatched inline, consistent with how WorkerStopping is handled in the worker, so there is no new method to call or interface to implement.

How It Fits With Interruptible Jobs

Laravel's ShouldBeInterruptible interface lets jobs declare that they can handle being stopped mid-execution. WorkerInterrupted sits one level above that. The jobs themselves do not need to care about signals at all. This event is for the application layer that wants signal visibility regardless of what the jobs do.

A worker being killed in a rolling deploy, a spot instance reclaim, or a memory-limit eviction all become observable events rather than silent failures.

Who Should Care

Teams running queue workers in environments where processes can be terminated before a job finishes (containerized deployments, spot or preemptible instances, autoscaling groups) now have a first-class hook to capture that signal. Pair it with a structured log entry or an ops notification and the guesswork around unexpected worker terminations goes away.