Incident Overview
A PostgreSQL-backed service has slower requests. One alert reports high database transaction latency, while a separate storage monitor reports normal device latency and no capacity threshold breach.
The database host is reachable, and application health checks still succeed intermittently. An automated message labels the event a storage degradation, but its classification is not itself proof of a storage fault.The immediate objective is to preserve service, identify where time is being spent and avoid an unnecessary storage change.
Treat the fictional impact as SEV-2 because users are affected but some requests still complete. Escalate immediately if availability declines, data-integrity indicators appear, access exceeds the authorised scope or evidence cannot be collected safely.
Investigation Options
Review the available operational moves and select the best immediate action.
Collect read-only PostgreSQL activity and wait evidence, then compare it with storage and application timing.
Escalate immediately without collecting any additional evidence.
Restart PostgreSQL to clear the slow sessions.
Provision more storage because the alert names storage degradation.