Incident checklist

Incident checklist A first-response order for "the database layer is broken". The point is to classify quickly, because the four categories below have nothing to do with each other. 1. Classify the error Every error prorm raises extends PrormError, and the type guards tell you which family you are in without string-matching a message: That single distinction decides everything that follows: Family | Meaning | Where to look | --- | --- | --- | ConnectionError | Never reached the database | Connection failures | TimeoutError | Reached it; it did not answer in time | Slow query, or lock contention | UniqueConstraintError etc. | Reached it; it rejected the write | Application logic, or a bad backfill | ValidationError | Never left the process | Application logic | 2. Is it everything, or one query? If that succeeds, the database is reachable and the problem is a specific query, table or lock — not connectivity. If it fails, go to Connection failures. 3. Is the pool exhausted? A pool with no free connection produces timeouts that look like a slow database. Distinguish them: if queries are queuing but the database itself is idle, the pool is the bottleneck, not the engine. logPoolOperations prints each acquire and release, which is the fastest way to see a leak: connections acquired and never returned, usually a transaction that threw without a finally. 4. Turn on the SQL Or per query, so you do not drown in output: benchmark: true adds timings, logSlowQueries with slowQueryThreshold reports only the queries that exceed it. 5. Decide the remedy Transient and isRetryableError → let the retry policy handle it; consider raising retry.max. Connectivity → Connection failures. Just failed over → Failover. Started right after a deploy → Migration rollback. Started right after a credential change → Credential rotation. Related reading Error handling Logging Query optimization