Incident Overview
A PostgreSQL service supporting an internal order-processing application has become intermittently slow. The fictional impact is classified as SEV-2 because writes remain available, but response times exceed the service objective and a growing request queue threatens wider degradation.The platform dashboard reports that the database volume has 62% free capacity.
PostgreSQL sessions are accumulating in wait states associated by the scenario with storage reads, while CPU utilisation remains below its normal busy-period range. Application workers retry timed-out requests, increasing concurrency.
A recent storage maintenance window is recorded, but the exercise provides no verified change record or product version. Treat that timing as a lead, not proof of causation.Assumptions: monitoring clocks are aligned; the displayed capacity belongs to the database volume; the environment permits read-only inspection; and responders lack authority to alter storage or PostgreSQL settings during initial triage.
Stop if any assumption is false.
Investigation Options
Review the available operational moves and select the best immediate action.
Collect read-only PostgreSQL wait evidence and storage-layer latency evidence over the same bounded interval, while preventing further retry amplification through the existing incident process.
Increase PostgreSQL connection capacity immediately because more sessions should drain the queue.
Restart PostgreSQL immediately to clear waiting sessions.
Declare storage healthy from free capacity alone and investigate application code exclusively.