Incident Overview
A PostgreSQL-backed internal service develops sustained request latency. Application workers remain available, but transactions that write data increasingly exceed their normal completion time.
The fictional incident is classified as SEV-2 because an important service is degraded without evidence of complete loss.The storage dashboard reports ample free capacity. A database view shows active sessions waiting more often than usual, while a host view reports elevated latency for the device carrying PostgreSQL data.
CPU utilisation is moderate, and the application deployment marker predates the degradation. The apparent conflict is deliberate: capacity is healthy, but responsiveness is not.Assume responders have approved read-only access and can collect evidence without exposing query text or customer data.
Any recovery change requires a separate human-approved procedure, a confirmed PostgreSQL version, verified permissions and an isolated validation environment.
Investigation Options
Review the available operational moves and select the best immediate action.
Correlate PostgreSQL wait categories with read-only device-latency evidence, preserve timestamps and escalate if the signals remain aligned.
Treat available filesystem capacity as proof that storage is healthy and investigate only application code.
Restart PostgreSQL immediately to clear waiting sessions.
Increase PostgreSQL connection limits immediately because more sessions are waiting.