Section 1 of 3 · 6 minutes
Define impact and scope
Your goal
What you will be able to do
State what users cannot do, when it began, and which service, database, role, and workload are affected.
Why this matters at work
The practical reason
A precise symptom prevents the investigation expanding into unrelated systems and metrics.
Learn
The idea in plain English
Start with the user-visible failure: connection errors, slow checkout, blocked writes, stale reads, or failed recovery. Record the first known time and important recent changes.
Confirm the exact PostgreSQL service and connection context. Compare one affected request with one working request when possible. Keep facts separate from possible causes.
Remember these points
- Describe user impact before naming a cause.
- Record service identity and a clear time window.
- Separate confirmed facts from hypotheses.
See it in SQL
Capture a service snapshot
Record connection context and current session counts at the start of an incident.
SELECT
clock_timestamp() AS captured_at,
current_database() AS database_name,
count(*) AS total_sessions,
count(*) FILTER (WHERE state = 'active') AS active_sessions,
count(*) FILTER (WHERE wait_event IS NOT NULL) AS waiting_sessions
FROM pg_stat_activity;This small snapshot anchors later comparisons. It does not prove a cause, but it describes the service at a known time.
Add application latency and error evidence from the same interval before deciding the database is the source.
A timestamped service snapshot with database name and total, active, and waiting session counts.
Useful words
Important terms
- Incident scope
- The users, services, operations, and time window affected by a failure.
Quick check · Not graded
Check your understanding
What should the first incident statement describe?
Your progress is saved to your signed-in account.