Laravel 13.x Release Notes on Queue Timeouts, Crashes, and Unique Locks

A queued job can fail or stop in several different ways. It can approach its timeout, its worker can be asked to restart, the worker process can crash, or an exception can be raised while the job runs. The 13.x release notes contain separate entries for several of these cases, and each entry is written as a short title with a pull request number and an author handle.

The sources for this article are the GitHub release pages for Release v13.34.0 (published 2026-09-29), Release v13.35.0 (published 2026-10-06), and Release v13.38.0 (published 2026-10-20). Pull request numbers such as #61651 are given as plain text. The order of the steps below follows a job's lifecycle. That order is this article's arrangement; the release notes are not arranged that way.

The mechanism, step by step #

1. A worker processes a queued job.
2. The job can be notified that a timeout is going to occur. Release v13.34.0 lists "Notify job when a timeout is going to occur" (#61651).
3. A worker can be restarted with queue:restart. Release v13.34.0 lists "Display error in queue:restart when worker isn't restartable" (#61706).
4. A worker crash can be counted toward maxExceptions. Release v13.34.0 lists "Allow jobs to count worker crashes towards maxExceptions" (#61737). Release v13.38.0 lists "Support CountCrashesAsExceptions on queued listeners, mailables and notifications" (#62048).
5. When processing finishes, the JobProcessed event includes a duration. Release v13.34.0 lists "Include duration in JobProcessed event" (#61672).
6. Unique locks are released in listed paths. Release v13.35.0 lists "Release unique job locks in Queue::fakeFor()" (#61824), and Release v13.38.0 lists "Release the unique lock when dispatching a scheduled job fails" (#62083).

Timeout notices reach the job #

The first entry in the sequence is the timeout notice. Release v13.34.0 includes "Notify job when a timeout is going to occur" by jackbayliss in #61651. The title names the job as the recipient, so the job is the object that is told a timeout is coming. The release notes do not describe how the notice is delivered, what timing triggers it, or what the job receives, so this article does not describe those details.

Release v13.35.0 adds a related entry for scheduled work. "Let long-running scheduled commands see schedule:interrupt" by cyppe (#61764) is about commands that run for a long time under the scheduler, and it refers to the schedule:interrupt signal. Release v13.35.0 also lists "add test for notifyJobOfSignal SIGALRM" by jackbayliss (#61787). This suggests that signal handling around jobs was tested in the same release cycle, but the notes do not explain the test or the signal path, so that link is an inference only.

Restarting workers and the memory limit #

Workers have their own lifecycle, and the notes contain entries about restarting them. Release v13.34.0 lists "Display error in queue:restart when worker isn't restartable" (#61706) by jackbayliss. The entry says that the restart command now displays an error for a worker that cannot be restarted. The title does not say which conditions make a worker non-restartable.

Release v13.35.0 lists "Support percentages for queue:work --memory" (#61753) by jackbayliss. The title says percentages are supported for the memory option of queue:work. The notes do not give the accepted syntax or the base the percentage is measured against, so this article does not describe either.

Release v13.34.0 also lists "Add --queue option to queue:flush" (#61630) by jackbayliss. The option is named in the title, but the notes do not show its full syntax or describe its behaviour beyond the title. The short example below uses that option name only to show where it appears on the command line.

php artisan queue:restart
php artisan queue:flush --queue=default

The value default in the second line is a placeholder. The release notes do not name a required value, and the example does not show what the command does with it.

Counting crashes toward maxExceptions #

A crash of the worker process is a different kind of failure from an exception thrown inside a job. Release v13.34.0 lists "Allow jobs to count worker crashes towards maxExceptions" (#61737) by williamjulianvicary. The title names both the crash and the maxExceptions property, so the notes connect the two directly.

Release v13.38.0 extends the subject to other components. It lists "Support CountCrashesAsExceptions on queued listeners, mailables and notifications" (#62048) by Taldres. The v13.34.0 entry refers to jobs, and the v13.38.0 entry refers to listeners, mailables and notifications. The two releases therefore describe different queued components. The notes do not say whether one entry depends on the other, and this article does not claim that they do.

Duration in the JobProcessed event #

Release v13.34.0 lists "Include duration in JobProcessed event" (#61672) by jackbayliss. The title states that the event now includes a duration. The notes do not give the unit, the property name, or the point in processing where the value is measured. Code that depends on those details should be checked against the release and its pull request.

The same release also lists "Notify job when a timeout is going to occur" (#61651). The two entries touch job timing in two different places: the notice that a timeout is approaching, and the duration reported with the processed event. The notes do not connect the two entries, so this article does not state that they are linked in the code.

Releasing unique locks and reporting skipped work #

Unique jobs use a lock to prevent duplicate work. The 13.x notes contain several entries about releasing those locks and reporting skipped work.

• Release v13.35.0 lists "Release unique job locks in Queue::fakeFor()" (#61824) by xurshudyan.
• Release v13.38.0 lists "Release the unique lock when dispatching a scheduled job fails" (#62083) by sumaiazaman.
• Release v13.38.0 lists "Dispatch UniqueJobSkipped when a unique broadcast event is skipped" (#62077) by jackbayliss.

The first two entries both concern releasing a lock. One is in the fake helper used in tests, and the other is in the path where a scheduled dispatch fails. The third entry adds a dispatch of UniqueJobSkipped for skipped unique broadcast events. The notes do not say whether the skipped-event path and the failed-dispatch path share any code, so this article does not make that claim.

What the notes leave open #

The release notes are titles with pull request numbers and author handles. They do not include code samples, benchmarks, migration steps, or design descriptions. This article therefore describes each change only at the level the title gives. Where a reader needs the exact timeout value, the event payload, the accepted memory syntax, or the signature of a new option, the source does not provide it. The pull request or the code is the place to confirm those details.

The table below lists the entries used in this article. Each row names the release that lists the change.

Where to start when checking an application #

The notes name specific entry points that a team can check against its own code. If an application runs queue:restart, the v13.34.0 entry on non-restartable workers applies. If it sets maxExceptions on jobs, the v13.34.0 entry covers jobs, and the v13.38.0 entry covers listeners, mailables and notifications. If it uses unique jobs with scheduled dispatch, the v13.38.0 entry on releasing the lock applies. If it reads the JobProcessed event, the v13.34.0 entry on duration applies.

Each check should begin with the release that lists the change, because the notes attribute each entry to one version. The notes do not describe a migration path between these releases, so this article does not describe one.