Free plan: pgbouncer health-check logs (~11,600/day) using most of my log ingestion, can they be reduced or excluded?

[AbuZaynHalawa]

My Free-plan project ingests 30–90 MB of logs per day, and I'd like to stay within the log quota as the app grows.

Breaking the logs down in the Logs Explorer (last 24 hours), the largest single source is pgbouncer_logs: a flat ~483 entries every hour, around the clock, even overnight with zero users (~11,600/day). 98% of them are one repeating pair, about every 15 seconds:

C-...: postgres/pgbouncer@[::1]:N login attempt: db=postgres user=pgbouncer tls=TLSv1.3/... replication=no
C-...: postgres/pgbouncer@[::1]:N closing because: client close request (age=0s)

My app never connects through PgBouncer; everything goes through supabase-js (REST + Realtime). So this looks like the platform's own pooler health check.

Questions:

1. Is this an internal health check, and does it count toward my project's log ingestion?
2. Can it be excluded, or its log level reduced, on the Free plan?
3. If I don't use the dedicated pooler (port 6543), can I disable it to stop these logs?

Query used:

select replaceRegexpAll(substring(event_message, 1, 140), '[0-9]+', 'N') as message, count() as entries
from logs where source = 'pgbouncer_logs'
group by message order by entries desc limit 20

[aantti]

Thanks for flagging it. It looks like this is a known issue with an internal health check indeed and currently being addressed.

[amjaingzb]

Seeing the same thing, and it is still happening as of 24 Oct 2026. I have two Free-plan projects (production and a test copy). Each shows about 11.6k pgbouncer log rows in the last 24 hours, the same repeating pair every 15 seconds (login
attempt … user=pgbouncer then closing because: client close request (age=0s)). Real app traffic on the production project is only about 164 API requests over the same day.

Together the two projects add roughly 6 MB a day of baseline Log Ingest even when nobody is using the apps, which is about 20% of the 1 GB Free allowance per month.

Thanks for confirming it's a known issue. Is there an expected date or release for the fix, and will the already-ingested rows be excluded from the usage meter?