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. classic 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 or Wait blocks, the timeout is unlimited. Individual Wait blocks are limited to a maximum of 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​

Memory limits are not enforced by default. To enable enforcement, set WORKFLOW_MONITOR_PROCESS_ENABLED to true on the code-executor container. When enabled, the memory limit defaults to 2,500 MB, configurable via WORKFLOW_MEMORY_LIMIT_MBS.

You can also set organization-level defaults and per-workflow overrides via the Retool API. Workflow-level settings take priority over organization-level settings, which take priority over the environment variable defaults. Refer to Configure code executor resource limits for details.

Logs​

A workflow run can generate and store a maximum of 10MB of logs, after which logs will be truncated.

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 and burst limit are not limited by default and can be configured via environment variables.

Concurrent external requests​

Retool limits the number of in-flight outbound requests to 50 at a time from a single workflow. Self-hosted customers can change this value by changing the WORKFLOW_REQUEST_CONCURRENCY_LIMIT environment variable.

Triggers​

Classic app triggers​

Workflows triggered via a classic app are not limited by the 2 minute query timeout on cloud or DBCONNECTOR_QUERY_TIMEOUT_MS on self-hosted instances. 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.

note

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 workflows runs, Resource query blocks can run up to 24 days. For synchronous workflows runs, Resource query blocks can run up to 2 minutes.

note

AI Action blocks have a maximum timeout of 120 seconds. If your call takes longer than 120 seconds, you can instead call the AI provider directly via REST API, which doesn’t have this restriction.

Code blocks​

The default timeout is 10 seconds and is configurable with block settings up to 24 days.

Loop blocks​

Loop 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.