# On the database host:sudo -u postgres psql -d <admin_or_docs_db> -c " SELECT pid, now()-query_start AS runtime, state, wait_event, query FROM pg_stat_activity WHERE state='active' AND now()-query_start > interval '30 seconds' ORDER BY runtime DESC LIMIT 10;"
Look at the query column. Common offenders:
A SELECT … WHERE … IN (long list) — usually from an unoptimized panel-side filter
An UPDATE without an index on the WHERE clause
A migration in progress (alembic upgrade)
A VACUUM (FULL) someone kicked off without thinking
sudo -u postgres psql -d <db> -c "SELECT pg_cancel_backend(<pid>);"# if cancel doesn't work after 30s:sudo -u postgres psql -d <db> -c "SELECT pg_terminate_backend(<pid>);"
If the query is a migration: don't kill it unless you're absolutely sure. Killing a migration mid-write can leave the schema inconsistent. Wait it out.
Add an index for the missing WHERE-clause column. Use CREATE INDEX CONCURRENTLY to avoid lock.
If the query came from panel UI, file a GitHub issue with the slow query + the panel page that triggered it. We'll add a query-plan budget to that endpoint.
Consider connection-level statement_timeout — set a sensible default (say 30s for read APIs):
SQL
ALTER ROLE app_user SET statement_timeout = '30s';
This makes any query that exceeds 30s fail loudly instead of consuming resources silently.