Server Down at 3 AM: A Triage Checklist Before You Call Support

A server outage at 3 a.m. produces two problems at once: the actual technical failure, and the adrenaline that makes it hard to think clearly about what to check first. The difference between a 15 minute outage and a 2 hour outage is often not technical skill, it is whether the first few minutes were spent triaging in order or jumping randomly between symptoms.

This is a fixed order to work through before you call support, so the call itself starts with useful information instead of "it's down, I don't know why."

Step 1: confirm it is actually down, and for whom

Before anything else, confirm the outage is real and understand its scope. A single failed monitoring check can be a false alarm from a transient network blip.

• Load the site or application from a connection that is not on your own network, using a phone on mobile data or an online uptime checker, since a local DNS or network issue can make a healthy server look down only to you.
• Check whether the failure is total, such as connection refused or timeout, or partial, such as a slow response or an error page. These point to different causes.
• Check whether it affects one service, such as the website, or everything on the server, including SSH access. This single fact narrows the cause enormously.

Step 2: try to get in

Attempt SSH or your control panel login before assuming the whole server is unreachable.

• If SSH works but the website does not, the operating system is fine and the problem is in a specific service: the web server, PHP, the database, or the application itself.
• If SSH times out or refuses the connection entirely, the problem is more likely network level, a firewall change, or the server being genuinely unresponsive, which is a more serious category.
• If you can reach a hosting provider's own console or KVM even when SSH fails, use it. Seeing the actual boot and console output is worth more than ten minutes of guessing blind.

Step 3: check the obvious, fast-moving causes first

These four causes account for a large share of unplanned outages, and each takes under a minute to check.

• Disk space. df -h. A full disk stops databases, mail queues and logging cold, and is one of the single most common causes of a sudden, total outage.
• Load and memory. uptime and free -h. A load average far above the core count, or memory fully consumed with heavy swap activity, points to a resource exhaustion event rather than a configuration change.
• Recent changes. Did a deployment, plugin update, cron job or scheduled maintenance run in the last hour. Correlating the outage time with a recent change is often the fastest path to a cause.
• Service status. systemctl status for the web server, database and PHP-FPM. A crashed service that failed to restart is common after a memory spike killed a process.

Step 4: check the logs that actually explain what happened

Once the fast checks narrow the category, the relevant log confirms the specific cause rather than the symptom.

• Web server error log, typically under /var/log/nginx/ or /var/log/httpd/, for 502 or 503 errors pointing to an unreachable backend.
• Database error log for crashed tables, connection limit errors or an unexpected shutdown.
• dmesg and the kernel log for out-of-memory killer events, which show up as a process being killed without any application-level error at all.
• System journal, journalctl -xe, for a service that failed to start and the specific reason it gave.

Step 5: do not restart everything as a first move

Restarting a service or rebooting the server can resolve a stuck process, but it also destroys the evidence needed to prevent the same outage next week. If the situation allows even two extra minutes, capture the output of the checks above before restarting anything. If the outage is actively costing revenue or reputation by the second, restoring service takes priority over diagnosis, but note what you observed first in a text file or message to yourself so it is not lost once services come back.

What to have ready when you call for help

A support engineer, whether internal or an outsourced provider, resolves an outage faster with specific information than with "the server is down." Have ready:

• What you already checked, from the steps above, and what each one showed.
• The exact error message or error code, not a paraphrase of it.
• What changed recently, even something that seems unrelated, such as a plugin update, a DNS change, or a traffic spike from a marketing email.
• Whether the server is reachable at all, since that determines whether the engineer needs console access or can start over SSH immediately.

This alone often cuts real diagnosis time significantly, because the engineer starts at the actual problem area instead of repeating the same first five checks you already ran.

After the outage: the step most teams skip

Once service is restored, the incident is not actually finished. A short written note covering what failed, what the actual root cause was, and what would prevent it recurring turns a stressful night into a permanent fix. Without that step, the same failure mode often returns in a few weeks, at another inconvenient hour.

iServerSupport provides emergency server support for exactly this situation: a live engineer to diagnose and resolve an active outage, and to do the root cause work afterward so the same failure does not happen again at 3 a.m. next month.