Webhook debugging guide

Last edited: 1/15/2025

NOTE: version 0.10.0 of pg*net is out. You should consider updating your database in the Infrastructure Settings if you are on a prior version. If you do not know your version, you can check the Extensions Dashboard.

Debugging Steps

1. Test if webhooks are active: Webhooks are run in a Postgresql background worker. The first debugging step is to see if the worker is active. Run the following SQL code:


_10
select pid from pg_stat_activity where backend_type ilike '%pg_net%';

If it does not return an integer, then the worker has failed and needs to be restarted. If you are running PG_NET 0.8 or later, you can restart the background worker by executing the following function:


_10
select net.worker_restart();

Otherwise, it is necessary to fast reboot your instance in the Dashboard's Settings.

2. Remove any triggers on net tables:

Using pg_net in triggers on most tables is fine; however, please do not add triggers to the net._http_response or net.http_request_queue tables.

The net tables are special and if triggers on them fail or call a pg_net function (http_get, http_post, http_delete), it can lead to an infinite loop. This warning is irrelevant to most projects, but it's worth specifying just in case.

3. Check for timeout errors

NOTE: The timeout issue has been patched in pg*net v0.11. It is available in Postgres 15.6.1.135 and above. You can upgrade your version of Postgres in the Infrastructure Settings.

Go to your Table Editor and navigate to the net schema. It will contain two tables:

  • _http_response
  • http_request_queue

The _http_response table saves all the response messages from the past 6 hours. If every column contains NULL values, except for the id, error_msg, and created columns, then you are experiencing a timeout bug.

By default, webhooks will execute the next 200 available queued requests. If the requests are too intense, it may result in a mass timeout. In the Webhook Dashboard, you should increase your webhook's timeout to minimize this issue.

4. Inspect endpoints The below code makes a request to the Postman Echo API through PG_NET


_10
select
_10
net.http_post(
_10
url := 'https://postman-echo.com/post',
_10
body := '{"key1": "value", "key2": 5}'::jsonb
_10
) as request_id;

Postman will then respond with the same payload. This is just a test to confirm that requests are being properly formatted and going through.

You can then view the request in the net._http_response table in the Table Editor or with the following SQL:


_10
select
_10
*
_10
from net._http_response
_10
where id = <request_id>

You should also inspect all the failed responses from the past 6 hours to see if their are any insightful messages:


_10
select
_10
*
_10
from net._http_response
_10
where "status_code" >= 400 or "error_msg" is not null
_10
order by created desc;

Status codes from a server are described in Mozilla's web docs

5. Create logs

If none of the above suggestions uncovered the cause of the error, for debugging purposes, it may be useful to write a custom webhook that can create logs in the Dashboard's Postgres Logs. The process is outlined in the PG_NET documentation.

Conclusion:

If your issue still persists, please document it as an issue in the PG_NET Github Repo. You are also welcome to contact Supabase Support from your project's Dashboard for more guidance.