If the site slows at the same time most days, look for a backup running inside WordPress. Move backups to the quiet hours, run them from the server, and keep copies somewhere other than that server.

Slow at the same time most afternoons

Staff at a garden centre notice a pattern. At about half past two most afternoons the website crawls for twenty minutes, the admin screens time out, and then everything is fine again.

The host checks the server and sees nothing wrong overall. By the time anyone looks closely the slow spell has passed, and the next day it returns at almost the same time.

A problem that keeps a schedule is usually a scheduled job. Something on the site starts at that time, and the most common culprit is a backup.

A job that waits for a visitor

WordPress has its own scheduler for tasks such as publishing scheduled posts, checking for updates and running backups. Each task has a time, but nothing runs between page views.

Instead, WordPress checks the schedule whenever someone loads a page. The first visit after a task's time starts the task, and on some setups that visitor waits for it too.

Backup tools inside WordPress often count a daily schedule from the moment they were set up. One installed at half past two in the afternoon runs at half past two, every day.

What the backup does while customers wait

A full backup run from inside the site does all of this in the same account that serves the pages:

On shared hosting, each account usually has limits on processor time, memory and disk activity. The backup uses them up, and every page request queues behind it until it finishes.

Finding the scheduled jobs

Start with the time. Note when the slow spell begins over a few days, then look in any backup tool's settings for a schedule that matches.

The server's access logs show a request to a file called wp-cron.php at the start of each scheduled job. The host can find it and match it to the slow spells.

Look beyond backups too. Image compression, broken link checks, sitemap rebuilds and visit reports can run on the same scheduler, and each takes its share.

Moving the work to the quiet hours

Backups belong in the hours nobody is shopping, which for most local businesses means the middle of the night. Moving the schedule is not enough on its own, though.

A task set for three in the morning still waits for a visitor. On a quiet site, that may be the first customer at opening time, who meets the backup instead.

The fix is to switch off the visitor-triggered scheduler in WordPress's configuration file and have the server start it on a timer instead, every fifteen minutes or so.

Let the server make the copies

Better still, take full backups out of WordPress altogether. The host's own backup system works at the server level, with tools built for copying files and databases, and needs no visitor.

Ask the host what it already backs up, how often, how many days it keeps, and how a restore is requested. Many shared plans include nightly backups the owner has never heard of.

Copies kept somewhere else

A backup stored on the same server is lost with the server. A disk failure, a suspended account or an intruder who deletes files takes the site and its backups together.

Archives left in a folder inside the website are worse: whoever guesses the file's name can fetch the whole site, database and customer details included.

Keep copies at a second location run by a different company, keep several days of them, and clear old archives out of the web folder.

A worked example

A slide scanning service in a suburban plaza turns slides, negatives and prints into digital files for families and a few photographers, and takes orders through its WordPress site.

Every weekday at about one o'clock the site slowed badly, just when customers placed orders over lunch. The owner assumed the host was overloaded at that hour.

The site holds a gallery of several thousand sample scans. A backup tool, installed at one in the afternoon on launch day, compressed all of them daily and stored the archives inside the site.

Sixty days of archives had filled most of the disk allowance, and anyone who knew the folder's name could have downloaded them.

The tool's schedule was removed and the old archives deleted. The host's nightly backup now covers the site, a second copy goes each night to storage elsewhere, and the scheduler runs from the server.

The heavy work now happens at night, outside the hours customers order, and the copies would survive the loss of the account.

A restore is the real test

Until a copy has been restored somewhere, nobody knows it works. Archives can be incomplete, missing the database, or too large to download when they are needed.

Once a season, restore the latest copy to a test address and click through it. That is the only way to know the copies are worth keeping.

The counter-case

Some sites are so small that a backup finishes in seconds, and nobody notices when it runs. For them, where the copies go matters more than when.

And some low-cost plans allow no server timers and include no backups, which leaves a backup inside WordPress as the only option.

There, set it for the quietest hour, send each copy off the server, and ask whether a plan that cannot back itself up suits a business site at all.

A backup routine that stays out of the way

  1. Note the time the site slows, over several days.
  2. Check the backup tool's schedule inside WordPress.
  3. Ask the host what it backs up, how often and for how long.
  4. Move full backups to the quiet hours, run by the server.
  5. Replace the visitor-triggered scheduler with a server timer.
  6. Keep copies at a second location, out of the web folder.
  7. Restore a copy to a test address once a season.

Step seven gets skipped more than any other. Moving the backup fixes the slow afternoons; restoring a copy is the only proof the backups would save the business on a bad day.

What a WordPress site shows when its database stops answering, and why the database belongs in every backup, is covered in the database connection error on a WordPress site.


Frequently asked questions

Why does my site slow down at the same time every day?

Usually a scheduled job, most often a backup, starts at that time. WordPress runs it when the first visitor arrives after its scheduled time, on the same account.

Why does a daily backup run in the afternoon?

Backup tools inside WordPress often count a daily schedule from the moment they were set up. One installed in the afternoon keeps running in the afternoon.

Is moving the schedule to the night enough?

Not on its own. WordPress still waits for a visitor, so a quiet site may run the job at opening time. A timer on the server fixes that.

Who should run the backups?

The server, through the host's own backup system, at night. Ask the host what it backs up, how often, how long it keeps copies and how to restore.

Why keep backups somewhere else?

A backup on the same server disappears with it. Copies left inside the website folder can also be fetched by whoever guesses their name.

How do I know the backups work?

Restore one to a test address every season and click through the site. Until a copy has been restored somewhere, nobody can say it works.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Site slow at the same hour every day?

Tell us roughly when it happens and your site's address, and we will look for the job behind it.

Start a Conversation