Your automation was running, then the run was cut short and the log says it was stopped by loop protection. That means we noticed the flow going down the same path over and over without waiting for anything from the person. The protection keeps someone from receiving hundreds of messages and keeps Meta from restricting your account. This guide explains how the protection works and how to break the loop.
⚠️ Note: Being stopped is not an error, it is a deliberate safety belt. The run closes cleanly; your automation is not switched off and keeps working for other people.
You may be seeing one of these situations:
The log says the step limit was exceeded.
The log says the consecutive send limit was reached.
The log says the same step ran over and over in this session.
The log says there were too many flow jumps.
A concrete example: a gym builds a flow that asks "are you a member?". If the person does not follow the account, the flow sends them a follow invitation and then back to the original question. Since the person types nothing, the follow status never changes and the flow keeps cycling through the same two messages. On the third pass the protection kicks in and the run closes cleanly. The fix is a step before the loop back that waits for the person to reply.
How the three layers work
Protection is not a single counter; three layers come into play in order, and each catches a different kind of loop.
The same step repeating. If the same sending step runs three times without the person writing anything in between, the run closes. This layer catches loops whose condition never changes (a tag, a follow status, a field value) at the earliest point. Log reason: the same step ran over and over.
Consecutive sends. Sends made without a new message from the person and without a wait step in between are counted. At the ceiling the run closes before the next send. Log reason: the consecutive send limit was reached.
Total step limit. The last resort: a run can only execute so many steps in total. Log reason: the step limit was exceeded.
Both counters reset when the person writes. That is why legitimate flows that return to a menu, and that expect something from the person on every turn, are never affected.
Jumps from one flow to another are counted too: if the chain gets too long, the run ends with too many flow jumps.
Find the step that loops
Open the automation from Automations.
Switch to the Logs tab and tap the run that was stopped.
Read the event list from top to bottom. Find where the same step name repeats back to back.
Look at the condition just before it: if the condition returns the same answer on every turn, the loop is there.
Switch to the Flow tab, find that step on the canvas and follow the connections into it.
💡 Tip: In the per-step table on the Stats tab, a step whose visit count is far higher than the run count is a strong loop candidate.
Break the loop
What breaks a loop is the flow waiting for the person to do something. Apply at least one of the fixes below.
Put a wait step before the connection that loops back. A wait resets the consecutive send counter.
Connect the loop back into an information collection step or a message step with buttons, so the flow waits for a reply.
Make sure the condition can actually change. If you ask "does this contact have the tag?" and never add the tag on any branch, the condition answers the same forever; add an action step that sets it.
Put an end step at the end of the flow. Unconnected outputs leave runs open indefinitely.
If you use flow jumps, make sure the target flow does not come back: A → B → A is the classic loop.
Review the re-entry rule on the automation's Settings tab. With "every time" selected, the person re-enters the flow on every message; "once a day" or "once" may fit better.
After the change, try it with the simulator on the Test tab, then press Publish.
Comment reply and moderation limits
Comments are public, so they have their own, tighter counters.
A run may reply under a comment at most three times. When the limit is reached the step is skipped and the flow continues. Log reason: the comment reply limit was reached in this session.
A run may moderate a comment at most twice (hide, unhide, delete). Log reason: the comment moderation limit was reached in this session.
These counters survive a wait step, so a "wait → hide" loop cannot hide the same comment repeatedly.
Other known issues and limits
The external request step can be postponed. If the rate window is full the step is postponed; after a certain number of postponements the run ends with an error. See the external request step is not working.
One notification is sent. When loop protection fires, the portfolio owner is notified once; it is not repeated for the same automation in quick succession.
Older published versions are protected too. Protection happens at run time, so old runs are stopped even before you fix and republish the flow.
Test runs produce no notification. If you loop in the simulator, nobody is told.
The round time budget is separate. "The round ran out of time; it will continue where it left off" is not a loop; the run resumes on the next round.
If you have followed every step and the problem continues, contact our Support team.