Menu Search
Jump to the content X

What To Do When Your Website Goes Down


Have you ever heard a colleague answer the phone like this: “Good afterno… Yes… What? Completely?… When did it go down?… Really, that long?… We’ll look into it right away… Yes, I understand… Of course… Okay, speak to you soon… Bye.” The call may have been followed by some cheesy ’80s rock ballad coming from the speaker phone, interrupted by “Thank you for holding. You are now caller number 126 in the queue.” That’s your boss calling the hosting company’s 24 hour “technical support” line.

An important website has gone down, and sooner or later, heads will turn to the Web development corner of the office, where you are sitting quietly, minding your own business, regretting that you ever mentioned “Linux” on your CV. You need to take action. Your company needs you. Your client needs you. Here’s what to do.

1. Check That It Has Actually Gone Down Link

Don’t take your client’s word for it. Visit the website yourself, and press Shift + Refresh to make sure you’re not seeing a cached version (hold down Shift while reloading or refreshing the page). If the website displays fine, then the problem is probably related to your client’s computer or broadband connection.

If it fails, then visit a robust website, such as or If they fail too, then there is at least an issue with your own broadband connection (or your broadband company’s DNS servers). Chances are that you and your client are located in the same building and the whole building has lost connectivity, or perhaps you have the same broadband company and its engineers have taken the day off. You will need to check the website on your mobile phone or phone a friend. To be doubly sure, ask your friend to check Where’s It Up?1 or Down for Everyone or Just Me?2, which will confirm whether your website is down just for you or for everyone.

If the website is definitely down, then frown confusedly and keep reading. A soft yet audible sigh would also be appropriate. You might want to locate the documents or emails that your Internet hosting service3 sent you when you first signed up with it. It should have useful details such as your IP address, control panel location, log-in details and admin and root passwords; these will come in handy.

2. Figure Out What Has Gone Down Link

A website can appear to have gone down mainly for one of the following reasons:

  • A programming error on the website,
  • A DNS problem, or an expired domain,
  • A networking problem,
  • Something on the server has crashed,
  • The whole server has crashed.

To see whether it’s a programming error, visit the website and check the status bar at the bottom of your browser. If it says “Done” or “Loaded,” rather than “Waiting…” or “Connecting…,” then the server and its software are performing correctly, but there is a programming error or misconfiguration. Check the Apache error log for clues.

Otherwise, you’ll need to run some commands to determine the cause. On a Mac with OS X or above, go to Applications → Utilities and run Terminal. On a PC with Windows, go to Start → All Programs → Accessories and choose “Command Prompt.” If you use Linux, you probably already know about the terminal; but just in case, on Ubuntu, it’s under Applications → Accessories.

The first command is ping, which sends a quick message to a server to check that it’s okay. Type the following, replacing the Web address with something meaningful to you, and press “Enter.” For all of the commands in this article, just type the stuff in the grey monospaced font. The preceding characters are the command prompt and are just there to let you know who and where you are.

C:> ping

If the server is alive and reachable, then the result will be something like this:

Reply from
bytes=32 time=12ms TTL=53

Ping command from a Windows computer
Ping command from a Windows computer.

On Windows, it will repeat four times, as above. On Linux and Mac, each line will start with 64 bytes from and it will repeat indefinitely, and you’ll need to press Control + C to stop it.

The four-part number in the example above is your server’s IP address. Every computer on the Internet has one. At this stage, you can double-check that it is the correct one. You’ll need to have a very good memory, or refer to the documentation that your hosting company sent you when you first signed up with it. (This article does not deal with the newish eight-part IPv6 addresses4.)

For instance, my broadband company is sneaky and tries to intercept all bad requests so that it can advertise to me when I misspell a domain name in the Web browser. In this case, the ping looks successful but the IP address is wrong:

