4 Steps to Troubleshooting Website Issues with Technicians

Here’s a scenario that every systems administrator is familiar with: it’s Friday and everything is going swell, when all of a sudden you get a phone call: “Johnny, there’s a problem with the company website and we don’t know what’s wrong. Please help! Here’s a screenshot:”

Depending on who you ask, you’ll probably get different answers for why this is happening. The network administrator, IT Help Desk, System Administrator, and the software developer will all have different ideas about what you should do to fix this problem. Is that a problem? Yes. The user needs to be able to access the site now, not when you’re done interviewing the tech people. So what should you do? Who should you listen to? The answer: all of them.

You shouldn’t try to speak to them all at the same time, of course. These different techs play a very important role in different areas of technology, and nothing makes one better than the other. We all need each other. Sometimes we forget it, but we shouldn’t.

So back to our problem. Who should we listen to first? Answer: the IT Help Desk. This guy will probably tell you that the computer might not be hooked up to the network. Maybe the cable is disconnected, or maybe it can’t reach the wireless connection. And he’s right; most of the time that’s the issue. The physical components are what we should check first before anything else. But that’s not always the case…

Next? The Network Administrator. This guy will probably tell you that there’s something wrong with the communication. Can you ping 8.8.8.8? Can you ping the gateway server? How about the other subnet? Can you ping the host you are trying to get to? These are only a few of the steps he will ask you to try. But what if it’s not the communication?

Next up is the System Administrator. Besides probably being the most handsome, this guy will have more ideas. He might tell you there might be a problem with the application serving the website. He’ll have you log into the web server and check the services. Is the service turned on? Are there any errors in the system event log? When was the last boot time? Is the web server able to talk to other servers? Are there any other websites not working on the server? Is the website binding or virtual host correct? Are the DNS settings correct? Is the web server listening on the right port?

If none of these approaches resolves the issue, we finally move on to the Developer. If we know all else is working, the local PC is fine, networking looks cool, and the server is working properly, then there might be a problem with the actual site. The developer will have you check a few things on the website. Create a test page. Check the application logs for errors. Check the web.config settings. Try a different page. Compare the website files to a prior version. Turn debugging mode on the website to show errors. Check the database connection. By ruling out all of the other possibilities, he’ll be able to figure out exactly what the issue is and what needs to be done to resolve it.

The steps I've detailed here aren't meant to be a technical way of troubleshooting specific errors. That’s what Google is for. Instead, I want to emphasize that there are many different paths to take to find the resolution to a problem or issue. But it is best to start with the simplest method and troubleshoot from there, which will save both you and your technical partners a lot of headaches in the long run.