Automatic retry on failure not working

Get Help
,
1

Hey guys,

I have a complex workflow set to run every Monday morning using a time trigger. I would like it to automatically run again in case of failure (as an Ask AI node exited with an error for the first time this week).

I read in the docs that the Max Failure Count option (in the Edit Time Tigger window) sets the number of automatic retry attempts if a trigger fails : *“The flow is configured to run every Monday at 6:00 AM Pacific Time, with up to 3 retry attempts if it fails.” (*Triggers - Gumloop)
{39F425EF-3332-45B2-A9BA-43237B3E61EE}

I was hoping this would enable the “automatically rerun workflow in case it fails” safety net I’m looking for, but my tests indicate that a failing workflow only runs once.

Hopefully I missed something. Please advise as this is a must have feature for workflows resilience, especially working with APIs and LLMs. And no adding an Error Shield wouldn’t yield the same behavior as what I’m looking for is at the workflow level.

Thanks,

Romain

2

Hey @cdromain!

At the moment, workflows don’t have automatic retry functionality built in. The Max Failure Count setting doesn’t control retry attempts – instead, it defines how many consecutive failed runs are allowed before the trigger is automatically disabled. This is a safety mechanism to prevent workflows from endlessly failing (for example, due to missing credentials or an external API issue).

We can definitely consider adding an option in the future to allow automatic retries on failure.

For now, there’s a workaround you can use:

  • Wrap your entire subflow/flow in an Error Shield.

  • Turn on “Pass input values through.”

  • Connect the Error output back into another instance of the same subflow.

This setup effectively lets the workflow retry itself when a failure occurs.

Here’s a quick example: Gumloop | Automation Builder

  1. Create a flow (let’s call it Flow A) containing your main workflow logic.

  2. In another flow (say, MainFlow), call Flow A as a subflow.

  3. Wrap that subflow in an Error Shield, and connect the error path back to a new Flow A node.

If Flow A fails, it’ll automatically rerun once (or as many times as you configure).

Hope that helps clarify how the failure handling works and gives you a practical workaround until native retries are supported.

1 Like
3

Hey @Rithen_Gumloop :waving_hand:

Thanks for your reply.

I was afraid you’d say that :sweat_smile: I had thought about the error shield workaround but have to say I find it rather suboptimal.
I’m surprised that such a production-oriented feature hasn’t been implemented yet. Could it please be prioritized ? It really seems essential for robust & resilient flows execution, would be a clear game-changer.

(By the way I don’t have access to the flow example you shared)

The Max Failure Count setting doesn’t control retry attempts – instead, it defines how many consecutive failed runs are allowed before the trigger is automatically disabled . This is a safety mechanism to prevent workflows from endlessly failing (for example, due to missing credentials or an external API issue).

I’m sorry but I’m not sure I get it. How can we have consecutive failed runs / endlessly failing runs if they don’t automatically retry ?

Thanks again, cheers

Romain

4

Hey Romain,

:one: I’ve given you access to the flow – can you try again and let me know if you can access it?

:two: Regarding Max Failure Count, here’s how it actually works:
If you have a trigger set to run (say, every hour), it will execute on that schedule regardless of success or failure. The Max Failure Count defines how many subsequent failures are allowed before the trigger is automatically disabled.
So it’s a safeguard to prevent a trigger from running endlessly when something is consistently broken (like missing credentials or an external API outage).

:three: We can definitely add automatic retry support to the roadmap — but given the current backlog, it may take some time before it’s implemented.
In the meantime, the Error Shield remains the most practical workaround. It gives you a similar retry-like behavior without manual restarts.

5

Hey @Rithen_Gumloop,

Thanks for your reply. I do have access to the flow example.

Looking forward to this must-have feature - my vote goes to pushing it up high in the priority list :rocket:

All the best,

Romain