64 bytes from
( icmp_seq=1 ttl=55 time=26.4 ms

Note that ping might also show the server name in front of the IP address ( in this case). Don’t worry too much if it doesn’t match the website you are pinging — a server can have many names. The IP address is more important.

Assuming you’ve typed the domain name correctly, a bad IP address indicates that the domain name could have expired or that somebody has made a mistake with its DNS settings. If you receive something like unknown host, then it’s definitely a domain name issue:

ping: unknown host

In this case, use a website such as Who.is5 to verify the domain registration details, or run the whois command from Linux or Mac. It will at least tell you when it expired, who owns it and where it is registered. The Linux and Mac commands host and nslookup are also useful for finding information about a domain. The nslookup command in particular has many different options6 for querying different aspects of a domain name:

paul@MyUbuntu:~$ whois
paul@MyUbuntu:~$ host
paul@MyUbuntu:~$ nslookup
paul@MyUbuntu:~$ nslookup -type=soa

If nothing happens when you ping, or you get something like request timed out, then you can deepen your frown and move on to step three.

What a non-responding server looks like in a Linux terminal
What a non-responding server looks like in a Linux terminal.

Alternatively, if your server replied with the correct IP address, then you can exhale in relief and move on to step five.

Note that there are plenty of websites such as Network-Tools.com7 that allow you to ping websites. However, using the command line will impress your colleagues more, and it is good practice for the methods in the rest of this article.

3. How Bad Is It? Link

If your ping command has timed out, then chances are your whole server has crashed, or the network has broken down between you and the server.

If you enjoy grabbing at straws, then there is a small chance that the server is still alive and has blocked the ping request for security reasons — namely, to prevent hackers from finding out it exists. So, you can still proceed to the next step after running the commands below, but don’t hold your breath.

To find out if it is a networking issue, use traceroute on Mac or Linux and tracert on a PC, or use the trace option on a website such as On Mac and Linux type:

paul@MyUbuntu:~$ traceroute

On Windows:

C:> tracert

Traceroute traces a route across the Internet from your computer to your server, pinging each bit of networking equipment that it finds along the way. It should take 8 to 20 steps (technically known as “hops”) and then time out or show a few asterisks (*). The number of steps depends on how far away the server is and where the network has broken down.

The first couple of steps happens in your office or building (indicated by IP addresses starting with 192.68 or 10). The next few belong to your broadband provider or a big telecommunications company (you should be able to tell by the long name in front of the IP address). The last few belong to your hosting company. If your server is alive and well, then the very last step would be your server responding happily and healthily.

Traceroute on a Mac
Traceroute on a Mac, through the broadband company and host to an unresponsive server.

Barring a major networking problem, like a city-wide power outage, traceroute will reach your hosting company. Now, you just need to determine whether only your server is ill or a whole rack or room has gone down.

You can’t tell this just from traceroute, but chances are the servers physically next to yours have similar IP addresses. So, you could vary the last number of your server’s IP address and check for any response. If your server’s IP address is, you could try:

C:> ping
C:> ping
C:> ping
C:> ping

If you discover that the server is in the middle of a range of 10 to 20 IP addresses that are all broken, then it could well indicate a wider networking issue deep within the air-conditioned, fireproof bunker that your server calls home. It is unlikely that the hosting company would leave so many IP addresses unused or that the addresses would have all crashed at the same time for different reasons. It is likely, though not definitive, that a whole rack or room has been disconnected or lost power… or burned down.

Alternatively, if nearby IP addresses do reply, then only your server is down. You can proceed to the next step anyway and hope that the cause is that your server is very secure and is blocking ping requests. Perhaps upgrade that deep frown to a pronounced grimace.

Otherwise, you’ll have to keep listening to Foreigner until your hosting company answers the phone. It is the only one that can fix the network and/or restart the server. But at least you now have someone else to blame. And if you are number 126 in the queue, it’s probably because 125 other companies think their websites have suddenly gone down, too.

4. Check Your Web Server Software Link

If the server is alive but just not serving up websites, then you can make one more check before logging onto the server. Just as your office computer has a lot of software for performing various tasks (Photoshop, Firefox, Mac Mail, Microsoft Excel, etc.), so does your server. Arguably its most important bit of software is the Web server, which is usually Apache on Linux servers and IIS on Windows servers. (From here on in, I will refer to it as “Web server software,” because “Web server” is sometimes used to refer — confusingly — to the entire server.)

When you visit a website, your Web browser communicates with the Web server software behind the scenes, sharing caching information, sending and receiving cookies, encrypting and decrypting, unzipping and generally managing your browsing experience.

You can bypass all of this and talk directly to the Web server software by using the telnet command, available on Windows, Linux and Mac. It will tell you conclusively whether your Web server software is alive. The command ends with the port, which is almost always 80:

ping@MyUbuntu:~$ telnet 80

If all were well, then your Web server software would respond with a couple of lines indicating that it is connected and then wait for you to tell it what to do. Type something like this, followed by two blank lines:

GET / HTTP/1.1

The first / tells it to get your home page; you could also say GET /products/index.html or something similar. The Host line tells it which website to return, because your server might hold many different websites. If your website were working, then your Web server software would reply with some headers (expiry, cookies, cache, content type, etc.) and then the HTML, like this:

Checking the web server software with telnet.

But because there is a problem, telnet will either not connect (indicating that your Web server software has crashed) or not respond (indicating that it is misconfigured). Either way, you’ll need to keep reading.

5. Logging Into Your Server Link

The remote investigations are now over, and it’s time to get up close and personal with your errant server.

First, check your server’s documentation to see whether the server has a control panel, such as Plesk or cPanel. If you’re lucky, it will still be working and will tell you what is wrong and offer to restart it for you (in Plesk, click Server → Service Management).

Restarting your Web server in Plesk
If your server has a control panel such as Plesk, try logging in to make sure the Web server is running.

If not, then the following commands apply to dedicated Linux servers. You could try them in shared hosting environments, but they probably won’t work. Windows servers are a different kettle of fish and won’t be addressed in this article.

To log in and run commands on the server, you will need the administrative user name and password and the root password, as provided by your host. For shared hosting environments, an FTP user name and password might work.

On Linux and Mac, the command to run is ssh, which stands for “secure shell” and which allows you to securely connect to and run commands on your server. You will need to add your administrative user name to the command after -l, which stands for “login”:

paul@MyUbuntu:~$ ssh -l admin

Windows doesn’t come with ssh, but you can easily download a Windows SSH client such as Putty8. Download putty.exe, save it somewhere and run it. Type your website as the host name and click “Open.” It will ask you who to log in as and then ask for your password.

Putty configuration
Using Putty to SSH from a Windows computer.

Once you have successfully logged in, you should see something like admin@server$, followed by a flashing or solid cursor. This is the Linux command line, very similar to the Terminal or command prompt used above, except now you are actually on the server; you are a virtual you, floating around in the hard drive of your troubled server.

If ssh didn’t even connect, then it might be blocked by a firewall or turned off on the server. If it said Permission denied, then you’ve probably mistyped the user name or password. If it immediately said Connection to closed, then you are trying to log in with a user name that is not allowed to run commands; make sure you’re logging in as the administrative user and not an FTP user.

6. Has It Run Out Of Space? Link

Your server has likely not run out of hard disk space, but I’m putting this first because it’s a fairly easy problem to deal with. The command is df, but you can add -h to show the results in megabytes and gigabytes. Type this on the command line:

admin@server$ df -h

The results will list each file system (i.e. hard drive or partition) and show the percentage of each that has been used.

Checking hard disk usage on a Linux server.

If any of them show 100% usage, then the command probably took eons to type, and you will need to free up some space fast.

Quick Fix Link

You should still be able to FTP to the server and remove massive files that way. A good place to start is the log files and any back-up directories you have.

You could also try running the find command to search for and remove huge files. This command finds files bigger than 10 MB and lets you scroll through the results one page at a time. You might need to run it as root to avoid a lot of permission denied messages (see below for how to do this). It might also take a long time to run.

root@server# find / -size +10000000c | more

You could also restrict the search to the full partition or to just your websites, if you know where they are:

root@server# find /var/www/vhosts/ -size +10000000c | more

If you want to know just how big those files are, you can add a formatting sequence to the command:

root@server# find /var/www/vhosts -size +10000000c -printf "%15s %pn"

When you’ve found an unnecessarily big file, you can remove it with rm:

root@server# rm /var/www/vhosts/

Permanent Fix Link

Clearing out back-ups, old websites and log files will free up a lot of space. You should also identify any scripts and programs that are creating large back-up files. You could ask your host for another hard drive.

7. Has It Run Out Of Memory? Link

Your server might just be running really, really slowly. The free command will let you know how much memory it is using. Add -m to show the results in megabytes.

admin@server$ free -m

The results will show how much of your memory is in use.

Checking memory usage on a Linux server
Checking memory usage on a Linux server.

The results above say that the server has 3550 MB, or 3.5 GB, of total memory. Linux likes to use as much as possible, so the 67 MB free is not a problem. Focus on the buffers/cache line instead. If most of this is used, then your server may have run out of workable memory, especially if the swap space (a bit of the hard drive that the server uses for extra memory) is full, too.

If your server has run out of memory, then the top command will identify which bit of software is being greedy.

admin@server$ top

Every few seconds, this gives a snapshot of which bits of software are running, which user started them and how much of your memory and CPU each is using. Unfortunately, this will run very slowly if memory is low. You can press “Q” or Control + C to exit the command.

The Linux top command shows what is running
The Linux top command shows what is running.

Each of the bits of software above is known as a “process.” Big pieces of software such as Apache and MySQL will often have a parent process with a lot of child processes and so could appear more than once in the list. In this benign example, a child process of the Apache Web server is currently the greediest software, using 7.6% of the CPU and 1.6% of the memory. The view will refresh every three seconds. Check the Mem column to see whether anything is consistently eating up a large portion of the memory.

Quick Fix Link

The quickest solution is to kill the memory hog. You will need to be root to do this (unless the process is owned by you — see below). First of all, though, search on Google to find out what exactly you are about to kill. If you kill a core program (such as the SSH server), you’ll be back to telephone support. If you kill your biggest client’s data amalgamation program, which has been running for four days and is just about to finish, then the client could get annoyed, despite your effort to sweeten it with “But your website is okay now!”

If the culprit is HTTPD or Apache or MySQLd, then skip to the next section, because those can be restarted more gracefully. In fact, most things can be restarted more gracefully, but this is a quick ignore-the-consequences type of fix.

Find the process ID in the PID column of the command above, and type kill -9, followed by the number. For example:

root@server# kill -9 23421

The -9 tells it to stop completely and absolutely. You can now run top again to see whether it has made a difference. If some other similar process has jumped to the memory-eating position instead, then you’ve probably only stopped a child process, and you will need to find the parent process that spawned all the greedy children in the first place, because stopping the parent will stop all the children, too. Use the process ID again in this command:

root@server# ps -o ppid,user,command 23421

This asks Linux to show you the parent process ID, user and command for the process number 23421. The results will look like this:

31701 apache   /usr/sbin/httpd

The PPID is the parent process ID. Now try killing this one:

root@server# kill -9 31701

Run top again. Hopefully, the memory usage has now returned to normal. If the parent process ID was 0, then some other process entirely is consuming memory, so run top again.

Permanent Fix Link

You will probably have to restart the offending software at some point because you may have just disabled your server’s SPAM filter or something else important. If the problem was with Apache or MySQL, you might have an errant bit of memory-eating programming somewhere, or Apache, MySQL or PHP might have non-optimal memory limits. There’s a slim chance that you have been hacked and that your server is slow because it’s sending out millions of emails. Sometimes, though, a server has reached capacity and simply needs more RAM to deal with the afternoon rush.

To find out what went wrong in the first place, check the web logs and/or the log files in /var/log/. When your hosting company has finally answered the phone, you can ask it to also take a look. Figuring out what happened is important because it could well happen again, especially if it’s a security issue. If the hosting company is not responsive or convincing enough, seek other help.

8. Has Something Crashed? Link

Most Linux servers use Apache for the Web server software and MySQL for the database. It is easy to see whether these are still running (and to restart them if they’re not) or are using up way too much memory. To see all processes running on your server right now, run this command:

admin@server$ ps aux | more

Scroll through the list and look for signs of apache (or its older name httpd) and mysqld (the “d” stands for daemon and is related to the way the programs are run). You are looking for something like this:

apache   29495  0.5  1.4 90972 53772 ?       S    14:00   0:02 /usr/sbin/httpd
apache   29683  0.3  1.4 88644 52420 ?       S    14:03   0:00 /usr/sbin/httpd
apache   29737  0.3  1.4 88640 52520 ?       S    14:04   0:00 /usr/sbin/httpd

Or you can use the grep command to filter results:

admin@server$ ps aux | grep http
admin@server$ ps aux | grep mysql

If either Apache or MySQL is not running, then this is the source of the problem.

This listing shows that Apache is indeed running
This listing shows that Apache is indeed running.

Quick Fix Link

If Apache or MySQL is not running, then you’ll need to run the commands below as root (see below). Linux usually has a set of scripts for stopping and starting its major bits of software. You first need to find these scripts. Use the ls command to check the couple of places where these scripts usually are:

root@server# ls /etc/init.d/

If the results include a lot of impressive-looking words like crond, httpd, mailman, mysqld and xinetd, then you’ve found the place. If not, try somewhere else:

root@server# ls /etc/rc.d/init.d/

Or use find to look for them:

root@server# find /etc -name mysqld

Once it is located, you can run a command to restart the software. Note that the scripts might have slightly different names, like apache, apache2 or mysql.

root@server# /etc/init.d/httpd restart
root@server# /etc/init.d/mysqld restart

Hopefully, it will say something like Stopping… Starting… Started. Your websites will start behaving normally again!

Permanent Fix Link

As above, check the log files, especially the Apache error logs. Sometimes these are all in one place, but usually each website on the server has its own error log. You could look through the ones that were busiest around the time of the crash. Or else you could have a misconfiguration or a programming bug or security breach, so it could well happen again until you identify and address the cause.

Becoming a Super-User Link

Most of the fixes above require special permissions. For example, you (i.e. the user you have logged in as) will be able to kill or restart processes only if you started them. This can happen on shared servers but is unlikely on dedicated servers, where you will see a lot of permission denied messages. So, to run those commands, you will need to become the server’s super-user, usually known as “root.” I’ve left this for last because it’s dangerous. You can do a lot of irreversible damage as root. Please don’t remove or restart anything unless you’re sure about it, and don’t leave your computer unattended.

There are two ways to run a command as root. You can prefix each command with sudo, or you can become root once and for all by typing su. Different servers place different restrictions on these commands, but one of them should work. The sudo command is more restrictive when it turns you into a lesser non-root super-user who is able to run some commands but not others. Both commands will ask for an extra password. For example:

admin@server$ sudo /etc/init.d/httpd restart

When you run su successfully, the prompt will change from a $ to a #, like this:

admin@server$ su

It might say admin@server or root@server. Either way, the # means that you are powerful and dangerous — and that you assume full liability for your actions.

Conclusion Link

This article has provided a few tips for recognizing and solving some of the most common causes of a website going down. The commands require some technical knowledge — or at least courage — but are hopefully not too daunting. However, they cover only a small subset of all the things that can go wrong with a website. You will have to rely on your hosting company if it is a networking issue, hardware malfunction or more complicated software problem.

Personally, I don’t mind the ’80s music that plays while I’m on hold with my hosting company. It’s better than complete silence or a marketing message. But it would be even better if the support rep picked up the phone within a few seconds and was ready to help. That is ultimately the difference between paying $40 per month for a dedicated server versus $400.

When the dust has settled, this might be a conversation worth having with your boss — the one still sitting glumly by the phone, eyeing your frown, and waiting for Bono to stop warbling.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9

↑ Back to top Tweet itShare on Facebook

Paul Tero is an experienced PHP programmer and server administrator. He developed the Stockashop ecommerce system in 2005 for Sensable Media. He now works part-time maintaining and developing Stockashop, and the rest of the time freelancing from a corner of his living room, and sleeping, eating, having fun, etc. He has also written numerous other open sourcish scripts and programs.

  1. 1

    Useful article… Thank you for taking the time to write it. I have bookmarked it for future reference.

    9 times out of 10, when my client’s sites go down, it’s an issue caused by their hosting provider, and yet they still automatically assume it’s my fault!

  2. 2

    Nice Article :D

  3. 3

    Very thorough. And bookmarked!

  4. 4

    I use Nagios from a remote server to ping my production servers every 90 sec. I have used one of the pinging services, but Nagios gives much more control. More importantly, I pay the premium for managed servers at Singlehop, so I get 24/7 surveillance; after 10 minutes they jump in and start diagnosing the issue. Peace of mind worth the cost.

    I would like to see an article on ways to create a mirror server with a some sort of failover or switchover. If the hard drive crashes, it could take hours to get all the software back (much of it must be installed and not just copied over from the backups) and all the data backups moved over.

    All I know is that everytime I get a ping error notification, my heart stopped. 99.9% of the the time it’s a temporary connection issue that goes away, but one never knows.

  5. 5

    Hehe thanks,

    You know the past few months things have happened on my website and changes had to be made. Everytime I check this website strangely enough everytime an article appears on subjects I actually need.

    What a coincidence :D

    I’ve been a visitor for almost a year now, and I want to thank you guys for these wonderful articles.


  6. 6

    Nice article, but I think that everyone that has only one site big enough already knows how to do all of the above, or more.

    It’s funny, there’s no SYNFLOOD or DDOS information, how to track such attacks, how to handle them and so on. That would be helpful!

  7. 7

    This is a very useful article for anyone who deals with or helps diagnose problems for clients. Anything you can do to help the account folks solve server problems is certainly appreciated, especially if the client’s income is being affected. Being able to check and see if a server is responding at all, and if it is being able to provide extra feedback when dealing with the host support can speed up restoration of service significantly. Thanks for this.

  8. 8

    I agree with Bogdan (sta ima) if you own dedicated server you better know all of that above, but I think it’s a good tutorial for web owners that are not that much into tech like Gawker :) . Leaving clear txt passwords on server, who does that?

    Anyway, regarding the $400 vs $40 I never pay more than $100 for dedicated server and my site gets over 600K pageviews. How?

    Use Cloud Computing… Amazon, Rackspace….

    Dedicated servers are just waist of money, why would I spend $800-$900 in my case, to have half managed server with some pretty console? I rather get book and learn about web servers and security than buying half managed dedicated servers on any host.

    On cloud you get same thing, and it’s 50% cheaper.

  9. 9

    I would add, “Check Twitter”. A lot of hosts nowadays have a feed which publishes the statuses of their servers. It could save you some trouble during the early stages at least.

  10. 10

    To be honest, this is one of the more useless articles I have read on Smashing. No offence Paul, because I understand where you were trying to go with this. I personally manage my own servers and I know firsthand that when a client’s site goes down it is one of the most terrifying experiences as a developer. But you missed the mark. There are just too many scenarios, end of story. Diving into the ethics of what to do, or possibly applying some business theories to this would have made for a better article.

  11. 11

    Awesome article – I really love when Smashing does “slightly” more nitty gritty articles like this one. Still have my fingers crossed for an article on best practices for automating your webserver deployment!

  12. 12

    You missed out a couple of incredibly important steps:

    1) Don’t Panic
    2) Ensure you have a towel on standby

  13. 13

    Great article, thanks. I will be trying out some of your suggestions.

    Since this type of thing has happened to me quite often I have my own quick checklist that you might want to add:

    1. See if all of your websites are down on that server or just the one.
    2. Check to see if your host’s website is down as well! (if it is you’re f*$%d)
    3. I think you mentioned it but see where/if you can login, ftp, ssh, web, etc.
    4. Don’t freak out too bad, especially on the support people at the hosting company.

    One of our hosts had a major outage where a fire marshal flipped the wrong switch during a test and sent a spray of water down on a roomful of active servers including mine. They were all destroyed. Luckily I pay for nightly backups but it was a nightmare getting everything up and running again.

    A couple of years ago it was a huge fire that burned up a roomful a servers including mine.
    If you have a website it will happen to you sooner or later so backup your sites locally.

    Mark Lewis
    Partners In Rhyme Inc

  14. 14

    I just usually cry and avoid the phone until it comes back ;)

  15. 15

    @James: nice one :-)

    THe last time I had a major issue was when the hosting supplier had a major power issue, and there was nothing I could do about it. Fortunately, I can RDC into my servers and do everything there, when I can’t get in then panic does set in. I’d second an article for mirror servers – I’d like to get mine to mirror each other.

  16. 16

    Rizqi Djamaluddin

    December 13, 2010 7:10 am

    I think this is a really good starting point (though perhaps a tad too technical, but that can’t hurt either). Even developers who never touch their client’s (maybe self-hosted) site should have some knowledge of troubleshooting websites that went down — if only “ah, it’s from your host, try calling them?”, it’s better than saying no outright.

    A suggestion for the author: Maybe more references in each scenario and stage could be useful, for those of us running different setups or when the first aid situations don’t help!

    Overall, still very useful and worth a read.

  17. 17

    Thanks for all the great comments – and I’m glad most people found the article useful. Coincidentally, one of the servers I maintain became unresponsive on Monday, and I logged in and ran “top” and found that MySQL was using all the memory. So although this article does only brush the surface of what can go wrong with a server, it will help in some cases. (Actually, not that much of a coincidence as I caused the problem in the first place – but not on purpose – and I was pleased to be able to take my own advice.) And although anybody who maintains a server should already know this stuff, I learned it through frantic research and practice with the phone ringing in the background. Sorry I forgot to mention towels.

  18. 18

    I don’t quite understand the point of this article. If it’s targeted at server administrators, they should be replaced instantly if they don’t know these basic tasks and tools. If it’s targeted at designers, developers and site maintainers who don’t have advanced server admin skills (like me), then usually your host whoever it is including shared hosting companies, have support departments who take over if it’s in fact down for everyone. I can’t imagine that too many people who are savvy enough to run their OWN server, don’t know these things, and companies should have an IT team or person in charge of this stuff.

  19. 19

    Looks like there isn’t even a mention of services like “Are My Sites Up?”, that email/text you within a few minutes of your site actually going down.

    So: Get a service (or make your own) to check on your sites regularly, so you can find out early when they’re down.

  20. 20

    Great post! It contains exactly everything I need to control my websites.

  21. 21

    Great article: I like the way it is written with a gentle sense of humor and it covers all the basics. It’s nice for people to have a clear plan of action to be able to follow.

  22. 22

    Houser – Don’t be a douche!

    If you bother to read the other comments, you can easily see that this article is indeed both useful and appreciated. Next time try to make suggestions that are intended to be constructive criticism from a fellow developer, instead of extolling your elevated thinking process as an arrogant elitist that is above such mundane topics. Basically, try to be helpful without having to show everyone how smart you are.

  23. 23

    I totally disagree on step 1’s hitting shift+F5 to get the uncached version of your site. If that is indeed the solution to your problem, then only YOU have solved the problem. Your USERS may still be getting the cached version. Don’t expect the average user to clear their cache when something goes wrong. They’d rather just assume your site is broken and leave.

    The correct way to serve uncached files is to version all your images, javascript, and CSS whenever releasing a new version of your site. For example: style_20101213.css and sprite_20101213.png. If you edit the CSS that manipulates your sprite PNG without versioning, your site will appear broken to your users. You may not realize it because during development, you’ve been constantly hitting F5 to refresh your cache. Don’t expect the average user to do the same. They usually get to your site through a bookmark or link, not through refreshing, and thus will get the cached version from their harddrive.

  24. 24
  25. 25

    Nice post now lots of people are anxious about the DDoS attacks regarding Wikileaks. :-) How current.
    It’s always great to have SSH access.
    (I prefer using dig instead of NSLookup)

  26. 26

    This article sends the wrong message.

    It should read:

    If you don’t know how to troubleshoot a webserver,
    you should get *managed* hosting.

  27. 27

    And of course, make sure you’re using our product, Are My Sites Up ( ) and you’ll know exactly when/if your site goes down, so you can hold your hosting company (or yourself) responsible! :)

  28. 28

    Great article, thanks for sharing this with us.

    Have one point though, I am not sure how genuine “Down for Everyone or Just Me?” is as I checked a perfectly fine website ( and their result was that it was “also” down for them. With off-course an advertisement that you should switch to their hosting partner.

  29. 29

    the site will get back up anyway, so why stress yourself?

  30. 30

    I think you missed something while “reading” this post. The author never said refreshing the cache was the solution. He was using it as a way to determine the problem. When troubleshooting, it is always important that you are seeing the current state of the issue. If you load the site and it looks correct, but the client says it’s down, you should most definitely refresh your cache to make sure the server is indeed serving up the site and you’re not just viewing the cached state.

    Once you have determined whether or not that is the problem, then you can address it as needed. (including versioning.)

    please read and understand the post before adding your ‘informed’ opinions.


↑ Back to top