Skip to main content

Workflow limits

Learn about the limits applied to workflows.

Retool imposes certain limits on workflow runs and workflow block runs.

Workflow run limits​

A workflow run is a complete execution of a workflow through a trigger (e.g. app, schedule, webhook, Retool Event) or by manually running the workflow in the workflow IDE.

Timeout​

Retool limits the length of time a workflow run can remain in execution before it is automatically terminated.

For asynchronous workflow runs, the timeout is 30 hours. For asynchronous workflows with User Task blocks, the timeout is 60 days.

For synchronous workflows runs, the timeout is 15 minutes up to executing the first webhook Response block. The remainder of the workflow follows the asynchronous timeout.

Memory and CPU​

A workflow run can use up to 1GB in memory, and 1 vCPU.

Logs​

A workflow run has no limits on log generation or storage.

Rate limits​

Workflow concurrency is how many of the same workflow can be actively running within a 15 minute period. If a workflow reaches the concurrency limit, one of the runs must complete (whether successful or not) before another can start.

Workflow burst limit is how many runs of the same workflow can be triggered within a 10 second period.

Workflow concurrency is 60, and burst limit is 200.

Triggers​

App triggers​

Workflows triggered via an app are not limited by the 2 minute query timeout on cloud or DBCONNECTOR_QUERY_TIMEOUT_MS on self-hosted. If there is no webhook response block, the workflow is enqueued for asynchronous execution and responds immediately to the Retool frontend. If there is a webhook response block, the workflow waits to execute all the blocks until the first webhook Response block, respond back to the Retool frontend, and then enqueue the rest of the execution to happen asynchronously.

On self-hosted instances, any network middlewares (load balancers, proxies, etc.) outside of Retool's control that surround the MAIN_BACKEND and CODE_EXECUTOR may interfere with long running network requests.

Schedule triggers​

Workflows triggered via schedule support a minimum interval of one minute. Each workflow must complete its run (whether successful or not) before another run can start. For example, a workflow that takes two minutes to complete can only be triggered every two minutes.

Workflows triggered at intervals via schedule have additional jitter to reduce spikes in queue time and smooth out the load on the system. Jitter is calculated with the following equation: random(0, min(6 minutes, 10% of the interval)). For example, a workflow with a 1 hour interval will have a jitter of random(0, 6 minutes) and a workflow with a 10 minute interval will have a jitter of random(0, 1 minute). On self-hosted instances, this behavior can be disabled in the Beta settings, by turning off Enable jitter on cron Workflows..

Workflow block triggers​

Synchronous workflows triggered from another workflow have a timeout of 3 minutes.

Block limits​

Limits covered in this section apply to individual blocks that make up a workflow. These limits apply when blocks are run individually via the workflows editor and when they are run as part of a workflow run.

Resource blocks​

The default timeout is 10 seconds and is configurable with block settings.

For asynchronous workflow runs, resource blocks can run up to 10 minutes. For synchronous workflows runs, resource blocks can run up to 2 minutes.

Code blocks​

The default timeout is 2 minutes and is configurable with block settings up to 15 minutes.

Loop blocks​

Loops V2 blocks can run indefinitely (up to the workflow run timeout), but each iteration has a default of 10 seconds and can run up to 2 minutes.

Legacy Loop blocks have a default of 10 seconds and can run up to 15 minutes, including all iterations.

Workflow blocks​

The default timeout is 10 seconds and is configurable with block settings up to 3 minutes.