PostgreSQL · Database incident triage
PostgreSQL Incident Triage Checklist
A bounded first-response checklist for collecting PostgreSQL availability, saturation, blocking and replication evidence before intervention.
How to use this template
1
Record timestamps and the exact endpoint before querying.
2
Prefer read-only evidence collection during initial triage.
3
Do not terminate sessions or change settings without an identified owner and rollback.
Copyable template
# PostgreSQL incident triage ## Scope and safety - [ ] Incident start time, affected service and database endpoint recorded - [ ] Current writer/read-replica roles confirmed - [ ] Recent deployments, failovers and maintenance events checked - [ ] Evidence owner and intervention approver identified ## Availability - [ ] Fresh connection tested separately from existing pools - [ ] Server process and listener health confirmed - [ ] Database logs captured for the incident window - [ ] Client, pooler and proxy errors correlated by timestamp ## Capacity and sessions - [ ] Sessions counted by state, application and source - [ ] Connection usage compared with configured and reserved capacity - [ ] Long-running and idle-in-transaction sessions identified - [ ] CPU, memory, disk latency and storage capacity reviewed ## Concurrency - [ ] Waiting sessions and blocking process IDs captured - [ ] Oldest transactions and lock types identified - [ ] Deadlock details retained from server logs - [ ] Any cancellation target tied to a known workload and transaction ## Replication and durability - [ ] Replication state, lag and slot retention checked - [ ] WAL filesystem growth and archive failures checked - [ ] Recovery objective and last successful restore evidence available - [ ] Transaction outcome uncertainty documented before retries
Related KBY resources
Engineering signal
Follow PostgreSQL failures and fixes
One useful weekly email with new error references, tools, integration notes and production lessons. No daily noise.