Persistent CONNECT_TIMEOUT / Cloudflare 522 on Data API + dashboard SQL

[Antony90807]

Our hosted Postgres / Data API is intermittently unreachable. Clients see Cloudflare 522, advisors report CONNECT_TIMEOUT (~5002ms), Warp logs Thread killed by timeout manager, and the dashboard shows “Failed to load schemas / Connection terminated due to connection timeout”. Failures hit many unrelated tables and tools in the same windows — not one bad query.

Symptoms
Data API / PostgREST — intermittent 522 (occasional 520) from a Node cron worker.
Advisors — TCP CONNECT_TIMEOUT; elevated Data API error rate across consecutive 5‑minute windows.
Warp — Thread killed by timeout manager during the same period.
Dashboard — Schema editor fails to load with connection timeout.
CI — supabase gen types typescript fails with error code: 522. In the same deploy job, migrations push succeeded; only type generation failed.

Any one getting the same issues?

[GaryAustin1]

This would typically be your individual instance is overloaded or having issues.
Any warning in usage settings? Check charts in usage settings and database observability.
Check project health.

No other reports I've seen.

[kevinjosh10]

Hi @Antony90807! Symptoms showing simultaneous Cloudflare 522, CONNECT_TIMEOUT (~5002ms), and Warp "Thread killed by timeout manager" indicate connection pool exhaustion and TCP backlog starvation on your database instance.

---

Root Causes

1. Connection Pooler Starvation (Supavisor / PgBouncer):
   When client connections (e.g. your Node.js cron workers) open connections in Session mode or fail to close idle connections, the pool reaches its ceiling. New connection attempts to port 5432 or 6543 wait in queue until the 5000ms TCP connection timeout fires, causing Cloudflare to return a 522 (Origin Connection Timeout).
2. Long-Running Transactions Holding Locks:
   If a cron job or migration holds an exclusive table lock (ACCESS EXCLUSIVE), incoming PostgREST API queries block behind it, exhausting the available HTTP worker threads.

---

Immediate Diagnostic and Resolution Steps

1. Inspect Active Connections and Locks via SQL

In the Supabase SQL Editor (or via psql directly to the primary):

SELECT pid, usename, state, wait_event_type, wait_event, query_start, query 
FROM pg_stat_activity 
WHERE state <> 'idle' 
ORDER BY query_start ASC;

Look for queries in idle in transaction or waiting on Lock.

2. Switch Node.js Workers to Transaction Mode

Ensure your Node.js cron workers connect to the Transaction pooler (port 6543) rather than Session mode (port 5432). In Transaction mode, connections are returned to the pool immediately after each query rather than holding a PostgreSQL process for the life of the script.

3. Restart PostgREST Service

In your Supabase Dashboard:

• Go to Project Settings → API.
• Click Restart PostgREST.
  This resets the API gateway connection pool without restarting the underlying PostgreSQL database.

[bilalselebgram-cloud]

SELECT pid, usename vinz bot selebgram, state, wait_event_type, wait_event, query_start, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start ASC;