Maybe you happen to visit your website or service and find that nothing loads. Maybe you’ve gotten some angry emails from viewers or customers. Maybe your monitoring system (if you’re forward-thinking enough to have one) has fired off a text message with a dire warning.

Your server is down. However you do learn about downtime, and no matter what you’re doing with your virtual private server (VPS), your priority is clear: Get it back online. ASAP.

Think of downtime like a fire—it can happen to the most careful of us, and sometimes it happens for completely unexpected reasons. Remember fire drills from your middle school days? Having a plan outlined ahead of time minimizes panic and gets the job done fast.

In the same vein, you can develop a plan of attack for VPS troubleshooting. The better prepared you are in advance, the faster you’ll get back online, minimizing downtime. Here are just over a half-dozen ways back online.

How long have you been ‘up’?

Whether you want to know exactly when your server crashed or want a brief look into your system load for potential CPU overloading, uptime is a great place to start.

$ uptime
 14:35:45 up 1 day, 18:41,  1 user,  load average: 0.04, 0.03, 0.05

The command’s output lets you know the system’s current time, how long it has been running, how many users are currently online, and what’s called the system load. The three numbers are load for the previous minute, 5 minutes, and 15 minutes, respectively. The higher these load averages are to 1, the more likely some process is overloading the CPU.

Get the full (his)story

If you want to see a raw, chronological list of which commands have been run most recently, use history. Sometimes, by examining what we’ve done in the past, we can better understand why something might not be working now. Can you correlate downtime to a recent yum/apt update? Is there something unexpected there?