Skip to main content

Workflow usage and billing

Learn about usage and billing for Retool Workflows.

Retool calculates the total number of runs for your organization and charges for billable run usage on a monthly basis. Retool also applies some limits to workflows to ensure they remain performant and prevent runaway errors.

Retool Workflows pricing

Refer to Retool's pricing page to learn more about pricing for Retool Workflows.

How billing works

A run is an iteration of a workflow that is executed by Retool. There are two types of run: billable and non-billable. Your organization is only charged for billable run usage.

Billable runs

A run is considered billable if it successfully completed and was automatically triggered by one of the following:

Billable run examples
  • A webhook-triggered workflow that runs whenever a payment is received using Stripe.
  • A schedule-triggered workflow that runs daily at 9am to generate a report using Salesforce data.
  • A workflow that is run from within another workflow.
  • A workflow that is run from a Retool web or mobile app.

Non-billable runs

A run is considered non-billable if a workflow either:

  • Fails to run successfully (e.g., an error occurred).
  • Is manually run from the Workflow IDE.
  • Is triggered by a Retool event.

Retool does not charge for non-billable run usage.

Non-billable run examples
  • A workflow that failed because a query timed out and did not retrieve data.
  • A workflow currently in development that is manually run from the Workflow IDE for testing purposes.
  • A workflow that runs whenever a new user is invited to your Retool organization.

Usage monitoring

You can monitor workflow bandwidth, runs, and total number of active workflows for the current period in the Workflows section of your Retool organization.

Workflows usage example

Usage limits

Each workflow has timeout, memory, and rate limits. Any workflow that exceeds these limits can fail and result in partial completion. Avoid using a single workflow to perform unrelated actions when separate workflows would work instead.



Query blocks have a maximum timeout of ten minutes, and entire workflows time out after one day. You can edit a Query block's timeout by clicking ••• > Query settings on the block.



The workflows executor can hold up to 258MB in memory. The more data a workflow query requests, the longer it can take for the resource to complete the operation. Where possible, write queries that return only the results that the workflow needs (e.g., use pagination in APIs or include WHERE clauses in SQL queries).


Rate limits

The rate limit for workflows depends on whether a workflow is triggered using a schedule or in response to webhook events. To reduce the amount of interactions workflows have with your data source and reduce operational costs, make sure your workflows are triggered only when needed.


Workflows 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 support up to 200 requests every 10 seconds. If this limit is exceeded, subsequent runs may not execute.

Webhook-triggered workflows also support concurrent execution, allowing up to 50 runs at the same time. If a workflow reaches this concurrency limit, one of the runs must complete (whether successful or not) before another can start.