Concurrency Control
Concurrency control decides how many copies of the same automation can run at the same time.
It protects your systems from being overloaded and helps prevent duplicate or conflicting work.
The Basic Idea
Why It Matters
Imagine an automation updates customer records. If 50 copies run at the same time, they may all try to update the same data.
That can cause:
- Slow systems
- Locked records
- Duplicate updates
- Confusing results
- Failed runs
- Extra load on connected systems
Concurrency limits prevent this by controlling how many runs can be active at once.
Where Concurrency Is Configured
Concurrency settings are configured per-job in the job's ExecutionConfig settings. Each automation has its own limits, so you can set different rules for different automations based on how they interact with your systems.
The configuration has two main fields:
| Setting | Internal field | What it controls |
|---|---|---|
| Maximum concurrent runs | maxConcurrentExecutions | How many copies can run at the same time |
| Behavior when limit is reached | onLimitBehavior | What to do with new requests: QUEUE or REJECT |
The Two Main Settings
Maximum Concurrent Runs (maxConcurrentExecutions)
This is the number of copies that can run at the same time.
| Setting | Meaning |
|---|---|
1 | Only one run at a time |
3 | Up to three runs at the same time |
0 | No limit -- any number of runs can start |
Use a smaller number when the automation changes important data. Use a larger number when the automation is safe to run in parallel.
What Happens When the Limit Is Reached (onLimitBehavior)
| Option | Internal value | Meaning | Best when |
|---|---|---|---|
| Queue | QUEUE | Put the new run in a waiting line | Every request should eventually run |
| Reject | REJECT | Do not start the new run | The request can be tried again later |
Queue vs Reject
QUEUE holds excess requests in a waiting line so they all run eventually, while REJECT drops them immediately and expects the caller to retry. Use QUEUE for business-critical work and REJECT for real-time checks where a delayed result has no value.
Choose QUEUE when missing a run would be a problem. Choose REJECT when the request is only useful if it can start now.
Workflow Timeout
Each automation workflow has a default timeout of 10 minutes. If a run takes longer than this, it will be stopped. This timeout is configurable and helps prevent stuck or forgotten runs from occupying a concurrency slot indefinitely.
Recommended Starting Points
| Automation type | Suggested limit | What to do when full |
|---|---|---|
| Updates the same records | 1 | QUEUE |
| Updates different records | 2 to 5 | QUEUE |
| Sends emails or notifications | 10 to 20 | REJECT or QUEUE |
| Generates reports | 2 to 5 | QUEUE |
| Calls a rate-limited API | Match the API limit | QUEUE |
| Reads data only | 0 (no limit) or a high limit | QUEUE |
| Uploads to the same folder | 1 to 2 | QUEUE |
These are starting points. Adjust them after watching real runs.
Examples
Inventory Updates
Use a low maxConcurrentExecutions (such as 1) and set onLimitBehavior to QUEUE.
Why: inventory changes must not conflict with each other.
Report Generation
Use a medium maxConcurrentExecutions (such as 3) and set onLimitBehavior to QUEUE.
Why: reports can run in parallel, but too many may slow the server.
Email Notifications
Use a higher maxConcurrentExecutions (such as 10 or more).
Why: emails are usually safe to send in parallel, but you may still need to respect provider limits.
Read-Only Lookups
Set maxConcurrentExecutions to 0 (no limit) or a high number.
Why: reading data is usually safer than changing data.
How to Know the Limit Is Too Low
Setting maxConcurrentExecutions too low can cause runs to queue up faster than they drain, leading to long delays and a backlog that grows without bound during busy periods.
| Sign | What it means |
|---|---|
| Many runs are waiting in the queue | The automation may need a higher maxConcurrentExecutions |
| Runs start much later than expected | The queue is too long |
| Users often wait for simple tasks | The limit may be too strict |
How to Know the Limit Is Too High
| Sign | What it means |
|---|---|
| Databases become slow | Too many runs may be writing or reading at once |
| More timeouts appear | Connected systems may be overloaded |
| Duplicate or conflicting updates happen | Runs may be working on the same data |
| Failures increase during busy times | The maxConcurrentExecutions may be too generous |
A Safe Way to Tune Limits
- Start with a conservative maxConcurrentExecutions.
- Watch queue length, duration, and failures.
- Increase slowly if runs are waiting too long.
- Decrease if systems become slow or errors increase.
- Review again after schedules, usage, or connected systems change.
Good Concurrency Habits
Use low limits for important updates
If the automation changes records, accounts, inventory, payments, or files, be careful.
Queue work that must eventually happen
Reports, reconciliations, and business updates usually should wait (QUEUE) rather than disappear (REJECT).
Reject work that is only useful right now
Some checks or real-time requests may not matter if they start too late.
Monitor busy periods
Limits that work during quiet hours may fail during month-end or peak business times.
Related Pages
- Monitoring Automations - how to watch running and queued automations
- Retry Strategies - how retries behave when systems are busy
- Logging - how logs can show overload or timeout patterns