Supabase Edge Function 150s Timeout: Workarounds That Work
The Supabase Edge Function 150s timeout can't be raised on demand — but batch loops, cron chunking, and a queue table make long work finish anyway. Here's the practical playbook.
Last updated: 2026-10-10 Here is the contrarian truth about the Supabase Edge Function 150s timeout: stop trying to raise it. The limit is a platform ceiling, not a setting you negotiate — and the workarounds that actually work (batch loops, cron-driven chunking, a queue table) make your long-running job more reliable than a longer timeout ever would. If your function dies at 150 seconds, the fix is to restructure the work, not to stretch the clock. What the error looks like On the free tier, a function that runs past the wall-clock limit is killed and the caller sees one of these: TimeoutError: The read operation timed out wall clock time limit reached In the function logs you may see the warning Wall clock time exceeded , and callers through the API gateway can receive HTTP 546 — Supabase's status code for a function that was terminated. The maddening part: the function often *almost* finishes. It processes 90 of 100 items, dies, and the next run starts from zero — unless you designed for resumption. Why it happens Edge Functions run on Deno Deploy infrastructure with hard per-request ceilings. The work you are doing — calling an AI API 100 times in a loop, generating a large PDF, backfilling thousands of rows — simply takes longer than the platform allows a single request to live. Every await in that loop is wall-clock time ticking down, and when the budget is gone, the isolate is destroyed mid-flight. There is no graceful shutdown hook, no "finish your current iteration" — the process is gone. What the 150s limit actually applies to This is where most confusion lives, so here are the documented ceilings for hosted Edge Functions: Limit Free tier Paid plans Wall-clock duration per request 150s 400s CPU time per request 2s 2s Request idle timeout 150s 150s Memory…