# Limits and safeguards The limits that apply to every flow and the safeguards that protect your project: duration, size, plan ceilings, low balance and events that don't start a flow. **Language:** en **Audience:** platform **TLDR:** A flow can have up to 50 steps and its longest path of waits can't exceed 180 days; fixed delays and activity waits last 1 minute to 90 days, and timezone and smart delay windows reach up to 14 days. Your plan sets how many flows can be active per project and how many contacts can enter per hour across all of them. Without funds, entry drops to a reduced pace, and old events, first syncs and CSV imports never start a flow. **Translation key:** platform.automations.flows.limits-and-safeguards **Search keywords:** maximum duration, max steps, wait limits, active flows per plan, hourly limit, plan ceiling, throttling, rate limit, no funds, out of balance, flows stopped, backfill, historical events, imported contacts didn't enter, CSV import trigger, load protection, traffic spike, quiet hours, frequency cap across flows, same contact in two flows, message sent twice **Related pages:** /platform/es/automations/flows/limits-and-safeguards, /platform/en/automations/flows/triggers-and-entry, /platform/en/automations/flows/waits, /platform/en/automations/flows/managing-flows, /platform/en/automations/flows/monitoring-a-flow, /platform/en/billing/plans-subscription, /platform/en/billing/wallet-balance **Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt **This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/llms.txt **This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/limits-and-safeguards/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/limits-and-safeguards.md (Markdown) **Other language (es):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/limits-and-safeguards.md Most of what a flow does is up to you: which event starts it, who can enter, how long each wait lasts. Around those choices sit a few boundaries that you can't change, and a set of protections that work on their own. The boundaries keep every flow finite and readable — a contact always reaches the end of a flow within a known time, and a journey never grows into something nobody can follow. The protections keep a project from sending what nobody intended: messages about orders placed months ago, a flood of entries when a data source sends thousands of events at once, or spend that carries on when the account has run out of funds. This page gathers them in one place, for when you plan a long or large flow, when you want to know what your plan changes, or when you are working out why a flow didn't start for someone. The entry limits you configure yourself — how often a contact can enter and how many contacts enter per hour or per day — are explained with the trigger, in [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry). ## At a glance Each value is explained on the page in the last column. | Limit | Value | Explained in | | --------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Shortest wait | 1 minute; only the window of a **Timezone delay** or **Smart delay** can start **Right away** | [Waits](/platform/en/automations/flows/waits#durations-and-precision) | | **Fixed delay** | 1 minute to 90 days | [Waits](/platform/en/automations/flows/waits#fixed-delay) | | **Wait for activity** | 1 minute to 90 days; up to 10 branches plus **No interaction** | [Waits](/platform/en/automations/flows/waits#wait-for-activity) | | **Timezone delay** and **Smart delay** window | **As early as** from **Right away** to 14 days; **As late as** from 8 hours to 14 days | [Waits](/platform/en/automations/flows/waits#timezone-delay) | | **Wait for delivery** | Up to 48 hours | [Waits](/platform/en/automations/flows/waits#wait-for-delivery) | | Longest path through the flow | 180 days | [Below](#how-long-a-flow-can-run) | | Steps per flow | 50 | [Below](#how-big-a-flow-can-be) | | Exit events | Up to 10 | [Goals and exits](/platform/en/automations/flows/goals-and-exits#exit-events) | | Branches in a split | Up to 10, plus the default branch | [Branches](/platform/en/automations/flows/branches#adding-ordering-and-naming-branches) | | **A/B split** | Up to 10 variants plus the default branch; at least 1 % per variant and 2 % for the default branch | [Branches](/platform/en/automations/flows/branches#ab-split) | | **Enrollments per contact limit** | **No limit** or **Once only** | [The trigger](/platform/en/automations/flows/triggers-and-entry#how-often-a-contact-can-enter) | | **Minimum time between enrollments** | 5 minutes by default; from 1 minute to about 115 days | [The trigger](/platform/en/automations/flows/triggers-and-entry#how-often-a-contact-can-enter) | | **Simultaneous runs per contact** | 5 by default; 1 to 10 | [The trigger](/platform/en/automations/flows/triggers-and-entry#how-often-a-contact-can-enter) | | **Enrollment pace** of a flow | Per hour and per day, 1 to 100,000 each | [The trigger](/platform/en/automations/flows/triggers-and-entry#enrollment-pace) | | Active flows per project | Set by your plan | [Managing flows](/platform/en/automations/flows/managing-flows#active-flows-limit) | | Entries per hour across the project | Set by your plan | [Below](#plan-limits) | | Live test | About 10 % of the contacts who enter | [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing#live-test-try-a-version-on-about-10) | ## How long a flow can run Every flow has a **maximum duration**: the longest time a contact can spend inside it, following the slowest possible path from the trigger to the end. The panel works it out from the waits on each path: - a **Fixed delay** counts its full length; - a **Timezone delay** or a **Smart delay** counts the end of its window (**As late as**); - a **Wait for activity** counts its time limit (**How long to wait**), because a contact who never reacts stays until it runs out; - a **Wait for delivery** counts about two days. Messages, branches and contact updates take no time in this count. Where the flow splits, each branch is a separate path: the waits inside one branch add up with the waits before and after the split, but never with the waits of a sibling branch, because a contact only goes down one of them. The maximum duration is the total of the slowest path. That total **can't exceed 180 days**. A flow whose slowest path is longer can be saved as a draft, but it can't be published: **Fix your flow to publish it** lists the problem for the whole flow, *Flow can run up to N days on its longest branch, over the 180-day limit.* Shortening any wait on that path solves it; the others don't matter. (How the panel lists what blocks publishing is explained in [Building a flow](/platform/en/automations/flows/building-a-flow#fix-what-blocks-publishing).) You can check the figure for every flow in the flows list: the **Max. duration** column shows "The longest a contact can stay in this flow, following its longest path of waits." See [Managing flows](/platform/en/automations/flows/managing-flows) for the list and its columns. For example, an abandoned-cart flow starts with a **Smart delay** whose window ends at 8 hours, sends a reminder, then waits up to 1 day with a **Wait for activity**. Contacts who don't click go through a **Fixed delay** of 1 day before a second reminder; contacts who click go straight to the end. The slowest path is the one without a click: 8 hours + 1 day + 1 day, so the flow's maximum duration is about 2 days and 8 hours. A win-back flow built as **Fixed delay** of 90 days, a message, a **Wait for activity** of 60 days and, on **No interaction**, another **Fixed delay** of 45 days, adds up to 195 days on its slowest path: it can't be published until one of those waits is shorter. A long maximum duration also means contacts stay on a version for a long time: when you publish a new version, the contacts already inside finish on the one they entered (see [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing)). Keep flows well under the limit when you can: a journey that needs months is usually easier to manage as two flows, the second one starting from something the contact does. ## How big a flow can be A flow can have up to **50 steps**. Every step you add from the palette counts — messages, waits, splits, contact updates, **Goal reached** and **Exit flow** — wherever it sits on the canvas. The trigger counts as one step too, and so does each exit event. When a flow gets close to the limit, the toolbar shows a notice such as **42 of 50 steps**, with the hint "This flow is close to the 50-step limit. Consider splitting it into smaller flows. It publishes normally up to the limit." The notice doesn't block anything. Above 50 steps the flow can still be saved as a draft, but it can't be published: **Fix your flow to publish it** shows *The flow has N steps, over the 50-step limit.* A flow that grows that large usually mixes several journeys. Splitting it makes each part easier to test, read and measure. A common way to chain two flows: the first one ends with an **Update tags** step that adds a tag, and the second one starts when a contact gains that tag (the **Customer created / updated** event with a condition on the added tag). See [Updating the contact](/platform/en/automations/flows/contact-updates) and [Tags, lists and new contacts](/platform/en/automations/flows/triggers-and-entry#tags-lists-and-new-contacts). ## Plan limits Your organization's plan sets two ceilings for Flows, both counted **per project**. The panel shows your figures where they apply, and the plan comparison in the panel lists them as **Active flows per project** and **Event flow enrollments per hour**. ### Entries per hour across the project Your plan caps how many contacts can enter flows **per hour, adding up every flow of the project**. It is a shared budget: a busy flow uses up room the other flows of the same project would have had. The count runs per clock hour (from 10:00 to 10:59, for example) and starts again at the next hour. The panel shows your ceiling in the trigger's **Limits** tab, under the hourly field of **Enrollment pace**: "Your plan allows up to N enrollments per hour across all the flows in this project." Each flow's own pace still applies inside that ceiling, and it can never exceed it. You can type a higher hourly value for a flow, and it is saved, but the panel warns "… is above your plan's ceiling of N per hour. It won't take effect beyond that." (How a flow's own pace works is explained in [Enrollment pace](/platform/en/automations/flows/triggers-and-entry#enrollment-pace).) When the project reaches its ceiling, every flow in it stops taking entries until the next hour. The contacts who qualify in the meantime are **dropped, not queued**: they don't enter that time, nothing is retried later, and each one is listed under **Didn't enter** with "Project hourly limit reached (plan limit)" (see [Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow#why-a-contact-didnt-enter)). For example, during a flash sale a shop receives far more orders than usual. Its **Thank you for your order** flow and its **Ask for a review** flow both start on **Order created**, so each order uses two entries of the project's hourly budget. If the budget runs out at 10:40, from then until 11:00 no flow in the project takes entries — not the thank-you, not the review request, and not the abandoned-cart flow either. To protect the flows that matter most at peak times, give the less urgent ones a lower **Enrollment pace**: a flow stops at its own hourly cap before it can use up the shared budget. If your project reaches the ceiling often, a plan with a higher ceiling gives every flow more room; the plan comparison in the panel shows each plan's **Event flow enrollments per hour**. ### Active flows per project Your plan also sets how many flows can have their entry open at the same time in each project. Flows with enrollment paused (**Pause enrollment**, the same action as **Disable** in the flows list), drafts and archived flows don't count. How the limit behaves when you publish, pause or change plan is explained in [Managing flows](/platform/en/automations/flows/managing-flows#active-flows-limit). ### What plans don't limit Plans set **speed and simultaneity**, not volume. There is no monthly allowance of runs: a flow can run as many times as its trigger fires, within the hourly ceiling. Runs themselves aren't charged, and neither are waits, branches, contact updates, goals or exits. What is charged are the **messages** a flow sends, like any other SMS or RCS message; see [Sending messages](/platform/en/automations/flows/sending-messages#what-gets-billed). ## When the account runs out of funds Flows send messages that are paid from the organization's balance, so they react when the account has no funds left. Instead of stopping completely, every flow **slows down** to a much reduced pace until funds are back. What happens while the account has no funds: - **Entry into each flow drops to a reduced pace.** The trigger's **Limits** tab shows the exact figure in its **Keep funds in your account** section: "Without funds, entry into this flow drops to N contacts per hour." While it is happening, the same section says so: "Your account has no funds, so entry into this flow has dropped to N contacts per hour." - **The contacts over that pace don't enter.** They are listed under **Didn't enter** with "Hourly entry limit reached: the account has no funds". As with every other drop, they aren't queued: they enter only on their next qualifying event, once the account has funds again. - **Contacts already inside aren't slowed down by this entry limit.** Whether the messages they reach can still be sent depends on the balance when the step runs; the contact journey shows what happened at that step (see [Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow#why-a-message-wasnt-sent)). - **The whole organization is affected.** The balance belongs to the organization, so every flow of every project slows down at the same time. - **Your team is notified.** The owner and the team members with **Full access**, **Billing** or **Marketing** receive an email and an SMS saying that the organization's flows have stopped for lack of balance, at most once a day. Despite that wording, entry has slowed down rather than stopped, and contacts already inside carry on. As soon as funds are back in the account, the normal pace returns, with nothing else to do. To keep it from happening, turn on **auto-reload**: users who manage billing see a **Set up auto-reload** link in the same section, and the settings are explained in [Auto-reload](/platform/en/billing/wallet-balance#auto-reload). If messages from your flows are missing and entries have slowed down at the same time, check the [balance](/platform/en/billing/wallet-balance) first. A **locked** project — for billing or a suspension — is a different case. No flow in it takes entries: each contact is listed under **Didn't enter** with "Project locked (billing/suspension)". The contacts already inside don't move on to their next step while the lock lasts, and a run that stays blocked for too long is ended. Without enough balance, a flow's messages aren't guaranteed to go out: keep the balance topped up or turn on auto-reload, as described above. ## Events that never start a flow A flow starts from events that are **happening now**. Some events reach your project without being new — they describe something that happened earlier, or they arrive as part of a bulk load — and they never start a flow, whatever the trigger says. The data isn't lost: the events are stored on the contact's profile and you can use them in segments and reports. They just don't trigger any flow. - **Events with an old date.** An event whose own date is well before the moment it reaches Instasent — a historical order loaded to complete a contact's history, a backfill, events from a queue replayed long after the fact — doesn't start a flow. Without this, loading last year's orders would send a thank-you message for each one. If you send events through the Ingest API, its guide explains the time window it uses: [Automations and the event time window](/platform-api/ingest-api/guide#automations-and-the-event-time-window). - **The first sync of a newly connected source.** When you connect a shop or another integration, the contacts and events it brings in the first import don't start flows. Events that arrive after that, as they happen, start flows as usual. - **CSV and copy-paste imports.** Contacts and data loaded through [CSV & copy-paste import](/platform/en/data-sources/csv-copy-paste) never start a flow, including the tags and lists an import adds. - **Events that can't trigger a flow**, because of their type or their data source, and events from a different data source than the one selected in the trigger. The events that can start a flow are listed in [Which events can start a flow](/platform/en/automations/flows/triggers-and-entry#which-events-can-start-a-flow). Flows also need a Platform project: an A2P Messaging API project doesn't run them. None of these events gets as far as the flow's entry checks, so they leave **no row in Didn't enter** and nothing in the flow's activity (see [What leaves no trace](/platform/en/automations/flows/monitoring-a-flow#what-leaves-no-trace)). For example, a shop imports a CSV of 2,000 past customers and gives them all the tag `vip`. A **VIP welcome** flow that starts when a contact gains the `vip` tag doesn't run for any of them, and a **Welcome new contacts** flow doesn't run for them either, even though they are new contacts in the project. Customers who get the `vip` tag later, through the shop's live connection or a flow's **Update tags** step, do enter. To reach the imported customers once, send them a campaign (see [Campaigns](/platform/en/campaigns)). ## Protections against bursts Separately from the pace you set, the platform protects the project when a lot arrives at once: - **Load protection.** If a very large number of entries arrives across the project in a very short time — typically a data source sending a bulk update of many contacts at once to a flow that starts on **Customer created / updated** — the protection drops part of them. They appear under **Didn't enter** as "Dropped by the project's load protection". Those rows are a sample, not one per dropped contact. Spreading bulk updates out over time, and adding event conditions so that a flow only reacts to the updates it needs, keeps a flow clear of it. - **Two events of the same contact at the same moment.** If the same contact sends two qualifying events for a flow within a few seconds, only the first one is evaluated. The second appears under **Didn't enter** as "Another activation for this contact was in progress" and isn't retried. This mostly happens when a source sends the same action twice in quick succession. - **The same event delivered twice.** An event that reaches the flow twice never creates two runs: the repeat is listed as "Already has an execution for this event". The thresholds behind these protections aren't configurable and aren't shown in the panel. What you control is the flow's own pace and re-entry limits, in [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry). ## What Flows doesn't limit Two protections that people often expect don't exist in Flows, by design. Knowing it helps you build around them. **There are no quiet hours on messages.** A **Send message** step sends as soon as a contact reaches it, at any hour. Flows has no project-wide quiet hours and no sending window on the message itself. To keep messages out of the night, place a **Timezone delay** or a **Smart delay** before the send; see [Waits](/platform/en/automations/flows/waits#there-are-no-quiet-hours-on-messages). **There is no frequency cap across flows.** Each flow decides on its own who enters, and nothing checks whether another flow, or a campaign, has just messaged the same contact. If two flows start on the same event, a contact who matches both enters both and gets both flows' messages. **Simultaneous runs per contact** doesn't help here: it only counts runs of the flow where you set it. For example, a shop has a **Browse reminder** flow on **Product added to cart** and an **Abandoned cart** flow on **Checkout started**. A shopper who adds a product and then starts a checkout enters both, and could get two reminders about the same purchase. To keep the flows from overlapping: - **Make one flow end where the other begins.** Add the other flow's trigger event as an exit event: with **Checkout started** as an exit event of the browse reminder, a shopper who reaches the checkout leaves the browse reminder and continues only in the abandoned-cart flow. See [Goals and exits](/platform/en/automations/flows/goals-and-exits). - **Exclude contacts who are already in another journey.** Tag contacts when they enter a flow (with an **Update tags** step at the start), and exclude a segment of that tag in the other flow's audience with **Exclude segments**, if your plan includes it. See [Who can enter: the audience](/platform/en/automations/flows/triggers-and-entry#who-can-enter-the-audience). - **Use one trigger per journey.** When two journeys start from the same event, build them as one flow and route contacts with a split instead of running two flows side by side; see [Branches](/platform/en/automations/flows/branches). ## Related - [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry) - Re-entry limits, the Enrollment pace settings and the events that can start a flow. - [Waits](/platform/en/automations/flows/waits) - The range of each wait and how waits add up. - [Managing flows](/platform/en/automations/flows/managing-flows) - The flows list, pausing and the active-flows limit. - [Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow) - Every reason a contact didn't enter, and what leaves no trace. - [Plans & subscription](/platform/en/billing/plans-subscription) - What each plan includes, and how to change plan. - [Balance](/platform/en/billing/wallet-balance) - Funds, auto-reload and the low-balance alert. --- This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.