What’s your first five-minute checklist when production goes down?

First, confirm that there’s a real customer impact and try to reproduce it from more than one location. Then check current alerts and monitoring, determine whether the failure is total or partial, and look for recent changes or deployments. From there I’d work through the application, network, infrastructure, and dependency layers while sending an initial status update and escalating if needed.

My rough order is: inspect the affected service and recent alerts, check whether the application is crash-looping, review application and system logs, and verify host health such as CPU, memory, and disk space. Storage exhaustion is a surprisingly common cause, so it should be monitored rather than discovered manually during an outage.

I usually start at both ends. From the front, test DNS, routing, and the customer-facing request. From the back, check databases and other data stores for connection-pool problems, blocked queries, or capacity issues. Those quick checks often identify whether the problem is at the edge or somewhere deeper in the stack.

The best five-minute checklist starts before the incident: customer-facing probes, API and dependency checks, service and container health, and infrastructure metrics should all have meaningful alerts. Each alert should explain likely causes and link to a runbook. During the outage, acknowledge the incident, start a shared coordination channel or bridge, assign someone to communicate, and use the alert evidence to guide the investigation instead of blindly opening dashboards.