The attachment never arrived, and the error said timeout

Scanned contracts, site photos, a supplier's forty-page price list, the video a customer sent to justify a warranty claim. Businesses move more files than they think, and automation platforms are the least comfortable with them.

Zapier documents two numbers. "Files larger than 100 MB may result in a timeout error", and "Zapier also has a 150 MB limit for downloading (hydrating) files from connected apps".

The first number is the one people meet. The second is subtler: fetching a file out of a connected app is its own operation with its own ceiling, so a file can be perfectly acceptable where it lives and still be unreachable by the workflow meant to move it.

The word "timeout" is doing the damage

If the failure said "file too large", this article would not need to exist.

It says timeout, which sends everyone in the wrong direction. People re-run the workflow. They blame the connection. They ask whether the supplier's server was slow. The one thing that looks obviously irrelevant is the file itself — the same file that worked last month, when the scan was three pages instead of sixty.

Then there is the pattern that makes it feel random. Small files go through all day. The failure only appears with the occasional large one, and large ones are often the important ones: the signed contract rather than the enquiry, the finished job rather than the quote.

Where the size comes from when nobody chose it

Nobody sets out to email a 120 MB document. It accumulates.

Phone photos. A modern phone produces several megabytes per picture. Eight photos of a delivery in one email is a large attachment created by someone doing exactly what you asked.

Scanner defaults. Colour, 600 dpi, no compression. A ten-page document becomes enormous and nobody notices, because on the office network it opens instantly.

Whole exports. The monthly report from a supplier that used to be a summary and is now every line of the year, because their system was upgraded.

Anything with video. One clip clears every threshold on its own.

The common thread is that the growth happens at the far end, outside your system and outside your control, which is why the workflow that has run since spring starts failing in autumn with nothing changed on your side.

What to do about it

Find out where your platform stands. Two numbers: the largest file it will handle in a step, and the largest it will fetch from a connected app. If the documentation gives you only one of them, assume the smaller number applies everywhere.

Move the link, not the file. The most robust pattern is to leave the document where it is — cloud storage, the supplier's portal — and pass a link through the automation. Links do not have a size, and the file stays in one place, which also makes the deletion question later much simpler.

Fail loudly on size before the platform fails vaguely. If a step can read the file size, check it first and stop with a message that says what happened. "Invoice 4471 was not processed: attachment is 118 MB" is a message someone can act on today. A timeout is not.

Shrink at the source. Scanner set to greyscale at 200–300 dpi, photos uploaded through a form that resizes them. This is a five-minute settings change that removes most of the problem permanently.

For genuinely big things, connect the two apps directly. The vendor advises exactly that: for large files, a direct integration between the apps, or splitting the file, rather than routing the bytes through a general-purpose automation platform.

Have a named fallback path. When a document cannot go through the automation, where does it go? A shared folder plus a note is fine. What is not fine is the current answer in most businesses, which is that the document vanishes and someone finds out when the customer asks.

The thing to take away

The failure mode is not really about megabytes. It is that automation platforms are optimised for records — small, structured, predictable — and documents are none of those things. Everything gets harder at the edges: size, format, scanning, storage, retention.

So when a process is mostly about moving documents rather than moving data, it is worth asking whether the pipeline should be carrying the documents at all, or just their whereabouts. That question has already been settled in the part of the job where getting data out of PDFs is the goal; this is the same question one step earlier, at the point where the file has to travel.

If you want the limits of your own setup written down before the next sixty-page scan arrives, that is part of a process audit: $299, three business days.

Related: getting invoice data out of PDFs covers what happens once the document has arrived. This one is about the documents that never got that far.