Workflows pricing

This document explains Workflows pricing details. You can also use the Google Cloud Pricing Calculator to estimate the cost of using Workflows.

If you pay in a currency other than USD, the prices listed in your currency on Cloud Platform SKUs apply.

Pricing overview

Workflows pricing is calculated monthly based on the number of workflow steps executed.

The following count toward the total of workflow steps executed:

  • Any step that executes successfully.
  • Any step that fails during execution.
  • Any step that is retried during a workflow execution. Each retry attempt counts as a step execution.

Internal and external steps

Steps can be classified as internal or external. Internal and external steps are priced differently:

Internal steps

Steps that occur inside Google Cloud when you execute your workflow.

Types of internal steps include:

  • Requests sent to * APIs
  • Requests sent to APIs running on Compute Engine, Google Kubernetes Engine, or Kubernetes and using * domain names
  • Requests sent to APIs running on App Engine and using * domain names
  • Cloud Functions invocations
  • Cloud Run invocations using * domain names
  • Assigning and evaluating variables
  • Evaluating conditional statements
  • Calls to user-defined subworkflows or built-in functions (standard library and connectors)
  • Polling attempts made by connectors for long-running operations and controlled using connector_params.polling_policy
External steps

Steps that make an external HTTP request to resources outside of Google Cloud, or wait for HTTP callbacks.

Types of external steps include:

  • Requests sent to external APIs
  • Requests sent to Google Cloud resources that use custom domains
  • Steps that wait for a callback to be received using events.await_callback

You incur charges for increments of 1,000 internal steps or external steps. For an example of how this works, see this pricing example.

Subworkflow costs

Pricing for subworkflows is calculated using the same pricing guidelines as a regular workflow. As a result, calling a subworkflow generates costs equal to the cost of all of the subworkflow's steps plus the cost of the step that calls the subworkflow.

Free usage

As part of the Google Cloud Free Tier, Workflows provides resources that are free to use up to specific limits. These usage limits are available both during and after the free trial period. If you are no longer in the free trial period, you incur charges beyond these Always Free limits according to the pricing table.

Resource Monthly free usage limit
Internal steps 5,000
External steps 2,000

Pricing table

Pricing example

Your monthly cost comes from the total number of internal and external steps performed in all of your workflow executions. The billing calculation subtracts the free usage from each total, counts the number of 1,000 increments that you have fully or partially used for each category, multiplies each count by the associated unit cost, then adds those results together to get the total charges.

For example, if your workflow executions use a total of 6,500 internal steps and 3,999 external steps in one month:

Total internal steps that you used: 6,500

Internal steps that the free tier covers: 5,000

Additional internal steps: 1,500

  • Fully or partially used increments of 1,000 steps: 2
  • Cost for 2 increments of internal steps: 2 * $0.01 = $0.02
Total external steps that you used: 3,999

External steps that the free tier covers: 2,000

Additional external steps: 1,999

  • Fully or partially used increments of 1,000 steps: 2
  • Cost for 2 increments of external steps: 2 * $0.025 = $0.05
Total charges for the month: $0.02 + $0.05 = $0.07

Optimize usage

As demonstrated by the preceding example, the cost to run a workflow is minimal. However, for high volume usage, apply the following guidelines to optimize usage and decrease cost:

  • Instead of using custom domains, ensure that any calls to Google Cloud services use *, *, *, or * so that you are billed for internal and not external steps.

  • Apply a custom retry policy that balances your latency and reliability needs with costs. More frequent retries lower latency and increase reliability, but can also increase costs.

  • When using connectors that wait for long-running operations, set a custom polling policy that optimizes latency for cost. For example, if you expect an operation to take over an hour, you might want a policy that initially polls after one minute in case of an immediate failure, and then every 15 minutes after that.

  • Combine assignments into one step.

  • Avoid excessive use of sys.log steps. Consider using call logging instead.

What's next

Request a custom quote

With Google Cloud's pay-as-you-go pricing, you only pay for the services you use. Connect with our sales team to get a custom quote for your organization.
Contact sales