I’ve seen this kind of issue quite frequently: sites are crashing around a regular interval and no one knows why. It’s a big mystery as to why—there’s no intense traffic spikes, nothing really happening that day out of the norm—but people just can’t access the site one day during the afternoon.
Let’s take a look at the problem: first we’re going to start with logs—tailing all of them:
tail -f /var/log/php8.2-fpm.logtail -f /var/log/nginx/error.logtail -f wp-content/debug.log
..all the logs (there are more, you’ll have to go find them), especially around that time of day. Yeah, ssh right into the server around that time. What are we looking for? Things like this:
[04-Oct-2025 16:00:03 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in /wp-content/plugins/some-plugin/includes/heavy-task.php on line 112
[04-Oct-2025 16:00:04 UTC] PHP Warning: Cannot modify header information – headers already sent in /wp-content/themes/my-theme/functions.php on line 203
[04-Oct-2025 16:00:04 UTC] PHP Notice: Trying to access array offset on value of type null in /wp-content/plugins/custom-dashboard-stats/stats.php on line 98
[04-Oct-2025 16:00:03] WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
[04-Oct-2025 16:00:05] ERROR: script timed out before returning headers: index.php
[04-Oct-2025 16:00:06] NOTICE: Terminating child process 10123 (request exceeded max_execution_time of 60s)
[04-Oct-2025 16:00:05 UTC] WordPress database error Lock wait timeout exceeded; try restarting transaction for query
UPDATE `wp_options` SET `option_value` = 'a:12345:{...}' WHERE `option_name` = '_transient_wc_session_abcd123'
made by do_action_ref_array('wp_scheduled_auto_draft_delete'), wp_delete_auto_drafts
[04-Oct-2025 16:00:03 UTC] PHP Notice: Action Scheduler queue is full (10,000 pending actions). Cannot spawn new job. in /wp-content/plugins/woocommerce/packages/action-scheduler/classes/ActionScheduler_QueueRunner.php on line 123
[04-Oct-2025 16:00:03 UTC] PHP Warning: ActionScheduler_QueueRunner->run() took 122.4 seconds for batch size 25 in /wp-content/plugins/woocommerce/packages/action-scheduler/classes/ActionScheduler_QueueRunner.php on line 210
2025/10/04 16:00:05 [error] 31220#31220: *754 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.100, server: example.com, request: "GET /dashboard HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"
2025/10/04 16:00:05 [crit] 31220#31220: *755 SSL_do_handshake() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while SSL handshaking, client: 192.168.1.101, server: 0.0.0.0:443
[04-Oct-2025 16:00:02 UTC] PHP Fatal error: Uncaught Exception: Out of memory while processing scheduled event 'backwpup_cron' in /wp-content/plugins/backwpup/inc/class-job.php:214
Stack trace:
#0 /wp-includes/class-wp-hook.php(308): BackWPup_Job->run()
#1 /wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
#2 /wp-includes/plugin.php(517): do_action_ref_array('backwpup_cron', Array)
#3 /wp-cron.php(138): do_action('backwpup_cron')
#4 {main} thrown in /wp-content/plugins/backwpup/inc/class-job.php on line 214
The logs give us clues as to what’s happening around this time. You might need to upgrade your server in some cases, tweak configuration settings (an expert can do that), but the usual suspect though: cron jobs!
Cross-reference the logs with any cron jobs that may be running, run wp cron event list and wp action-scheduler list on the sever to see if you notice any correlations with anything you are seeing in the logs (you can use WP Crontrol in WordPress for this too—just disable it when you’re done).
What I usually find is that long-running cron jobs are running around this time, or even multiple cron jobs are running! Things like backups, WooCommerce subscriptions, e-mail newsletter plugins, etc are all doing long-running activities on the server during that time. They aren’t running at random—they are scheduled by the plugins to run at a specific time.
If you built your website in a day and activated a bunch of plugins the same day, they likely scheduled tasks to run on repeat around that day.
So what are we going to do about it?
First, consider if you really need tools like backups running in WordPress. Hosting services usually have a backup process that can run in the background instead of when your site loads. Disable things like that and find alternatives that are outside of WordPress. The other option is re-scheduling cron jobs to run during low traffic times. For instance, if your e-mail newsletter plugins are sending emails on repeat each week around 4pm, have it send it at 11pm instead. You can use tools like WP Crontrol to modify them.
An expert coder, though, can make sure they stay that way by modifying the code through WordPress hooks!
You can also turn off WordPress cron jobs using define( 'DISABLE_WP_CRON', true );—this turns off CRON on page-load only—and instead have all cron jobs run during low-traffic times using system cron instead of in WordPress:
0 23 * * * curl -s https://mysite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
This way all cron jobs that are pending run at a specific time by the system—not WordPress! My biggest recommendation, though, is to spend time offloading hard tasks to another services: move your e-mail newsletter off WordPress, do backups through your hosting service, etc—you’ll get the best results out of doing that first!