A maximum timeout of 5000ms when calling an edge function through the pg_cron extension?

[od-vennre]

I am working for a company that uses Supabase as a backend and I am wondering where this limit originates. Is it originating from the pg_cron extension or from the pg_net extension? And how to possibly increase it?

[GaryAustin1]

Cron has no timeout.
Pg_net has a timeout option but I don't think it is limited to 5000 as webhooks UI allows 10000.
So must be a Supabase Cron UI decision. Not sure why.
You could use SQL to create the job I assume.

[od-vennre]

You are right it is a Cron UI decision. I found that in order to bypass it I needed to change my SQL expression to look less of a strait-forward invocation of an edge function. Certainly poor design.

[GaryAustin1]

You might gen an issue in supabase/supabase issues. I have no idea why they would have that limitation and maybe someone from Supabase will either change it or respond why.

[od-vennre]

Currently, an easy workaround is just using an obfuscated SQL invocation using pg_net:

select
  true as dummy_value,
  net.http_post(
    url:='https://xxxxxxxxxxxx/functions/v1/hubspot-migrator',
    headers:=jsonb_build_object(
      'Authorization',
      'Bearer xxxxxxxxxxxx'
    ), 
    timeout_milliseconds:=50000 -- any timeout we want
  ) as request_number;

[Rubenburdin]

Just a small note for anyone copying this pattern: the select true as dummy_value trick works because it makes the query look like a general SQL statement rather than a direct edge function invocation, which bypasses the UI's validation logic. A bit silly but it does the job.

One thing worth considering if your edge function genuinely needs 50 seconds to complete, pg_net is fire-and-forget, so you won't get the response back in your cron job regardless of the timeout. The timeout just controls how long pg_net waits before giving up on establishing the connection and sending the request. If you need to track whether the function actually succeeded, you'll want the edge function to write its status back to a table when it finishes.

Also, for long-running migrations like what you're doing with HubSpot, you might hit Edge Function's own execution time limits (default 60s on Pro, can be increased). If the migration involves processing lots of records, batching with multiple cron invocations or using Supabase's background tasks might be more reliable than one long-running function.
Worth filing that issue on supabase/supabase like Gary suggested, there's no good reason the cron UI should be more restrictive than the webhooks UI for the same underlying pg_net call.

[ErwanJes]

Do you know if using a background task https://supabase.com/docs/guides/functions/background-tasks could work when calling from a cron job?

[GaryAustin1]

It is a totally independent thing. Your cron task uses either pg_net (which won't wait for an answer at all from the function or http extension that will wait for a response. Http is very bad to do if calling it from an external request to the db as it ties up a connection. I don't know the impact from cron.

But say you use pg_net. Then your edge function gets kicked off. When it returns a response (before it goes in background mode) pg_net puts the response in an internal table in the net schema. Your function can then continue to run in background but it can't return any response to the original request, but could make its own DB/REST calls. Http you have to respond in 5 seconds I believe by default, but it has been awhile since I messed with it. The background part of the function is still independent of that.