By the Advantage Hosting WordPress support team
A WordPress site can look perfectly normal while an important background task is not running. A scheduled post may not publish, a backup plugin may not start its job, or a WooCommerce store may accumulate overdue actions behind the scenes.
That does not automatically mean WordPress is broken or that hosting is at fault. WordPress scheduling can be affected by visitor traffic, site configuration, loopback requests, plugins, themes, security controls and server-side conditions. The useful first step is to identify the symptom, preserve the details and work through a safe diagnostic order.
As part of routine maintenance, this is also worth checking after core updates. WordPress 7.1.4 was released on October 28, 2026, and WordPress describes it as a security release that should be installed promptly. Installing an update does not mean it caused a scheduling issue, but confirming that important background work still runs is a sensible post-update check.
WP-Cron in plain English
WordPress uses WP-Cron to schedule background events. Core uses scheduled events for work such as update checks and scheduled publishing, while plugins may use them for backups, reports, cleanup jobs, emails and store operations.
Unlike a traditional server scheduler that runs at set times independently, WP-Cron normally checks for due work when someone or something requests your site. On a low-traffic site, that can mean a due event waits until the next request arrives.
To start this work, WordPress normally makes a loopback request: a request from your website back to itself. If that request is blocked or cannot complete, scheduled work may be delayed or fail.
Typical WP-Cron flow
Visitor or automated request → WordPress checks for due events → loopback request to the same site → scheduled task runs
Server-scheduled flow
Server scheduler on a timetable → WordPress checks for due events → scheduled task runs
A server-side scheduler can be appropriate in some environments, but it is not automatically required for every WordPress site.
Start with the symptom
One symptom can have several possible causes. Use the first place to look as a starting point, not as a diagnosis.
| What you notice | First place to look | Who may need to help |
|---|---|---|
| A scheduled post did not publish | Confirm the site time zone and note the post’s scheduled time | Site administrator or developer |
| A Site Health loopback warning | Tools > Site Health > Status | Developer, plugin provider or host |
| A scheduled event is late or failed | Recent site changes, Site Health and the affected plugin’s logs | Site administrator or plugin provider |
| WooCommerce actions are pending, failed or in progress | WooCommerce > Status > Scheduled Actions | Store administrator, developer or host |
| A backup-plugin notification is missing or reports a problem | The plugin’s activity log and its backup destination/reporting settings | Site administrator, backup-plugin provider or host |
Safe 10-minute checks before changing anything
Start by collecting evidence. Avoid changing configuration files, disabling scheduling or copying a command from an unrelated guide before you know what is already in place.
- Confirm the WordPress time zone. A time-zone mismatch can make a scheduled post appear late when it is actually scheduled for a different local time.
- Open Tools > Site Health > Status. Look for a message about a loopback request or scheduled events. Record the exact wording rather than relying on memory.
- Capture timestamps. Note when the task should have run, when you observed the problem and the site’s configured time zone.
- Review recent changes. Include WordPress core, plugin and theme updates; new security or caching tools; DNS or SSL changes; and configuration changes made during maintenance.
- Check access restrictions. Confirm whether the site is in maintenance mode or protected by HTTP password authentication. These can affect a request WordPress makes back to its own site.
- If you run WooCommerce, inspect Scheduled Actions. Go to WooCommerce > Status > Scheduled Actions. Review pending, failed and in-progress actions, then open relevant logs for the affected task.
Take screenshots or copy the exact warning and relevant log entries before making changes. This gives a developer, plugin vendor or host something specific to investigate.
Common causes, without blame
The following are diagnostic leads, not conclusions. A single missed event does not prove any one cause.
Low visitor traffic
Because WP-Cron normally runs when the site receives requests, a quiet site may not process an event exactly when it becomes due. This is one reason a scheduled post or plugin task can run late on a low-traffic site.
WP-Cron was disabled without an equivalent server task
Some sites deliberately disable WP-Cron and use a server-side scheduled task instead. If WP-Cron was disabled but the replacement task was never configured, stopped running or points to the wrong location, due events can remain unprocessed.
A blocked loopback request
Plugins, themes, firewalls or other security rules can interfere with loopbacks. Persistent loopback problems may also require review of server-side security controls, firewall rules, DNS, SSL or HTTP authentication. Conflict testing with plugins or themes may be useful, but perform it carefully and preferably on staging where possible.
A plugin-specific queue or integration problem
A plugin can have its own queue, settings or external-service dependency. A WordPress scheduler issue may be involved, but it is also possible for the scheduling system to work while one plugin’s task still fails.
Resource or timeout constraints
Long-running background work can encounter timeouts or resource limits. The affected plugin’s logs, task details and the timing of the failure are important evidence when investigating this possibility.
WooCommerce: pay attention to Scheduled Actions
WooCommerce uses Action Scheduler for background work such as order notifications and payment processing, and it relies on WP-Cron by default. For an active store, the Scheduled Actions screen is an important operational check.
A growing list of overdue actions deserves attention, particularly when subscriptions, order processes, webhooks or sale-related tasks are involved. Not every late action indicates a failure; some late actions can occur. However, multiple actions overdue for more than a day can be a sign that WP-Cron needs investigation.
In WooCommerce > Status > Scheduled Actions, look at the status of relevant actions and open their logs. Record the action name, its scheduled time, status, error text and any pattern you see. Do not assume that clearing a queue or rerunning tasks will be safe for every store workflow; ask the relevant developer or plugin provider if you are unsure.
It is also useful to separate scheduling from delivery. For example, SMTP and DNS authentication are email-delivery concerns. A delayed scheduled action may instead affect whether a site generates an expected event in the first place. Both areas can matter, but they require different troubleshooting.
When a real server cron may help
A server-side cron task can trigger WordPress scheduling on a regular timetable instead of waiting for visitors. That may be worth assessing for a low-traffic site or a store with important background operations.
It is not a universal fix. High traffic can create its own performance considerations, and a server cron will not automatically resolve a plugin-specific error, a bad integration setting or every loopback issue.
Do not blindly enable DISABLE_WP_CRON, copy a generic command or run duplicate schedulers. First confirm your hosting environment’s supported configuration, whether a server-side task already exists and how the change should be tested. Document the final setup so that future maintenance does not accidentally leave scheduling disabled without a replacement.
What to send your host, developer or plugin provider
A clear support request can shorten the investigation. Include:
- Your domain or affected site URL
- The date, time and configured WordPress time zone
- The exact Site Health warning or error message
- The affected task or plugin, and what should have happened
- Whether any
wp-config.phpscheduling settings were changed - Recent WordPress, plugin, theme, security, DNS, SSL or maintenance changes
- For WooCommerce, the Scheduled Action status, logs and action details
- Whether the same issue happens on a staging site
Need help identifying whether a scheduled-task problem is related to site configuration, a plugin or the hosting environment? Contact Advantage Hosting for a practical review. If you are moving a WordPress site, you can also ask about free migration.
Prevention checklist
- After significant site changes, test a scheduled post or another non-critical scheduled task.
- Review Site Health periodically and keep a record of recurring warnings.
- On active WooCommerce stores, monitor Scheduled Actions and investigate persistent overdue or failed patterns.
- Document any server-side cron configuration, including who maintains it.
- Review backup reports and periodically confirm that restore procedures work.
A scheduled-backup notification alone does not prove that a backup is complete, retained elsewhere or restorable. Treat scheduling, backup completion and restore testing as separate checks.
Frequently asked questions
Is WP-Cron the same as server cron?
No. WP-Cron is WordPress’s scheduling system and normally checks for due events when the site receives requests. A server cron is a server-level scheduler that can trigger work on a regular timetable independently of visitors.
Why did my scheduled post publish late?
Low traffic can delay WP-Cron, but it is not the only possibility. Check the WordPress time zone, Site Health, recent changes and any loopback warning before deciding on a cause.
Does a loopback warning mean my host is at fault?
No. A loopback warning is useful diagnostic information, not proof of responsibility. Plugins, themes, security rules, HTTP authentication, DNS, SSL and server-side controls can all be relevant.
Should every WordPress site use server cron?
No. A server-side task can be useful in some environments, especially where reliable timing matters, but WordPress does not require every site to replace WP-Cron. Assess the site’s needs and confirm the supported setup before changing anything.
Where are WooCommerce scheduled actions?
In the WordPress dashboard, go to WooCommerce > Status > Scheduled Actions. There you can inspect pending, failed and in-progress actions, along with logs for relevant tasks.
