Last Updated on October 12, 2023 by Christopher G Mendla
I had backups set to run at 3 am figuring that would be a time where there would be few users. That way, the impact on the server of the backup job would be minimal. I noticed that the sites would slow down when I worked on them at night.
Overview
I am on the east coast. Most of my sites are locality based. Looking at Google Analytics, there is very little traffic in the 2am-5am timeframe. Tasks such as backup jobs can be a little processor intensive. Therefore, I set the backup tasks to run in the early morning. Or at least I thought I did.
Indications of a problem.
I noticed that I was getting failures to save posts or open them around 10 or 11 pm. When I checked cpanel it would show the CPU maxing out. I also checked using the TOP command in a terminal window. That showed very high usage.
Checking the Google Analytics realtime visitors did not show any sudden increase in visitors. There was a possibility that it was an attempted Brute Force attack but I have things locked down pretty well to prevent that. Also, it was odd that the problem occurred at about the same time.
Timezones
Servers and computers use Coordinated Universal Time or UTC where the Greenwich Royal Observatory in the UK is used as the reference point. I am on the East Coast of the U.S. so my computers and servers are set to UTC – 5 meaning that I am five hours behind Greenwich time.
Troubleshooting
I use a shared hosting account for five sites. All of my backup jobs set to email me when they ran. After an analysis of when the emails were arriving and was able to deduce that two of the sites were sending the emails around 10 pm instead of 3 am as expected.
I installed a couple of WordPress Cron job checkers but that didn’t really give me a lot of information.
The wrong time zone was causing the issue
I checked the timezone settings in the WordPress settings-general page and found that two of the sites had the timezone set to UTC-0 meaning that the sites thought they were on Greenwich Mean Time.
In the example below, you can see that the timezone was set to UTC-0.
Fixing the time zone
Fixing the time zone was simple. I changed it to UTC-5 and saved the settings
BUT – BE CAREFUL. These sites are simple blogs with low traffic. There is no e-commerce on the sites. They are not time critical as they would be in the case of a site with real estate transactions. Changing the time by five hours had a minimal impact. BACK UP YOUR SITE BEFORE CHANGING ANYTHING.
Summary
In my case, changing the timezone was simple and had a minimal impact. It fixed the issue with the backups running at the wrong time. I was fortunate in that there were no complicating factors such as ecommerce.
Note that this example was in reference to a WordPress site but the same problem can occur with other platforms such as Ruby on Rails, Joomla, Drupal and other platforms.