Hi @tpretori 

Try using the new feature available for custom error handling: https://help.zapier.com/hc/en-us/articles/22495436062605-Set-up-custom-error-handling

Thanks Troy, unfortunately I have not been invited to that closed beta so I can’t use error handling.

Do you or does anyone else have any other suggestions?

@tpretori 

Try adding Paths and create your own custom error handling after the Zap step that can error.

2 Paths.

• Path A Filter condition if a value is returned
• Path B Filter condition if a value is not returned

What I have found out after checking our logs is actually related to the way our delay process is designed.  In the back end of things, Delay does a very similar process than a replay would.
 
After the delay step hits the release time, the process goes over any 'unplayed' steps in the Zap until it hits the delay stage and then continues with the rest of the workflow.
 
Because our process does not recognize the timeout as an actual error, it defaults to try sending your POST again as it was never technically labeled as an 'error' as such. Since the HTTP call has no status, it tries to process again. 

This was the feedback from Zapier support.

Based on this feedback I moved the delay and subsequent steps into a sub-zap, which worked to solve the issue.

I suggested this to support and this was their thoughts on why it would work:

It's possible that creating a sub-zap with a delay and subsequent steps might help in this situation. The idea behind this is to isolate the delay and subsequent steps from the main zap. This way, if there is a timeout on the webhook, the sub-zap will not be triggered again.
 
This method essentially makes your main zap and sub-zap work together, but the sub-zap will only run when it's triggered by the main zap. If the webhook times out, it shouldn't trigger the sub-zap again.