--- title: Laravel Deadlocks: Queue Jobs That Already Ran End Up in... description: Laravel queue workers can deadlock when reserving jobs, causing jobs that already ran to land in the failed_jobs table. This happens on MySQL versions below... canonical: https://daily.dev/posts/laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs-zwrb9lex0 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Laravel Deadlocks: Queue Jobs That Already Ran End Up in failed_jobs | daily.dev og:description: Laravel queue workers can deadlock when reserving jobs, causing jobs that already ran to land in the failed_jobs table. This happens on MySQL versions below... og:url: https://daily.dev/posts/laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs-zwrb9lex0 og:image: https://api.daily.dev/og/posts/zwrb9LEx0.png og:image:alt: Laravel Deadlocks: Queue Jobs That Already Ran End Up in failed_jobs og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Laravel Deadlocks: Queue Jobs That Already Ran End Up in failed_jobs **[FREEK.DEV](https://daily.dev/sources/freek)** · 1 min read · 0 upvotes · 0 comments ## Summary Laravel queue workers can deadlock when reserving jobs, causing jobs that already ran to land in the failed_jobs table. This happens on MySQL versions below 8.0.1, or when Laravel misreads the server version, because workers reserve jobs with a plain FOR UPDATE and can deadlock on the subsequent DELETE. A single tinker command can reveal which locking behavior your setup actually uses. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why do my Laravel queue jobs that already ran end up in the failed_jobs table? This happens because of a deadlock during job reservation on MySQL versions below 8.0.1, or when Laravel misreads the server version. In these cases, workers reserve jobs using a plain FOR UPDATE lock instead of a safer locking strategy, and this can cause a deadlock on the subsequent DELETE statement, making completed jobs appear as failed. _Debugging flaky queue failures in Laravel is easier when you track fixes like this on daily.dev._ ### How can I check which row lock my Laravel queue worker is using against MySQL? A single tinker command can reveal which locking behavior a given setup actually uses, since Laravel's choice between a plain FOR UPDATE and a safer lock depends on the detected MySQL version. Running this check directly in tinker shows whether the server is misreported or below MySQL 8.0.1, which is the trigger condition for the deadlock issue. _Developers tuning Laravel's database behavior follow fixes like this on daily.dev before they hit production._ ## Similar posts on daily.dev - [Queue-Wide Inspection Methods in Laravel 13.8.0](https://daily.dev/posts/queue-wide-inspection-methods-in-laravel-13-8-0-hgzecxgmv) · Laravel News · 19 upvotes · 0 comments - [Queue-SQL: Run Mass Deletes and Updates Across Parallel Queue Jobs](https://daily.dev/posts/queue-sql-run-mass-deletes-and-updates-across-parallel-queue-jobs-y3dmmyuns) · Laravel News · 40 upvotes · 3 comments - [Your Laravel App Is Paying 20 Workers to Sleep](https://daily.dev/posts/your-laravel-app-is-paying-20-workers-to-sleep-wrk9sge8u) · Medium · 0 upvotes · 0 comments --- Tags: [#php](https://daily.dev/tags/php), [#laravel](https://daily.dev/tags/laravel), [#mysql](https://daily.dev/tags/mysql) [View this post on daily.dev](https://daily.dev/posts/laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs-zwrb9lex0) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Laravel Deadlocks: Queue Jobs That Already Ran End Up in failed_jobs","url":"https://daily.dev/posts/laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs-zwrb9lex0","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs-zwrb9lex0"},"datePublished":"2026-10-26T13:53:55.448Z","dateModified":"2026-10-26T13:54:18.922Z","description":"Laravel queue workers can deadlock when reserving jobs, causing jobs that already ran to land in the failed_jobs table. This happens on MySQL versions below...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9e0df2b4f55a1c7708bd3c2817f2737a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9e0df2b4f55a1c7708bd3c2817f2737a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"FREEK.DEV","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"FREEK.DEV","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/286e833d1aaa453d99849cd4dbb7a106","url":"https://daily.dev/sources/freek"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs-zwrb9lex0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"php,laravel,mysql","timeRequired":"PT1M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"FREEK.DEV","item":"https://daily.dev/sources/freek"},{"@type":"ListItem","position":3,"name":"Laravel Deadlocks: Queue Jobs That Already Ran End Up in failed_jobs"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/laravel-deadlocks-queue-jobs-that-already-ran-end-up-in-failed-jobs-zwrb9lex0#faq","mainEntity":[{"@type":"Question","name":"Why do my Laravel queue jobs that already ran end up in the failed_jobs table?","acceptedAnswer":{"@type":"Answer","text":"This happens because of a deadlock during job reservation on MySQL versions below 8.0.1, or when Laravel misreads the server version. In these cases, workers reserve jobs using a plain FOR UPDATE lock instead of a safer locking strategy, and this can cause a deadlock on the subsequent DELETE statement, making completed jobs appear as failed. Debugging flaky queue failures in Laravel is easier when you track fixes like this on daily.dev."}},{"@type":"Question","name":"How can I check which row lock my Laravel queue worker is using against MySQL?","acceptedAnswer":{"@type":"Answer","text":"A single tinker command can reveal which locking behavior a given setup actually uses, since Laravel's choice between a plain FOR UPDATE and a safer lock depends on the detected MySQL version. Running this check directly in tinker shows whether the server is misreported or below MySQL 8.0.1, which is the trigger condition for the deadlock issue. Developers tuning Laravel's database behavior follow fixes like this on daily.dev before they hit production."}}]} ```