Flow control

Limit concurrent work, smooth bursts, discard excess runs, or move urgent work ahead in a queue. Inngest applies these controls when it schedules function runs and steps, so you can protect the services they call. Flow control applies to durable workflows. It doesn't currently apply to durable endpoints.

Flow control types

• Step concurrency caps steps executing at the same time. Waiting runs do not use a slot.
• Throttling limits how often runs start. Extra runs wait in the queue.
• Rate limiting limits how often runs start and skips excess triggers. Use it when you can discard excess work.
• Batching groups events into one run for bulk operations.
• Singleton keeps one run active for a chosen key.
• Debounce waits for a quiet period so a burst of updates starts one run.
• Priority moves higher-value work ahead in the queue.
• Multi-tenancy applies limits by tenant key and reduces the effect of one tenant's backlog on another. Key-queue scheduling currently requires Enterprise access on request.

Flow control ordering

Inngest applies flow control in three stages:

1. Before scheduling: Rate limiting skips excess runs. Batching groups events before it schedules a run.
2. When scheduling: Debounce and singleton control which unbatched runs enter the queue.
3. When executing: Step concurrency limits how many steps execute at once.

Flow control always operates in this order. This has the following implications:

• Rate limit skips scheduling runs altogether, meaning no other flow control runs.
• Runs that are batched are grouped together, then are always scheduled once the batch finalizes. This means that the “when scheduling” flow control operators are skipped for batched items.

Combine controls carefully

Use a stable event-data key when limits should apply independently per customer or resource. Batching can work with concurrency, but it cannot be combined with rate limiting or priority. See each page for its exact behavior and constraints.