WORDPRESS
WordPress Site Health Says a Scheduled Event Has Failed
Site Health reports A scheduled event has failed? Identify the WP-Cron hook, isolate loopback and callback faults, and verify affected tasks safely.
WordPress Site Health’s “A scheduled event has failed” notice is a signal to inspect a named WP-Cron event. It is not, by itself, a PHP exception report or proof that the whole scheduler is broken. Record the event’s hook, determine whether other events are late, and check what the affected feature actually did.
The distinction matters on WooCommerce sites: a delayed WP-Cron trigger can affect Action Scheduler, but Site Health is not displaying the status of every individual queued action. Do not clear failed actions or run every due event simply to remove a dashboard warning.
Interpret the Site Health scheduling warning
Applies when: Site Health reports that a named scheduled event has failed.
Quick answer
The warning identifies missed scheduling evidence, not a complete callback execution trace. Capture the hook and compare other events before choosing a repair.
What to do
-
Distinguish failed, late, and unable-to-check messages. Record the named hook and any separate loopback warning.
-
Read the WP-Cron event list and configured trigger history without executing callbacks. Share only sanitized arguments.
-
After a focused correction, observe normal trigger cycles and confirm the affected publication, update, or low-risk queue workflow succeeds.
How broad is the scheduling problem?
All paths are listed below. Select a symptom to focus on the most relevant path.
Identify the callback owner
Check the installed scheduling code and matching logs. An orphaned event is possible, but do not delete it without confirming its owner and purpose.
Separate cron from queue processing
Compare the WP-Cron trigger with actual Action Scheduler completions and overdue jobs. Never replay renewals or clear failed actions just to remove the notice.
Did this help?
Quick triage: interpret the wording and scope
| What you see | What to investigate | First safe evidence |
|---|---|---|
| One named event, other scheduled work proceeds | A specific callback, stale event, or isolated delay | Hook owner, due time, and corresponding logs |
| Many unrelated events are overdue | The shared trigger or execution environment | Replacement-cron history, loopback result, and PHP errors |
| Action Scheduler’s queue hook is named | WP-Cron triggering and queue processing separately | Event timing plus actual queue completions |
| “It was not possible to check your scheduled events” | The diagnostic itself encountered an error | The displayed error message, not an assumed failed callback |
| Posts and jobs appear current, warning names an old plugin hook | An orphaned event or incomplete plugin cleanup | Whether the owning code and callback still exist |
1. Understand what Site Health actually tested
Open Tools → Site Health → Status, expand the notice, and copy the exact hook name and message. Distinguish “failed,” “late,” and “not possible to check.” Also note any separate loopback or REST API problem; they can coexist without having the same cause.
The official scheduled-events test implementation checks for missed and late cron events and reports the relevant hook. Its description explicitly allows for orphaned events from older code. It does not wrap every scheduled callback and return its application-level success or failure.
Consequently, “failed” here can mean an event missed the test’s timing criteria, not that WordPress captured a thrown exception from its callback. Exact thresholds and filters can vary with core and site code. Use the installed implementation when investigating edge cases rather than treating a dashboard label as a precise execution trace.
2. Capture a small, useful evidence set
Record the observation time and timezone, named hook, next scheduled time, recurrence, and whether the warning persists. Add the last relevant site change: plugin update, host move, PHP switch, restored backup, or scheduler reconfiguration. Identify the user-visible symptom, such as a missed publication or delayed integration.
An administrator with WP-CLI access can list events without deliberately executing callbacks:
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence --format=tableThe official command reference documents additional fields, including arguments. Avoid sharing full arguments publicly: plugins may store identifiers or private data there. Run the command against the correct installation and site context; a multisite network can have different cron state for each site.
Take a second observation after the expected trigger interval. Does the same event remain late? Are other events advancing? A single screenshot cannot distinguish a transient delay from a persistent failure. The command loads WordPress code, so it is an inspection tool rather than a guarantee that plugin bootstrap has no incidental effects.
3. If many events are late, inspect the trigger
The default WP-Cron mechanism is traffic-triggered, not a continuously running clock. A low-traffic site can accumulate late work. On a site with server cron, a DISABLE_WP_CRON setting may be intentional; the question is whether its replacement runs successfully against this installation.
Ask the host for the replacement’s target, cadence, last execution, exit status, and error output. Verify the path and PHP runtime after migrations. Check resource exhaustion and PHP fatal errors around those times. Merely seeing an enabled scheduler entry is not proof the application callbacks completed.
If Site Health also reports failed self-requests, inspect the exact error. A timeout calls for our loopback cURL error 28 guide. A REST 403 belongs to a different request path; our REST API blocking-layer guide helps interpret it without assuming all 403 responses are firewall rules.
Do not fetch wp-cron.php or run wp cron event run --due-now as a read-only probe. Those operations can execute business work. If an execution test is needed, plan it on staging or with the operator responsible for the affected callbacks.
4. If one hook is affected, identify its owner
A hook name often suggests a plugin, but names are not a complete dependency map. Ask the developer to locate the event’s scheduling code and registered callback in the installed version. A familiar plugin prefix is a lead; a matching callback and log entry are stronger evidence.
If the plugin was removed, establish whether the event is genuinely orphaned and what its removal would affect. Do not delete it simply because the name is unfamiliar. If the plugin is active, correlate the event time with errors and inspect its external dependencies, credentials, and application state through appropriate private diagnostics.
For a PHP failure, use our stack-trace ownership guide rather than editing the core dispatcher. For a callback with external effects, establish whether any part of the work already succeeded before considering a replay. A retry can duplicate an email, API update, or charge.
5. If the queue trigger is named, inspect Action Scheduler separately
A warning naming action_scheduler_run_queue concerns the cron event that can initiate queue processing. Individual Action Scheduler jobs have their own pending, complete, failed, or in-progress states. Other runner paths can also exist, so one cron warning does not prove that no actions are completing.
Read the latest completions and oldest overdue actions in the appropriate Scheduled Actions screen. Our Action Scheduler execution-gate guide separates trigger, runner, and callback failures. Do not interpret a queue full of future pending actions as evidence of a backlog.
Queue Health can provide read-only Action Scheduler and runner indicators, plus a privacy-conscious support report. It does not repair generic WP-Cron callbacks, rerun tasks, or prove the business outcome of an action. Use it only when the queue is relevant to the named event.
A public case with overlapping warnings
This WordPress.org support thread reported a failed Action Scheduler cron event alongside a loopback-related 403. The reporter later said removing their CDN cleared the warning; support noted that disabling the CDN was not the preferred targeted solution.
The case establishes that security and loopback configuration can be involved, not that Cloudflare must be disabled on every affected site. Match requests to actual security logs and correct the narrow rule or routing defect. A successful workaround alone does not identify the precise cause.
Verify the correction, not just the dashboard
After a focused, reversible change, refresh Site Health and compare the event list over normal trigger cycles. Confirm that the affected feature now works: an approved scheduled post publishes, the intended update check completes, or representative low-risk queue work progresses. A removed event can make a warning disappear while silently removing required functionality.
Keep before-and-after timestamps and the corrected configuration. If the warning returns, provide this small evidence set to the host or plugin maintainer. Do not flood a public forum with complete cron arguments or unredacted order logs.
What not to do
- Do not delete the whole cron option or suppress the Site Health test to claim a fix.
- Do not globally disable security or increase queue concurrency without matching evidence.
- Do not replay payment, renewal, or notification callbacks without checking external state.
FAQ
Is the warning proof the site is down?
No. Front-end pages can work while timed work is delayed. Assess the affected feature and urgency rather than equating the notice with a full outage.
Why does the warning name only one event?
The test reports a detected event; it is not a complete inventory of all failed work. Inspect the event list to understand scope.
Will reinstalling WordPress fix it?
Not necessarily. A missing trigger, plugin callback problem, or blocked self-request can persist. Repair the evidenced layer instead.