Quick answer
When Gravity Flow sends the same message repeatedly, compare the entry's step history with the message timestamps. A scheduled circular route can repeatedly expire, notify, and return to an earlier step. Fix the route and its exit condition on staging. Do not start by changing SMTP or restarting every affected entry.
Separate three different repeat patterns
A reminder can send another message while an entry remains on the same step. A mail-delivery retry can repeat a message without another workflow transition. A workflow loop revisits steps. These problems may look identical in an inbox, but the repair belongs to different configuration owners. Start with the entry timeline and message identifiers.
Make a small table with one row per observed event: entry, step, state, time, message, and external request if present. Sort it by time after normalizing timezones. Avoid combining several entries into one apparent sequence. Similar subjects across separate client submissions are not evidence of a single loop.
Measure the interval between repeated transitions
Use a fictional example to reason about the pattern: entry A enters review at 09:00, sends a follow-up at 09:30, returns to review, and repeats at 10:00. That regular interval suggests a configured wait or expiration worth examining. It does not prove that the scheduler itself is faulty.
A rapid stream of transitions within seconds needs a different urgency from a reminder every few days. If production is producing uncontrolled side effects, involve the workflow owner immediately and contain the affected execution through supported controls. Preserve the evidence you can obtain safely, but do not let evidence collection prolong a damaging loop.
Draw every exit, including the timeout exit
Inventory the relevant steps and record the next destination for each possible outcome. Include approval, rejection, completion, expiration, and any conditional branch actually available for that step type. A diagram that shows only the usual successful route can miss the exact path responsible for the repeated messages.
Gravity Flow identifies circular expiration paths as a cause of repeated notifications. For your workflow, verify the configured destination instead of assuming the next item in the visual list is the next executed step. Mark where a human decision, a terminating state, or a deliberate data change breaks the cycle.
Design the recovery around the business rule
Ask what should happen after the first unanswered request. A team may want one reminder, a backup reviewer, or a closed inquiry. Choose an explicit rule and an accountable owner. Do not automatically approve work as a convenient way to stop the emails if the business requires a manual acceptance decision.
If a repeat cycle is intentional, document what changes on each pass and what stops it. A counter, deadline, or processed-item flag belongs in a reviewed implementation, with limits and error handling. Do not paste generic loop-breaking code into a live workflow that also provisions accounts or sends payment instructions.
Reproduce with captured messages and disabled live integrations
Use a staging copy and a fictional entry. Capture mail locally or in a controlled test inbox, and replace external side effects with approved sandbox destinations. Start from the state immediately before the suspected cycle. Record the configured interval and allow the scheduler to process it through its normal mechanism.
Run the no-response path and the human-response path separately. Verify the actual terminal state, message count, and assigned reviewer. A test that merely stops sending email is incomplete if the entry becomes stuck or the next legitimate business action never occurs.
Resume affected entries selectively
Before changing production entries, reconcile messages and external actions already completed. A workflow restart is not a neutral retry. It can repeat a successful webhook, create duplicate CRM activity, or send a second acceptance message. Prepare a per-entry disposition when outcomes differ.
After deploying the reviewed configuration, watch the same transition and message evidence over at least the interval that previously triggered the problem. Keep the expected reminder cadence documented so a legitimate follow-up is not mistaken for a regression. Remove temporary debug collection when verification is complete, and retain only redacted evidence under the organization's normal retention process.
Illustrative diagnostic example, not customer measurements.When to bring in help
Use workflow loop troubleshooting when repeated transitions are sending customer messages or calling external systems. Share a redacted sequence and a list of affected integrations. Recovery should account for completed side effects before anyone restarts the workflow.
Related troubleshooting
Check the outcome configured for approval expiration.
Helpful references
Gravity Flow troubleshooting. Gravity Flow expiration.