Cronjobs not working since pg_net 0.8 update
Hey Supabase team,
could you help with a pg_net privilege regression on project InvoiceMaster (id
ecxmtjaiysleuqcgfqgp in org uizitwxhqauxmfwqmeae)? Since 17th Sep 2025 every cron job that calls net.http_post has failed.
cron.job_run_details logs the same error each run:
ERROR: permission denied for sequence http_request_queue_id_seq CONTEXT: SQL statement "insert into net.http_request_queue(...) returning id"
pg_extension shows pg_net at 0.8.0, so it looks like the upgrade recreated the sequence without the previous grant to the postgres role. From our Postgres session (rolsuper=false) we can’t reapply GRANT USAGE because the sequence owner is supabase_admin, and that role isn’t exposed in the dashboard.
Could you either restore the privileges (and ideally add the default privilege so future upgrades keep them) or let us know how to do so?16 Replies
Sort of confusing. Pg_net is at 0.19. Don’t recall another report of this.
But this is a user helping user site and not monitored by staff regularly. If you really need something in your instance fixed support is the way.

In my case, it is at 0.8
I didnt know that it was user to user. I will ask support.
But... 0.19?? really?
That's quite a difference

From a few weeks ago upgraded instance. .8 is from 2 years ago almost.
Do I have to upgrade it manually?
A Postgres upgrade in infrastructure tab does it.
MIght be because I have pgjwt activated...
I can’t look today to see when they upgraded various Postgres versions with new pg_nets but would be shocked nothing in 2 years.
Anyway, it seems like for the cronjob issue I will have to call support directly, no?
Generate a ticket, but not clear at all what the issue is.
All my cronjobs stopped working the 17th September

Yeah but if you did not upgrade then not clear what changed.
But might as well generate a ticket as not seen this before that I recall. So no telling is something on your side or theirs.
This query:
Got me this output:
The failure happens inside net.http_post before the HTTP call leaves the database, no?
Seems like.
Upgrading my system has worked. Who knows, but oh well
Thanks!