How wp-cron Can Cause High CPU Usage and Slow Down WordPress

wp-cron is not a permanent daemon; WordPress usually checks if a scheduled event is running when it receives a request. If the job is heavy, delayed, or overloaded, it can involve PHP and the CPU during visiting. But any CPU is not upper than cron, and turning it off without a replacement stops important tasks.

Quick answer:First, find the hook name, timing, runtime, and abundance, and match the timestamp of CPU usage with cron and PHP log. Then fix the cause of the failed or long job, prevent overlap, and transfer the trigger to the controlled cron system if necessary.

What does wp-cron do?

Scheduled releases, clearing, update check, and many plugins use cron events. In WooCommerce, some jobs may go through Action Scheduler, which has its own table and runner. Deleting an event location can disable email, sync, backup, or order processing.

Signs of a Cron conflict

• CPU spike at a nearly constant time interval.
• slowdown's first visit after a low traffic period.
• A lot of calls.wp-cron.phpIn the access log
• Missed scheduled or delayed events at Site Health
• CLI or FPM PHP processes with long duration
• A large line of failed/pending jobs

These are hypothetical.The WordPress CPU usage guideRun it as well.

List of events with WP-CLI

wp cron event list
wp cron schedule list

These commands are read-only and must be executed at the correct root of the site and with the right user. Record the next_run, recurrence, and hook column. Argument information may be sensitive; clear before subscribing.

Why is Job backing down?

Low traffic, inactivity of the trigger, DNS/loopback, PHP timeout, fatal error, lock, long previous job or lack of worker can cause delays.PHP and debug.logRead the time.

Why is the co-op performed?

If the job duration is longer than the interval, the next trigger may occur while the previous one is still active. Inadequate locks, incorrect timeout, or multiple nodes also increase the likelihood of overlap. Each hook must behave idempotent and lock appropriately; this depends on the additional implementation.

How do we find a heavy job?

1. Record the CPU spike time.
2. See the process and access logs in the same space.
3. Extract a list of events and active runners.
4. Ascribe the hook name to the plugin or the owner's code.
5. Measure the duration, input and number of batch items in the staging.
6. Check for errors, retries and overlaps.

Just seeing a luxurious hook doesn't mean it's heavy. Measure the duration and cost of each run with plenty.

Trigger is transferred to System Cron.

For a portraits site, the internal trigger can be defined as passive and timed calls controllable, but only after verification that the external scheduler is actually running, monitored, and alerted.

define( 'DISABLE_WP_CRON', true );

Adding this constant without a replacement job will stop events. Command and interval system cron should be configured with your actual path, user, PHP and architecture; do not blindly copy a general sample to the production.

Batch and timing.

Import, email, and sync into small batches with checkpoints. Job should be continuous and safe in case of retry. Move heavy work to fewer hours, but don't delay time-sensitive jobs like inventory or payment without analysis.

Loopback and network.

The HTTP loopback method may fail with DNS, WAF, basic auth, or TLS. Disabling WAF or TLS verification to run cron is not a secure solution. Check destination, status, and response and define the target rule. In multiple nodes, a common trigger and lock need to be designed.

Don't know the Action Scheduler with wp-cron

wp-cron can trigger the runner, but the backlog and status jobs are managed in the Action Scheduler layer. Deleting a table or all pendings is at risk of losing work. Check failed hooks, claim, log and cause retry separately.

Runbook CPU crash caused by Cron

1. Record the process, time, and possible hook before restarting.
2. Identify the business impact of the job: pay, email or cash?
3. If necessary, only stop the trigger or specific, non-living job.
4. Do not delete the row and keep the status of the record running.
5. Reproduce the factor in the staging with the same input and adjust the batch/lock.
6. Run backward jobs gradually and monitored.

If the temporary shutdown is made, record the expiration time and be responsible for returning it. A temporary shutdown after the event can lead to more severe job accumulation a few days later.

Preventive monitoring is needed.

Monitor the number of pending/failed, oldest job, duration, retry, and overlap. Alerts on a single failure may be noisy; age, backlog trends, and the effect of a business path are better metrics. Follow these indicators closely after a particular deployment or sale.

Common Mistakes

• Definition of DISABLE_WP_CRON without replacement scheduler
• Manual execution of all events in production
• Remove the row to lower the number.
• Reducing interval without measuring duration
• Running cron with root or PHP path error
• Ignoring multiple nodes and overlapping

Approval of the amendment

CPU reduction should be accompanied by successful and timely execution of the job. Monitor lag, failure, duration and retry and smoke test email, timed release, backup and associated business operations.

When do you need special assistance?

If the hook has no specific owner, the queue is large or several runners are also filling the CPU cover, accidental deletion is dangerous.WordPress speed boost serviceIt can analyze events, PHP processes and server resources in a timeline.

Common Questions

Should we turn off wp-cron?

Only with a replacement scheduler and monitoring; otherwise the scheduled tasks will stop.

Does low traffic cause cron delays?

In the visit-based trigger model, it is possible; a real scheduler can make timing more predictable.

Why is an event held so many times?

Check for overlap, retry, inadequate lock or recurring event recording; removing all events is not detection.