What are 500 errors?

HTTP Response Status Code

The HTTP Response Status Code that a server might give come from a list of standard codes – just search for “http response status codes” and you will find a list. Most servers won’t implement some of the more unusual status codes. For example, a correct response to the request to brew coffee could be “418 I’m a teapot” – IT humour… almost as good as dad jokes. However, there are a bunch that are used frequently – “404 Not Found” being the most frequently, erm, found.

They are split into 5 bands.

If the HTTP response status code is 100-199 then this is an informational status code that tells the browser that the request is in progress. If it is 200-299 means that everything went to plan. 300-399 means that extra steps are needed to complete the request – for example, a redirect.

You are unlikely to really see these (unless you are looking for them) ones.

400-499 HTTP response status code mean that the client (you) asked for something in a way that was invalid. The classic instance of 404 – you asked for a resource that doesn’t exist – either a file or directory… or a record in a database.

Then there are the HTTP response status codes 500-500… this means that the client (browser) asked for something in a way that was perfectly fine. However, something, somewhere on the server (or servers) is not happy. This could be any number of things…

An analogy you say?

Alright… you asked for it. Let’s do the usual thing of comparing with a car.

1xx – you put the car in the ignition. Most modern cars will be doing things even before you turn the key, checking the key is valid and disabling the immobiliser.

2xx – you turn the key and the engine starts. Everything is perfectly okay.

3xx – before you go too far, fill up with diesel.

4xx – you tried to move without releasing the hand brake. Bong-bong-bong-bong.

5xx – as you drive down the road, one of a number of sensors detects a problem and stops the car (or puts the check engine light on). There’s nothing else for it, you’ll have to take it to the garage again.

Most modern cars (I say modern but anything with a microchip under the bonnet is modern to me!) will log the fault. The garage will be able to read the fault, identify the problem, fix it and all will be well. Older cars didn’t have this – they were fine until they went bang.

It is no different with a web server. Somewhere the fault will be logged, someone will be able to read the fault, identify the problem, fix it and all will be well. 

Logged and Monitored

We use many different sorts of logging mechanisms but most write a simple text string to a file and to a central server. These are normally date/time stamped and include some details. This can help the developer to see where the problem is… sometimes down to the line of code that didn’t handle the situation correctly… and when.

Our logging systems are monitored continuously but a challenge presents here. There will be a general chatter of 500 HTTP response status codes (mainly due to script kiddies trying to hack your website) but an increase needs to be handled… especially in a checkout flow. We’ll get alerts for unusual increases.

Common Reasons

There are almost as many reasons as there are numbers as to why a 500 HTTP response status code can occur but some common reasons include:

• Configuration problems can happen – perhaps an out of place & in an email address or an incorrect setting for a database. These happen typically on start up of the application – we get alerts about these almost instantly and as we know what just happened we know where to look.
• Security – we lock down various bits of your website’s directory structure so that they can only be changed in permitted ways – for example, only the uploads folder might be writable. We have scripts that we have developed over the years to ensure this is setup correctly.
• Third party systems – sometimes it might be that a third party system is unavailable… this could be a weather API or a payment system provider. We handle these situations in different ways – for example, the weather API being unavailable isn’t a problem for a while so we might cache the last result and re-use that if we cannot get live data. If we detect a problem with a payment system provider we will disable that integration temporarily.
• Our code – sometimes we divide by zero. We shouldn’t and we do try not to. Our internal testing catches most of them and our internal QA websites will allow catch the rest of these issues and your CAT websites will allow you to check our work too. If the instances of these creep up then I can assure you that we know about them.

Conclusion

If you see a “500 Internal Server Error” there might not be much you can do about it, inform your provider and they will help resolve it. They probably already know about it.