If flow run fail, it will not retry it, i think retry is very impotant if the flow fail cause by 502 or something like that error
Came here just to upvote this. Absolutely agree. Some of my tasks are failing and there is no way to replay them after fixing the integration.
We hear this frequently, but we never scoped it down, can you help us understand these things:
- Do you want to retry the whole flow if any step fails, or only from the step forward?
- Do you want it to auto-retry or you’d like to manually retry the flow?
Auto retry the whole flow in my case
1 Like
The whole flow even the succeeded steps @Johnny_Wong ? How would you deal with the changes that were made because of the executed steps?
You’re right. Perhaps it’s better to retry from the flows where got failed.
2 Likes
Both, a manual retry or auto could be implemented.
In the case of retry, you can choose to retry from the error piece or retry the whole flow from the original flow or from the new and modified flow.
It’s something similar as you can do on others platforms. 
1 Like
Need this as well. Retry from where it failed so that it will pick up from where it was left off
3 Likes
Yes, this is essential. If I’m building something that I’m charging a client for, I need to know that if there is a failure, the action will eventually be carried out. Zapier and others have similar fail-safes. For Zapier, it’s called “autoreplay” and it will only replay actions that fail due to a Stopped/Errored status.
This is one of the most important updates, in my opinion. Thanks for your consideration. 
1 Like
A retry from the point the flow failed.
On tha note is it possible to be notified (e.g. by email) when a flow fails and which part failed.
1 Like
Retry from the failed step.
An auto-retry option would be great.
1 Like
I propose that any items that fail should be automatically re-queued. This approach offers several advantages. If an item succeeds upon retry, no further action is required, streamlining the process. However, if an item fails three times, it would then warrant manual review. Importantly, using a queue system ensures that the overall workflow remains uninterrupted. This means that successfully processed items aren’t affected by those that fail. Theoretically, the only items remaining in the queue would be those that have consistently failed after three attempts, allowing for targeted troubleshooting without disrupting the entire flow.
1 Like
Ash - the reality of building ANY flows with GPT means we’ll have errors. Their models get overloaded and return 500s, or they take too long. In 99.9% of cases, if you just retry exactly the same request immediately after the failed request (or even one minute later) will result in a successful completion.
Hence, for any flows that rely on multiple calls to OpenAI, we need to have an option to have failed modules automatically re-run if they failed.
With Make, we can set how many times and with what intervals a failed module will re-execute. This is superbly useful to make sure you don’t have to rerun the entire flow in case one module just fails once.
2 Likes
This feature is now available in the runs page (you’ll have to manually retry failed runs), and you get both the option to retry from where the flow failed, and the option to retry the entire flow.
2 Likes
Hey hey - thanks for adding this feature, but we’d need this to auto-retry please. This will solve 99% of failed runs with OpenAI where if the piece just retries to run in 1 minute or less, OpenAI will respond.
1 Like
Auto retry piece with predefined time delay should be available in case of failure. The users use this feature or not its should be up to their need.
1 Like
+1 for auto-retry with an option to set the max number of retries.
+1 also for auto-retry, only for failed operations, of course
Of course, auto retrying is what we’ll be going after next, but for now we can do it manually. I will keep this thread open until we have auto retry for failed flows.
2 Likes
Great work! Really looking forward to auto-reply too. Thanks! 