How runs are counted in React Flow

In this article:

What is a run?
Testing doesn't count as runs
The exception that matters most: fetch actions create sub-flows
Retrospective initialization for update triggers
Choosing a plan for your run volume
Not sure yet? Use the free trial
Next step

Every plan on React Flow is billed based on runs per month. Before you pick a plan — or worry that you've picked the wrong one — it helps to understand exactly what counts as a run, because the answer isn't always "one trigger firing = one run."

This article walks through the core definition, the biggest exception to watch for, and how to choose a plan that matches your store's actual run volume.

What is a run?

A run is one counted execution of a workflow (or sub-flow) against real store data.

The simplest way to think about it:

Number of runs ≈ how many times your trigger event actually fired.

That covers most workflows. But there's one important exception — covered in fetch actions create sub-flows — that can break this 1:1 assumption in a big way, so it's worth reading before you estimate your monthly usage.

Testing doesn't count as runs

While you're building or debugging a workflow, you can test it using:

Run test > Simulate
Run test > Execute

Both let you manually fire a trigger — like "Order created" or "Product added to store" — against sample or real data.

Neither of these counts as a billed run.

Click around, test, and iterate freely while building — it won't burn your monthly quota.

The exception that matters most: fetch actions create sub-flows

If your workflow only reacts to its main trigger and runs simple actions (send an email, update an order, etc.), the math is simple: 1 trigger firing = 1 run.

But if you add a step partway through your workflow that fetches an additional resource or collection — for example "Fetch customers," "Fetch products," or "Fetch orders" — the execution model changes:

The fetch step fans out the workflow into a separate sub-flow for every item it returns.
Each sub-flow counts as a separate run.

Worked example

Workflow: trigger "Order created" → action "Fetch customers" → do something per customer.

The initial trigger firing = 1 run.
Suppose "Fetch customers" returns 10,000 customers. Each customer becomes its own sub-flow execution, and each sub-flow = 1 run.
Total = 1 (initial trigger) + 10,000 (sub-flows) = 10,001 runs — from a single order-created event.

A workflow that looks like "just one trigger" can silently generate thousands of runs per event once a fetch/fan-out step is added downstream. This is the single biggest thing you might misjudge when estimating your monthly plan.

Cutting the cost: use the query option

Fetch actions support a query option that lets you filter what gets pulled in. If your workflow doesn't actually need to process every record in a collection, narrow the fetch down to the subset that matters — for example, only customers with a specific tag, instead of your entire customer list.

Since each fetched item becomes its own billed sub-flow, narrowing the fetch directly reduces the number of runs generated per trigger event. Going back to the earlier example: if only 200 of the 10,000 customers actually carry the tag your workflow cares about, filtering the fetch to that tag turns a 10,001-run event into a 201-run event.

Before assuming you need a bigger plan because of a large fetch, check if a more specific query or filter can fetch fewer items and still give you the same result.

Retrospective initialization for update triggers

This section applies specifically to change-detection triggers:

Order updated
Product updated
Inventory level updated

These triggers work by comparing a resource's current value to its previously stored value to detect what changed. For resources that already existed before the workflow was created, there's no stored baseline yet — so:

The first update event on a pre-existing resource can't be evaluated as a real change. It's consumed just to store the current value as the baseline for future comparisons.
Your workflow's actual logic only starts firing from the second update onward, for each resource — unless you run a retrospective initialization.

Retrospective initialization is a one-time process that seeds baseline values for all existing resources up front, so change-detection works correctly starting from the very first real change, for every resource, immediately.

Running a retrospective initialization also counts as runs — and because it touches every existing resource at once, it behaves like the fetch/fan-out case described above (one sub-flow/run per resource). For stores with a large catalog, customer base, or order history, this can generate a very large number of runs in a short window.

Recommendation: if you have a significant volume of existing resources to initialize, do it on the Unlimited plan to avoid large overage charges.

Choosing a plan for your run volume

On Pay as you go, the first 100 automation runs/month are free; each additional run beyond that is billed at $0.03.
A free trial lets you try a paid plan's extended limits — but usage/overage charges can still apply during the trial if your monthly run limit is exceeded.

Which plan fits?

Pay as you go is best for testing or low-activity stores — few orders, no heavy fetch/fan-out usage. No monthly fee, and the 100 free runs likely cover light usage.
It's not recommended for high-volume stores. Its overage rate ($0.03/run) is the highest of any tier, and volume can spike quickly via the fan-out mechanic or an initialization run — overage costs can easily exceed what a flat-fee paid plan would cost for the same volume.
For high volumes, a paid plan — ideally Unlimited — is the best choice. Overage risk disappears entirely and your cost becomes predictable.

Not sure yet? Use the free trial

If you're unsure which plan fits, use the 7-day free trial to observe, in practice, how your triggers fire and roughly how many runs your workflows generate over time — before committing to a paid tier.

✔️ Next step

Check our articles to learn more about the app's functionality:

Updated on: 29/09/2026

Was this article helpful?

Thank you!