WordPress External Cron: Services, Setup, and Free Options

/ Why WP-Cron fails

Why does WP-Cron fail on low-traffic sites?

WordPress ships with a built-in scheduling system called WP-Cron. Unlike a real cron daemon, WP-Cron does not run on a timer. It runs on page load: every time a visitor (or bot) requests a WordPress page, the site checks whether any scheduled jobs are due and runs them inline. This works acceptably on high-traffic sites because there is always a page load happening. On low-traffic sites — staging environments, small business sites, early-stage products — large gaps between page loads mean scheduled jobs pile up unprocessed.

The practical consequences: a scheduled email digest fires at 3 AM only if someone visits the site between 2:59 AM and 3:01 AM. A webhook queue runner that should fire every minute runs only as often as traffic arrives. A plugin that expires licenses daily may not run for 18 hours on a quiet Sunday.

External cron replaces the page-load trigger with a real scheduled HTTP ping — a service you control, running on its own schedule, regardless of site traffic.

WP-Cron (default)
  visitor request → wp-cron spawned → runs due jobs
  ↑ only fires when traffic exists

External cron service (correct)
  cron-job.org / UptimeRobot / EasyCron
        │
        │ every 1 min (scheduled HTTP GET)
        ▼
  GET /wp-cron.php?doing_wp_cron
        │
        ▼
  WordPress runs all due jobs
  (queues, emails, deliveries, expirations)
        │
        └─ returns 200 (jobs ran) or 200 empty (nothing due)

/ The cron URL

What URL do you ping for WordPress external cron?

The standard URL for triggering all WordPress scheduled jobs is:

https://yourdomain.com/wp-cron.php?doing_wp_cron

Replace yourdomain.com with your actual domain. The ?doing_wp_cron query parameter tells WordPress this is an intentional external trigger rather than a side-effect of a page load. The endpoint always returns HTTP 200 — even when no jobs were due — so status monitoring alone is not a reliable way to confirm cron ran. See the verification section below for a better approach.

If your site uses HTTPS (it should), always use the HTTPS URL. Most external cron services follow redirects, but some do not — use the canonical HTTPS URL directly to avoid a redirect on every ping.

/ cron-job.org setup

How do you set up WordPress external cron with cron-job.org?

cron-job.org is a free HTTP cron service with no rate limiting on 1-minute intervals, email failure notifications, and an execution log for each job. No payment is required for standard use.

1. Create an account at cron-job.org — free, email verification required.
2. Add a new cron job. In the dashboard click Create cronjob. Set the URL to https://yourdomain.com/wp-cron.php?doing_wp_cron and the request method to GET.
3. Set the schedule. Choose Every 1 minute under the schedule picker. For low-traffic sites, every minute is the right starting point — drop to every 5 minutes only if you have no sub-5-minute scheduled tasks.
4. Enable failure notifications. Under Notifications, enable email alerts on failure. This is your early warning when the WordPress site is down or wp-cron.php is returning non-200 responses.
5. Add DISABLE_WP_CRON to wp-config.php. See the next section — this step is required to prevent page loads from triggering cron in parallel.

/ Other free services

What other free external cron services work with WordPress?

UptimeRobot (free tier: up to 50 monitors, 5-minute minimum interval) is primarily an uptime monitor but doubles as a cron trigger — add a monitor of type HTTP(s) pointing at your wp-cron.php URL and set the check interval to 5 minutes. The free plan does not support 1-minute intervals, but for most sites a 5-minute cron window is acceptable. You also get uptime history as a bonus.

EasyCron offers a free tier with one cron job running every 20 minutes — suitable only for low-frequency tasks. Paid plans unlock 1-minute intervals. For single-site WordPress with budget constraints, EasyCron's free tier is usable but not recommended for sites with webhook queues that need frequent flushing.

Healthchecks.io works differently: it is a dead man's switch, not an active pinger. You configure a check with an expected ping interval, then your cron job pings the Healthchecks URL to signal it ran. Healthchecks alerts you when it stops receiving pings. For WordPress external cron, you would use a system cron entry or another service as the actual trigger, and Healthchecks for monitoring. It is free for up to 20 checks.

/ DISABLE_WP_CRON

How do you configure DISABLE_WP_CRON correctly?

After setting up an external cron service, add this constant to wp-config.php before the /* That's all, stop editing! */ line:

wp-config.php — disable page-load cron trigger

// Add before "That's all, stop editing!"
define( 'DISABLE_WP_CRON', true );

Without DISABLE_WP_CRON, every page load attempts to spawn a cron worker via a non-blocking loopback request to wp-cron.php. This means your external service and page-load traffic are both trying to claim and run the same due jobs. In most cases WordPress's lock mechanism prevents double-execution, but the wasted HTTP round-trips add overhead to every page load. Disabling the page-load trigger makes cron timing fully deterministic.

/ REST endpoint vs wp-cron.php

When should you use a plugin REST endpoint instead of wp-cron.php?

Pinging wp-cron.php runs all due jobs across every plugin on the site. For most WordPress installations this is fine. But there are cases where you want to run only one plugin's queue, with tighter control over batch size, or at a shorter interval than 60 seconds.

Webhook Actions Pro exposes a dedicated cron endpoint: /wp-json/fswa/v1/cron/process?token=<your-token>. Pinging this URL processes only the Webhook Actions delivery queue — not email campaigns, not license checks, not anything from other plugins. You can configure the batch size (1–100 items per ping) and run it as frequently as every 20 seconds from an external service. The WP-Cron endpoint has a minimum interval of 60 seconds because WordPress's own lock mechanism throttles faster pings. See the External Cron feature docs for configuration details.

/ Verification

How do you verify your external cron is actually running?

HTTP 200 from wp-cron.php only means WordPress responded — it does not confirm any jobs ran. Two reliable verification methods:

Check a plugin's queue log. Webhook Actions shows per-delivery timestamps in its Logs screen. After enabling external cron, trigger a test delivery and confirm the timestamp matches the expected interval. If the delivery log shows deliveries clustered at irregular intervals, page-load cron is still running alongside your external trigger — check whether DISABLE_WP_CRON is set correctly.

Use WP-CLI from the server. If you have server access, wp cron event run --due-now manually fires all due events and prints which hooks executed. Run it after your external cron fires and confirm the expected hooks appear in the output.

/ Zero-config option

What is the zero-config alternative to managing external cron yourself?

If you are running Webhook Actions Pro, you do not need to configure cron-job.org, UptimeRobot, or any external service manually. The External Cron feature provisions a managed Uptime Kuma heartbeat monitor automatically when you activate your Pro license. It handles DISABLE_WP_CRON configuration, sets the ping interval (down to 20 seconds in plugin-endpoint mode), and shows a live heartbeat chart with monitor status directly in the Webhook Actions admin screen.

For teams already managing external cron manually — via a server crontab, hosting panel, or one of the services above — the external cron approach in this article is completely valid and costs nothing. The Webhook Actions managed option is for teams who want reliability without any server or service configuration overhead. See the WP-Cron developer reference for the full wp_schedule_event and WP-CLI cron command reference if you need finer-grained control.

External cron is not a plugin feature — it is a fundamental requirement for any WordPress site that relies on scheduled jobs running at predictable times.