Zapier video processing timeout isn't a plan limit. Go async.

Your Zap grabs a new video from Google Drive, hands it to an action, and 30 seconds later the run turns red. Or it never gets that far, because the file is 400 MB and Zapier refuses to move it at all. Both failures come from the same place, and adding a paid plan doesn't fix either one.

Quick answer: A Zapier video processing timeout happens because the Webhooks by Zapier action gives up waiting after 30 seconds, and transcoding even a two-minute clip takes longer than that. The honest DIY fix is to stop doing the work inside the Zap: pass the video's URL to a video processing API, let the Zap finish immediately, and use a second Zap with a Catch Hook trigger to receive the finished file when the job is done. FFmpeg Micro is built for exactly that shape. It accepts a source URL plus a callback URL in one API call, runs FFmpeg on its own machines, and POSTs the result back to your Zapier webhook, so no step in your Zap ever waits on an encoder.

Why Zapier times out on video specifically

Zapier has two ceilings, and video is the rare payload that hits both. The first is time: a Webhooks by Zapier action waits about 30 seconds for a response, then errors the task. Code by Zapier caps execution at 1 second on free plans and 10 seconds on paid ones. The second is size: Zapier's documented file transfer ceiling is 150 MB, and plenty of app integrations give up well before that.

Transcoding blows past the time limit on almost any real input. A 10-minute 1080p clip re-encoded with libx264 at -preset veryfast takes one to four minutes of CPU time. No FFmpeg flag brings that under 30 seconds, because the constraint isn't your flags. It's that HTTP request-response was never meant to hold a rendering job open.

Which video tasks Zapier can do natively, and which need an API

Zapier handles metadata and orchestration well and handles bytes badly. Moving a file reference, writing a row, or firing a notification is native work. Opening the video and re-encoding pixels has to happen somewhere else, with Zapier acting as the dispatcher.

If the step needs to read the video's frames, it belongs outside the Zap.

The async architecture that beats both limits

Instead of one Zap that does everything and waits, you build two Zaps that each finish in under a second. The first submits a job and stops. The second wakes up when the job is done. The video never travels through Zapier, which is what kills the file size problem: you're passing a URL string, and a URL is a few hundred bytes no matter how big the video is.

The same fix solves Make.com's file ceiling. If you're on Make, Make.com's file size limit isn't your video, pass a URL instead covers the equivalent setup.

FFmpeg Micro is designed around this pattern. You send a source URL and a webhook URL in a single POST, the API returns a job ID in well under a second, and the finished file's URL arrives at your Catch Hook when processing completes. There are no servers to run and nothing in your Zap that can wait long enough to time out. The free tier covers enough jobs to test the whole architecture first.

Step 1: Create the receiving Zap first

Build the second Zap first, because you need its webhook URL to exist before anything can call it. Create a Zap with Webhooks by Zapier as the trigger and pick Catch Hook. Zapier generates a URL like https://hooks.zapier.com/hooks/catch/123456/abcdef/. Copy it.

Step 2: Trigger on the new video

In your first Zap, use whatever source you actually watch: New File in Folder in Google Drive or Dropbox, or a Catch Hook of your own if an upload form posts to you. Polling triggers check every 1 to 15 minutes, so this isn't instant. Async work doesn't care.

Step 3: Get a publicly readable URL for the source

The processing API has to download the file, so a private Drive link won't work. Add a Google Drive Share File action set to anyone-with-the-link, or store uploads in S3 or Cloudflare R2 and use a presigned URL. People skip this step, and the job fails with a download error instead of an obvious permissions message.

Step 4: Submit the job with Webhooks by Zapier

Add a Webhooks by Zapier action, choose POST, and point it at the FFmpeg Micro API with your source URL, the operation you want, and the Catch Hook URL from step 1. Set the payload type to JSON and add your API key as an Authorization header. The response comes back in milliseconds with a job ID, long before the 30-second window closes. Field names and the full option list are in the docs.

