Inngest offers two separate features, concurrency keys and priority, to control who waits in a backed-up queue and in what order. Concurrency keys create a separate queue per account or user, so one customer's burst of work doesn't block others. Priority is a number from -600 to 600 seconds that treats a run as having arrived earlier or later, so an enterprise run passes free runs that arrived less than that many seconds before it, like enterprise plans or dashboard requests. The two can be combined: a concurrency key splits work by account, then priority orders within each account's queue, for example letting interactive requests jump ahead of scheduled batches with `event.data.source == 'dashboard' ? 120 : 0`.
Table of contents
Why a basic queue can't fix thisWho waits: give each customer their own queueWhen they go: let important work move upWhich feature for which scenarioUsing both togetherGetting startedQuestions this post answers
How do I stop one customer's bulk job from blocking everyone else's background jobs in a shared queue?
Add a concurrency key, such as `key: "event.data.account_id"`, to the job's concurrency configuration. Inngest evaluates the key against each triggering event and creates a separate queue per unique value, so a limit like 2 concurrent runs per account stops one customer from taking every slot. A second, keyless limit can still cap the total across all accounts, for example limit 10. daily.dev surfaces patterns like this for developers tuning multi-tenant job queues.
What is the difference between concurrency limits and priority in a job queue?
Concurrency limits cap how many steps run at the same time, while priority controls the order runs are pulled from the queue without adding capacity. In Inngest, priority is an expression returning seconds from -600 to 600: a positive value makes a run act as if it arrived earlier, a negative value as if it arrived later, and zero leaves it unchanged. Developers choosing between queue controls can track these trade-offs on daily.dev.
How do I give enterprise customers faster turnaround than free-tier users in the same job queue?
Use a priority expression instead of splitting queues by plan, since reserving capacity for enterprise work wastes it when unused. An example expression is `event.data.plan == 'enterprise' ? 60 : 0`, which treats enterprise runs as having arrived 60 seconds earlier, letting them pass free runs that arrived less than 60 seconds before them, without starving the free queue indefinitely. daily.dev helps developers deciding how to prioritize paid traffic in shared infrastructure.
Share this post