--- title: The Queue is Durable. Your Worker is Not | daily.dev description: Durable execution guarantees no work is lost, but it doesn't guarantee your worker finishes that work or finishes it only once. The post lists five failure... canonical: https://daily.dev/posts/the-queue-is-durable-your-worker-is-not-ynde5ay4l twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Queue is Durable. Your Worker is Not | daily.dev og:description: Durable execution guarantees no work is lost, but it doesn't guarantee your worker finishes that work or finishes it only once. The post lists five failure... og:url: https://daily.dev/posts/the-queue-is-durable-your-worker-is-not-ynde5ay4l og:image: https://api.daily.dev/og/posts/yNDE5Ay4l.png og:image:alt: The Queue is Durable. Your Worker is Not 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. # The Queue is Durable. Your Worker is Not **[Inngest Blog](https://daily.dev/sources/inngest)** · 15 min read · 0 upvotes · 0 comments ## Summary Durable execution guarantees no work is lost, but it doesn't guarantee your worker finishes that work or finishes it only once. The post lists five failure modes developers own: pods dying mid-step, buggy deploys, hung steps, bursts starving critical work, and retries hitting non-idempotent side effects. It recommends short steps (a 30-minute step is a 30-minute hostage versus ten 3-minute steps), graceful shutdown tuned to step length, canary deploys with readiness gates, priority and per-tenant concurrency keys, capping steps per worker with settings like maxWorkerConcurrency, and idempotency keys on anything touching money or inventory. It also notes Inngest's metrics export runs at 5-minute granularity with a 5-minute delay on the Pro plan. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What's the difference between durable execution and high availability in Inngest? Durable execution guarantees no work is lost; it persists every step result and resumes runs on whatever infrastructure is available. High availability is a separate promise about when the work runs and whether your worker finishes it. A durable queue can hold work indefinitely if your workers are unreachable, which is why worker-side failures like dead pods, bad deploys, or hung steps remain your responsibility. _Developers architecting resilient job pipelines track distributed systems trade-offs like this on daily.dev._ ### Should I use Inngest's serve or connect deployment model for better worker availability? Connect is the stronger availability choice for containerized workers: there's no load balancer in the failure path, a per-worker step cap via maxWorkerConcurrency, and rollback is as simple as scaling an old-version pod back up. Serve is better on serverless or when you already trust your load balancer and deploy tooling, since step execution there is bound by your platform's HTTP timeout. _Teams weighing worker deployment models for reliability compare options like this on daily.dev._ ### How do I make retries safe when a step in a job pipeline might charge a customer twice? Add idempotency keys to anything touching money, inventory, or a customer record, since a step killed mid-flight will retry while a completed, memoized step won't. Use the payment provider's idempotency header, an upsert keyed on order ID instead of an insert, or a conditional 'WHERE version = ?' update on an inventory decrement, so the write itself refuses to double-apply. _Engineers hardening payment or inventory workflows against duplicate retries follow guidance like this on daily.dev._ ## Similar posts on daily.dev - [All your workflows are about to be long running. Build for it.](https://daily.dev/posts/all-your-workflows-are-about-to-be-long-running-build-for-it--ff8epi154) · Inngest Blog · 0 upvotes · 0 comments - [How to Build AI Agents That Don’t Start Over When They Fail](https://daily.dev/posts/how-to-build-ai-agents-that-don-t-start-over-when-they-fail-hdtnqpnlp) · System Design Newsletter · 3 upvotes · 1 comments - [Hatchet](https://daily.dev/posts/hatchet-alugo3xs3) · Hacker News · 2 upvotes · 0 comments - [Worker Backpressure \(Part 1\)](https://daily.dev/posts/worker-backpressure-part-1--cxqrqmk9u) · Canva Engineering · 2 upvotes · 0 comments - [How to Scale Long-Running API Requests](https://daily.dev/posts/how-to-scale-long-running-api-requests-aj4mhj66o) · Milan Jovanović · 57 upvotes · 3 comments --- Tags: [#distributed-systems](https://daily.dev/tags/distributed-systems), [#inngest](https://daily.dev/tags/inngest) [View this post on daily.dev](https://daily.dev/posts/the-queue-is-durable-your-worker-is-not-ynde5ay4l) ```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":"The Queue is Durable. Your Worker is Not","url":"https://daily.dev/posts/the-queue-is-durable-your-worker-is-not-ynde5ay4l","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-queue-is-durable-your-worker-is-not-ynde5ay4l"},"datePublished":"2026-10-26T22:04:57.984Z","dateModified":"2026-10-26T22:23:22.570Z","description":"Durable execution guarantees no work is lost, but it doesn't guarantee your worker finishes that work or finishes it only once. The post lists five failure...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b7572361ea9976489332c20d7a4941cc?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b7572361ea9976489332c20d7a4941cc?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Inngest Blog","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":"Inngest Blog","logo":"https://media.daily.dev/image/upload/s--ieZKUa5y--/c_limit,w_256/f_auto,q_auto/v1789329423/logos/inngest?_a=BAMAMicg0","url":"https://daily.dev/sources/inngest"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-queue-is-durable-your-worker-is-not-ynde5ay4l","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"distributed-systems,inngest","timeRequired":"PT15M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Inngest Blog","item":"https://daily.dev/sources/inngest"},{"@type":"ListItem","position":3,"name":"The Queue is Durable. Your Worker is Not"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-queue-is-durable-your-worker-is-not-ynde5ay4l#faq","mainEntity":[{"@type":"Question","name":"What's the difference between durable execution and high availability in Inngest?","acceptedAnswer":{"@type":"Answer","text":"Durable execution guarantees no work is lost; it persists every step result and resumes runs on whatever infrastructure is available. High availability is a separate promise about when the work runs and whether your worker finishes it. A durable queue can hold work indefinitely if your workers are unreachable, which is why worker-side failures like dead pods, bad deploys, or hung steps remain your responsibility. Developers architecting resilient job pipelines track distributed systems trade-offs like this on daily.dev."}},{"@type":"Question","name":"Should I use Inngest's serve or connect deployment model for better worker availability?","acceptedAnswer":{"@type":"Answer","text":"Connect is the stronger availability choice for containerized workers: there's no load balancer in the failure path, a per-worker step cap via maxWorkerConcurrency, and rollback is as simple as scaling an old-version pod back up. Serve is better on serverless or when you already trust your load balancer and deploy tooling, since step execution there is bound by your platform's HTTP timeout. Teams weighing worker deployment models for reliability compare options like this on daily.dev."}},{"@type":"Question","name":"How do I make retries safe when a step in a job pipeline might charge a customer twice?","acceptedAnswer":{"@type":"Answer","text":"Add idempotency keys to anything touching money, inventory, or a customer record, since a step killed mid-flight will retry while a completed, memoized step won't. Use the payment provider's idempotency header, an upsert keyed on order ID instead of an insert, or a conditional 'WHERE version = ?' update on an inventory decrement, so the write itself refuses to double-apply. Engineers hardening payment or inventory workflows against duplicate retries follow guidance like this on daily.dev."}}]} ```