Workflow Pricing and Limits

Vercel bills Workflows usage across three resources:

• Workflow Events: Every state transition in a workflow run is persisted as an event. See Events for more details.
• Workflow Data Written: The amount of data written to managed persistence for workflow state and event logs, including stream data.
• Workflow Data Retained: The amount of data stored per month in managed persistence.

Vercel bills each resource based on usage. Hobby includes monthly allowances for Workflow Events and Workflow Data Written. Workflow Data Retained is not available on Hobby, and Vercel bills Pro usage on demand.

You can inspect the amount of Workflow Data Written for a specific workflow run by navigating to the workflow details on the Workflows page in the dashboard. Vercel calculates Workflow Data Retained based on the amount of data written and the retention period. For example, writing 1 GB and having a retention period of 1 month would result in 1 GB-month of retained data.

Functions invoked by Workflows continue to be charged at the existing compute rates. We recommend using Fluid compute with Workflow for reduced costs and higher performance.

Workflow uses Vercel Queues to orchestrate workflow runs. Vercel bills Queues usage at standard rates, see Vercel Queues pricing for more details.

Every state transition in a workflow run is persisted as an event. The full list of events is available in the Workflow SDK documentation.

As an example, a normal step function execution produces three events: step_created, step_started, and step_completed. For every time a step re-tries due to a transient error, a step_retrying event is also created.

Storage for managed persistence is retained based on your team plan:

Storage retention is not configurable by default. You can request a custom retention period by contacting support.

The following limits apply to all Workflow runs.

Requests include any event creation or stream write operation, as well as any operation for reading events, stream chunks, metadata, or event data. For any request made from your deployment, exceeding the rate limit will automatically re-try with backoff. This includes the initial request to start the workflow. If the call to start() does not throw an error, the workflow will eventually start and run to completion or failure. This means hitting the rate limit will not cause your workflow to fail, but it will slow down the rate at which your workflows run.