The 40-second cliff: how execution timeouts create duplicate records
One slow API call, one hard time limit, and the invoice lands in your system twice. Why timeouts quietly cause duplicate records, and how to design them out.
A supplier emailed one of my clients, irritated, about being billed twice. Same amount, same everything, two invoice numbers with a suspicious gap between them. The finance team was sure they'd created it once. They had. The automation created it twice.
Here's what happened. The Make scenario created the invoice in the accounting system, and that day the accounting API was crawling. After 40 seconds, Make pulled the plug, because 40 seconds is the hard scenario timeout on its lower plans. The invoice already existed by then, but Make never got the success response. So the run counted as failed and got retried. Second invoice.
Two ways timeouts get you
There are two flavors of timeout, and most people only picture the first.
The first is the call that hangs forever. Your workflow calls some external API and waits. And waits. If you didn't set a timeout, it'll wait until the platform itself steps in. Meanwhile that run is stuck, and depending on your setup, the next ones pile up behind it.
The second is the nastier one: the platform's hard limit. Make kills a scenario after 40 seconds on lower tiers. A Zapier task, an AWS Lambda, any serverless runtime has a ceiling like this. Cross it and your workflow gets cut off mid-step. Not finished cleanly. Cut off.
Quick answer to the question that follows: what happens to your data when a run dies halfway through? It depends how far it got. Everything before the cutoff happened, everything after didn't. If step three created a record and step five would have marked it done, the record now exists with nothing recording that it's handled. That's exactly where double charges, half-finished orders, and customers getting the welcome email twice come from.
Why it never happens in testing
When you're building, everything is fast. The test API answers in 200 milliseconds, the scenario finishes in two seconds, you're nowhere near 40. The timeout is a theoretical number nobody thinks about.
Production is slower. The third-party API has a bad day. An attachment is ten times bigger than your test file. 500 records show up instead of five. Suddenly a run that used to take two seconds is scraping the 40-second line. The bug waits patiently for the worst possible moment.
How to tell a timeout is the culprit
After the fact, timeouts often look like other failures, so here are the tells. If your logs show operation timed out, gateway timeout, or a 504 status, it's obvious. More often it's subtler: a run sits in the history marked failed, yet the record was created cleanly in the target system. That combination, error on one side and a correct result on the other, is the signature of a timeout that fired after the action succeeded.
The second tell is timing. If runs only fail when things are busy, during the morning import or the month-end billing job, then volume is the trigger and the platform ceiling is the real opponent. A failure that only shows up under load is almost always a question of time or size.
What actually helps
Set timeouts on purpose instead of leaving them to chance. Every HTTP call deserves an explicit limit, and five or ten seconds is generous for most APIs. A call that hasn't answered in ten seconds usually won't answer in sixty either. Failing fast and retrying deliberately beats waiting blind.
Break up long runs. If a scenario is flirting with the platform ceiling, don't process 500 records in one pass, do 50 per run across ten runs. Shorter runs hit the limit less often and are far easier to clean up when something does go wrong.
Watch how long your runs take, too, not just whether they finish. A scenario that creeps from two seconds to twenty over a few weeks will blow past the 40-second line eventually, with no warning. Track the runtime and you see it coming, instead of hearing about it from an annoyed customer.
And the big one, the thing that stops the duplicate invoice: make the step that creates something permanent safe to repeat. Before the workflow creates an invoice, have it check whether one already exists. In practice that means a unique key per transaction, like the order number, that the target system rejects if it's already there. Then the run can retry ten times without producing ten invoices. If you want the deeper version, that's idempotency, which we've written about at length.
The takeaway
A timeout isn't a malfunction. It's a decision the platform makes for you when you don't make it yourself, and it makes that decision at the worst moment: not before something happens, but in the middle of it.
If you've got a workflow that creates, charges, or sends anything, ask yourself one thing: what happens if it dies right after that step? If you can't answer with a straight face, you've found where your next duplicate is hiding.