> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.devit.software/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# How runs are counted in React Flow

# ${color}[#204a87](How runs are counted in React Flow)

${color}[#3465a4](**In this article:**)
* [What is a run?](#1-what-is-a-run)
* [Testing doesn't count as runs](#1-testing-doesnt-count-as-runs)
* [The exception that matters most: fetch actions create sub-flows](#1-the-exception-that-matters-most-fetch-actions-create-sub-flows)
* [Retrospective initialization for update triggers](#1-retrospective-initialization-for-update-triggers)
* [Choosing a plan for your run volume](#1-choosing-a-plan-for-your-run-volume)
* [Not sure yet? Use the free trial](#1-not-sure-yet-use-the-free-trial)
* [Next step](#1-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.

# ${color}[#204a87](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](#1-the-exception-that-matters-most-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.

# ${color}[#204a87](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.

# ${color}[#204a87](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:

1. The fetch step fans out the workflow into a separate sub-flow for every item it returns.
2. 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.

# ${color}[#204a87](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](#1-the-exception-that-matters-most-fetch-actions-create-sub-flows) (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.

# ${color}[#204a87](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](#1-the-exception-that-matters-most-fetch-actions-create-sub-flows) or an [initialization run](#1-retrospective-initialization-for-update-triggers) — 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.

# ${color}[#204a87](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:

* [What will happen if I reach the limit of available number of runs?](https://help.devit.software/en/article/what-will-happen-if-i-reach-the-limit-of-available-number-of-runs-3ty62u/)
* [When do limits reset?](https://help.devit.software/en/article/when-do-limits-reset-2695ye/)
* [Can I upgrade or downgrade plan?](https://help.devit.software/en/article/can-i-upgrade-or-downgrade-plan-bu0n78/)
* [Workflow testing](https://help.devit.software/en/article/workflow-testing-1m51cf9/)