> ## Documentation Index
> Fetch the complete documentation index at: https://help.maestra.io/llms.txt
> Use this file to discover all available pages before exploring further.

# How to Limit How Often a Flow Runs

Use the **Limit** block to cap how many times customers can enter a specific chain inside a flow. Limits help you control spend on paid channels, smooth out load during peak periods, and hand out a finite number of rewards without overshooting.

## When to use a Limit block

* **Cap spend on paid channels.** Restrict the number of SMS or Flash Call sends so you stay inside budget.
* **Smooth infrastructure load.** Spread sends over time instead of firing everything at once.
* **Distribute limited rewards.** Hand out a fixed pool of loyalty points, promo codes, or discounts and stop once the pool is empty.

## How the Limit block works

The block counts how many customers pass through it and compares that count against the cap you set. It has two output branches:

| Branch           | What it does                                                                                                                                                                |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Within limit** | Runs the main chain. Used while the counter is below the cap.                                                                                                               |
| **Beyond limit** | Optional. Runs an alternative chain (for example, a cheaper channel) once the cap is reached. If you leave it empty, customers who hit the cap exit the flow at this block. |

While the flow is running, the block shows the current pass count and how much capacity is left.

## Set up a Limit block

<Steps>
  <Step title="Add the block">
    Drag the **Limit** block into your flow and place it before the chain you want to cap.
  </Step>

  <Step title="Choose how the cap is counted">
    Pick one of two modes:

    * **For all time** — a single cap across the entire lifetime of the flow.
    * **For a period** — a cap that resets on a schedule. Choose hours, days, calendar days, or weeks.
  </Step>

  <Step title="Enter the number of passes">
    Set the maximum number of customers allowed through the **Within limit** branch.
  </Step>

  <Step title="Connect the branches">
    Wire the **Within limit** output to the chain you want to run for the first N customers. Optionally wire the **Beyond limit** output to a fallback chain.
  </Step>

  <Step title="Turn on threshold alerts (optional)">
    Enable a notification that fires a warning when remaining capacity drops below a level you choose — useful for catching a budget that's about to run out before it does.
  </Step>
</Steps>

## Editing a live Limit block

You can change a Limit block while the flow is running, but be aware of how each change affects the counter:

| Change                                     | Effect on the counter                                          |
| ------------------------------------------ | -------------------------------------------------------------- |
| Change the number of passes only           | Counter is **preserved**. Existing pass statistics carry over. |
| Change the reset schedule (mode or period) | Counter is **reset**. Pass statistics are cleared.             |

<Warning>
  Changing the reset settings wipes the running totals. If you depend on historical pass counts, export them before you save the change.
</Warning>

## How passes are counted

A customer's run through the flow counts as a successful trigger only when a step group actually executes. If a customer enters the Limit block but the run ends there — for example, because they hit the cap and the **Beyond limit** branch is empty — that run is not recorded as a successful flow trigger.

This matters when your flow has per-customer entry restrictions: a customer who stops at the Limit block can still be re-entered later, because the platform doesn't count that pass as a completed trigger.

## Design rules to keep counts accurate

<Note>
  Don't place either of the following on the **Within limit** branch before the first step group:

  * **Delay blocks**
  * **Additional Limit blocks**

  These can throw off the count. Put your first step group right after the Limit block, then add delays or further limits downstream.
</Note>

## Limits on the Limit block itself

You can add up to **5 Limit blocks per flow**. If you need more, contact support.

## Example: capping SMS spend

Say you want to send an SMS reminder but cap the cost at \$500 a week, with an email fallback once the cap is hit.

<Steps>
  <Step title="Add the Limit block">
    Place it before the SMS send step.
  </Step>

  <Step title="Set the cap">
    Choose **For a period**, set the period to **1 week**, and enter the number of SMS sends that fits your \$500 budget.
  </Step>

  <Step title="Route the branches">
    Connect **Within limit** to the SMS send step. Connect **Beyond limit** to an email send step.
  </Step>

  <Step title="Add a threshold alert">
    Turn on the notification and set it to warn you when fewer than 10% of sends remain, so you can adjust before the week ends.
  </Step>
</Steps>

<Tip>
  Pair the Limit block with a segment filter upstream to make sure only your highest-value customers reach the paid channel before the cap is hit.
</Tip>