curl -X POST https://api.ffmpeg-micro.com/v1/jobs \
  -H "Authorization: Bearer $FFMPEG_MICRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "input_url": "https://drive.google.com/uc?id=FILE_ID",
    "operation": "compress",
    "options": { "height": 720, "crf": 26 },
    "webhook_url": "https://hooks.zapier.com/hooks/catch/123456/abcdef/"
  }'

That job runs this under the hood, which is what you'd run yourself if you hosted FFmpeg:

ffmpeg -i input.mp4 -vf "scale=-2:720" \
  -c:v libx264 -crf 26 -preset veryfast \
  -c:a aac -b:a 128k output.mp4

Same output. One version needs a server, a build of FFmpeg, disk for temp files, and a queue so two uploads don't fight for CPU. The other is an HTTP request.

Step 5: Log the job ID while you wait

Add a Google Sheets Create Spreadsheet Row action to your first Zap and write the job ID, the source filename, and a timestamp. That costs one task and saves hours later, because when a job never calls back you'll want a record of what was submitted. Turn the Zap on. It should run in about two seconds end to end.

Step 6: Handle the callback and publish

Back in the receiving Zap, run a test so Zapier learns the shape of the incoming payload, then map the output URL into your final action: upload to Drive, post to Slack, attach to an Airtable record, or send to YouTube. Put a Filter by Zapier step first that only continues on a success status, so failed renders don't publish a broken link.

Pitfalls that break this setup in production

Most failures here happen at the seams between the two Zaps, not in the video work.

When Zapier is the wrong host for this workflow

Zapier is a good dispatcher and a poor conveyor belt. Once your pipeline branches on file properties, loops over a list of clips, or handles 500 files an hour, the per-task pricing and the linear step model work against you. A self-hosted workflow runner gives you loops and bigger payloads in the orchestration layer, and the video API underneath stays the same. n8n video automation walks through that version, and batch transcoding a folder of videos covers submitting jobs in bulk instead of one Zap run at a time.

There's also a case for skipping the workflow tool. If the video step lives inside an app you already wrote, calling the API from your own backend removes a moving part and a per-task cost. Zapier earns its place when the trigger and the destination are both SaaS apps you don't control.

FAQ

What is the actual Zapier timeout limit for a webhook action?

The Webhooks by Zapier action waits roughly 30 seconds for a response before it errors the task. Code by Zapier allows 1 second of execution on free plans and 10 seconds on paid plans. Neither limit is adjustable, so long-running work has to be submitted asynchronously and returned via a callback.

What's the largest video file Zapier can handle?

Zapier's documented file transfer ceiling is 150 MB, and many app integrations fail below that. The workaround is to never move the bytes through Zapier: pass a public or presigned URL as a text field, and let the processing API and the destination app move the file between themselves.

Can I compress a video inside Zapier without an external service?

No Zapier-native action compresses or transcodes video, and Code by Zapier can't either: it runs JavaScript or Python in a sandbox with no FFmpeg binary and a hard cap of a few seconds. Compression has to happen on a service built for it, with Zapier submitting the job and receiving the finished file.

How do I get the result back into Zapier after the job finishes?

Create a second Zap that uses Webhooks by Zapier with the Catch Hook trigger, copy the generated URL, and pass it as the callback URL when you submit the job. When processing completes, the API POSTs the output URL to that hook and the second Zap runs. Turn the receiving Zap on before you submit real jobs, because callbacks to a disabled Zap are dropped.

Does this pattern work in Make and n8n too?

The same submit-and-callback architecture works in Make, n8n, and any tool with an HTTP module and a webhook trigger. Make uses a Webhooks module for the callback and n8n uses a Webhook node, but the shape holds: send a URL, end the run, receive the finished file on a separate trigger.

You can watch a job run this way without wiring up a single Zap. Drop a file into the playground to see the output and the timing, then sign up free and grab an API key when you're ready to point your Catch Hook at it.