Inngest launched a new feature called bursty concurrency, which temporarily raises an account's concurrency ceiling to 3x its plan limit for up to one hour per month, letting unexpected spikes in workload run immediately instead of queuing into a backlog. The feature is free for Pro and above accounts, counted in minutes of burst usage, resets monthly, and triggers admin notifications at 25%, 50%, 75%, and 100% of the budget so teams can decide whether to permanently raise their concurrency limit.
Table of contents
What does concurrency mean in Inngest?Why does concurrency spike?How does a traditional queue handle spikes?How does bursty concurrency work?How does the burst budget work?What should you do with that number?Questions this post answers
What is Inngest's bursty concurrency feature and how much extra capacity does it provide?
Bursty concurrency lets an Inngest account run up to 3x its plan's concurrency ceiling for a total of one hour per month, so a sudden spike in work runs immediately instead of queuing into a backlog. It applies automatically at the start of a burst, is measured in minutes (each minute any burst capacity is used counts against the monthly 60), resets monthly, and is free on Pro and above plans. Admins get notifications at 25%, 50%, 75%, and 100% of the budget. Teams sizing concurrency limits for spiky workloads can track platform changes like this via daily.dev.
Does a run waiting on a human approval or external event count against Inngest's concurrency limit?
No, runs with wait-for steps hold no concurrency slot. A run that is sleeping, waiting for an event, or paused between steps does not count, so an agent waiting days for human approval uses zero concurrency until it actually has work to execute. This differs from traditional job queues, where a paused job usually still holds its worker the entire time unless manually split into separate jobs. Developers comparing queue-based systems to durable execution platforms can follow these distinctions on daily.dev.
Share this post