Does a paid plan fix it?

Paid plans raise the total duration from 150 to 400 seconds. Supabase’s limits page lists the 150-second response wait, 2 seconds of CPU time and 256MB of memory without a per-plan difference, so a slow or heavy function usually needs a code change.

The function runs fine on my machine. Why does it time out live?

Local runs often use small test data, so a slow query or a heavy input may only show up live. Compare the logs of a failing live request with a local run of the same input. Background tasks also behave differently under the local CLI, as described above.

What access do you need to sort it out?

The repo with the function code and the logs for a failing request. We find which limit it hits, change the code in a pull request you review, and you deploy it.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

Supabase Edge Function Timeout (504 or 546)? Fix

Short answer

A 504 means the function didn’t send a response within the 150-second request timeout, usually because of a slow query, a slow outside API or a loop. A 546, Supabase’s own resource-limit code, means it ran out of memory or CPU time, and the function’s logs say which. Speed up or put timeouts on slow calls, split heavy work into smaller jobs, and answer first when the caller doesn’t need to wait.

Find the limit, then fix it

01
Check the logs first
“Edge Function logs should provide which resource limit was exceeded.” Supabase, Status codes
A 504 is the request timeout. A 546 is a resource limit, and for a 546 the function’s logs name which one. Look before changing code, because each limit has a different fix.
02
504: no response within 150 seconds
“If an Edge Function doesn't send a response before the timeout, 504 Gateway Timeout will be returned” Supabase, Edge Functions limits
The function has to send its response within the request timeout. Long database queries, slow outside APIs and loops that never end are the usual causes, Supabase says. Speed up the slow call, and add a timeout to every outside request, as Supabase advises, so a slow service fails fast instead of waiting out the full 150 seconds.
03
546 from CPU time: 2 seconds of real computing
“Maximum CPU Time : 2s (Amount of actual time spent on the CPU per request - does not include async I/O.)” Supabase, Edge Functions limits
CPU time counts only the time spent computing, not time waiting on the network or the database. Heavy computing in the function itself, for example parsing a large file, can use it up. Split the work into smaller jobs, as Supabase suggests for large operations.
04
546 from memory
“Common causes: Memory usage exceeded available limits CPU time exceeded execution quotas Too many concurrent operations” Supabase, Status codes
Each function has 256MB of memory. Supabase lists memory, CPU time and too many concurrent operations as the common causes of a 546. Work through large data in pieces rather than holding it all at once.
05
Respond first, finish the work in the background
“You can respond to the request immediately and leave the task running in the background.” Supabase, Background Tasks
If the caller doesn’t need the result straight away, send the response at once and hand the slow part to EdgeRuntime.waitUntil. Background work gets no extra CPU or memory, and it still has to finish within the function’s total duration: 150 seconds on the Free plan, 400 on paid plans. Log failures, because the caller has already had its answer and won’t see them.
```
Deno.serve(async (req) => {
  const job = await req.json();
  // processJob is your slow function; no await, so it runs after the response
  EdgeRuntime.waitUntil(processJob(job).catch((e) => console.error('job failed', e)));
  return Response.json({ accepted: true }, { status: 202 });
});
```
06
Background tasks stop early when testing locally
“When testing Edge Functions locally with Supabase CLI, the instances are terminated automatically after a request is completed.” Supabase, Background Tasks
On your own machine, the Supabase CLI ends the function after each response, so background tasks look broken there even when they work in production. Supabase’s guide shows a config.toml setting that keeps them running locally.
```
# supabase/config.toml
[edge_runtime]
policy = "per_worker"
```

Checked against the vendor’s docs on November 1, 2026: Supabase docs: Edge Functions limits; Supabase docs: Edge Functions status codes; Supabase docs: Background Tasks.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Supabase Edge Function errorWhy does my Supabase Edge Function time out with a 504 or 546?

Find the limit, then fix it

Check the logs first

504: no response within 150 seconds

546 from CPU time: 2 seconds of real computing

546 from memory

Respond first, finish the work in the background

Background tasks stop early when testing locally

Rather hand it over?

More on this error

Describe it and get a written quote