Log Files Show Status 500 Randomly

500 errors ruined my life for the better part of a year, so I can certainly understand the problem. I’m sure you have the same picture in your mind of annoyed visitors/customers each time one of these occurs.

My best success was with my web hosting company’s technical support folks. Typically, NOT by chat or telephone, but either e-mail or, preferably, if they have it, some sort of “trouble ticket” system where you can attach files and write info at length in an on-line web form. Hopefully, you won’t have to resort to Forums, as they are rarely watched by web host staff in a timely fashion.

Here is what I would look for: a cluster of these 500 errors all about the same time. It is more important that they be very recent, less than 24 hours ago, preferably in the last 8 or even 2 hours.

Cut and paste the errors out of the web logs, if you have access to them, including the time stamps. Attach as a file, if you can. Otherwise, cut and paste into the “report” you write them.

Specifically ask them if they can tell you what is wrong. Typically, they would look in the MySQL database error logs, which customers like you are usually not allowed to see, as it has info on other customers, too. They also have access to a log on the web server’s processor usage, which can help, too.

In my case, the web host company had installed proactive monitoring software that killed “everything in sight” whenever the web server processors got busy. That “kill” produced 500 Internal Server Error messages for my users.

The web host tech support is indeed excellent, but they could not help me because they could not reproduce the problem either.

I stubbed in some logging commands into the theme files. I confirmed the HTTP header output is being triggered by the theme’s header.php file, and the script is running normally through to the end of footer.php, even when the server is recording status 500.

Since I can’t reproduce the problem or find any other symptoms, I am really stumpped by this!

Hmmm. Sounds like my previous web host when the original founder and President left. They suddenly stopped researching problems. And started saying “it works now” or “I can’t replicate your problem”, and closing the trouble ticket in a kind of “too bad, so sad” response.

If you are showing them web log entries, they should be showing you database server and web server error log entries at the same time. Or at least looking for them.

I don’t know what else to say except maybe it’s time to find a new web hosting company.

But, before I did that, I would try and escalate your problem. Most web hosts have a QA or Customer Support Manager or some such listed on either their response to you, or their web site, under the area of “if you are not happy with our support…”

All this said, I am the first to admit that we don’t know FOR SURE that this is a web host problem. But “it doesn’t happen on my other domains” doesn’t tell us much if they are just HTML files, without php or MySQL.

At this point I’m hoping the Monday guys are better than the Sunday guys because I can’t think of any way to trap 500’s from inside of PHP.

If it is the web host killing a process that is generating the 500, you can’t trap anything. The kill blows it away with no questions asked. Very ugly.

I totally agree with your “wait for the weekday guys” approach. Even where I am now, I notice a difference whenever the owner is doing support. Even if it is the difference between Excellent and Stellar Support.

Going a step further, as long as you are polite about it, “the squeaky wheel gets the grease” is never more true than with Support. Persistence pays off, especially if you are willing to do your part, as you clearly are.

No luck with the techs today.

One thing did occur to me though: Hits on flat files are never showing status 500. It’s only showing 500 on WordPress pages, including sometimes the 404 pages are showing status 500.

Hits on flat files are never showing status 500.

At least two possibilities that I’m aware of if it is the kind of software I spoke of at work at your web host:

1. serving straight html (“flat files”) to a browser takes next to no processing power from the server side
2. the “killing” software typically targets php processes and ignores straight html processes

WordPress pages involve not just the execution of php code, but SQL to, and results from, the MySQL database server which the php must then wade through. In comparison to straight HTML files, many times the processor workload involved in a WordPress page.

My persistence got the issue escalated, and the level II guy said try turning off FastCGI. I turned off FastCGI and the problem went away instantly ??

I can’t offer any explanation, other than the server’s FastCGI became defective within the past 3 months, and the host will have to look into that. ??

Thanks for your ideas too, adiant.