API latency spike: a no-panic investigation
Separate network, queueing, application, dependency, and database time; averages conceal the tail that users feel.
Application cannot reach the database: trace the whole path
Test name resolution, network, TLS, authentication, pool saturation, and database health as separate hypotheses.
The deploy broke production: rollback first or debug first?
When evidence strongly ties the outage to a reversible deploy, restore service first and preserve logs for the later explanation.
DNS change went wrong: TTLs, caches, and split answers
Compare authoritative and recursive answers with TTLs; do not keep editing records while the first change is still propagating.
Docker Compose outage: dependency order is not readiness
During a multi-container stack that starts but does not work, the first danger is the outage.
High I/O wait: find the disk queue behind the slowdown
Correlate device latency and queue depth with the process issuing I/O; CPU graphs alone make this incident look mysterious.
Load balancer says unhealthy while the app looks fine
Validate bind address, path, host header, protocol, status code, timeout, and firewall from the load balancer's perspective.
No space left on device: disk blocks, inodes, and deleted files
During failed writes despite confusing disk reports, the first danger is the outage.
The OOM killer terminated your app: what to inspect next
Identify the killed cgroup, memory growth, limits, and swap behavior before merely restarting with more RAM.
Address already in use: find the owner without killing the wrong service
Identify process ownership and supervisor state; random kill -9 commands often create duplicate restart loops.
Postgres lock incident: find the blocker, not just the blocked
Trace the blocking transaction and its owner; terminating every waiting query treats victims as the cause.
Redis latency incident: slow commands, forks, and network stalls
Distinguish command complexity, blocked clients, persistence forks, swapping, and network latency before flushing anything.
Locked out of SSH: recovery paths before desperation
Use the provider console to distinguish firewall, daemon, disk, user, and key failures; restore a narrow safe path before hardening again.
Expired TLS certificate incident: restore trust without creating a second outage
Confirm which terminator serves the certificate, renew there, reload safely, and validate the full chain from outside.
Website down: the first 15 minutes of production triage
Prove DNS, TLS, routing, proxy, application, and database layers in that order before changing anything.