Everything below reflects the current release (v1.0.0). From install to a fully attributed, diagnosed and repaired schedule is about fifteen minutes of your attention.
You need WordPress 6.0+ on PHP 7.4+, an administrator login, and the plugin zip plus licence key from your purchase email. Two honest notes before you begin: orphan flags say “likely” because conditional registration makes certainty impossible — the flag shows its evidence and the decision stays yours. And stall alerts obey physics: WordPress code runs only when a request arrives, so detection is opportunistic, at the first opportunity after the gap.
Go to Plugins → Add New → Upload Plugin, choose the zip from your purchase email, install and activate. It adds a Cron Repair item to the admin menu. Activation changes nothing about your schedules — the plugin starts by reading, not touching.
Open Cron Repair → Licence and paste the key from your purchase email into the licence box — it's a long code starting VPC1., so paste the whole thing into the textarea rather than typing it. Keys are domain-based — no account, no phoning home.
Open Cron Repair → Jobs. Every scheduled job is listed with the columns that matter: the job, its schedule, its owner — the plugin, theme or core it was traced back to — and its true status. Sort by owner to see whose work fills the queue; sort by status to see what's late.
The top of the screen gives the site one verdict: on time, drifting, or stalled with the hours counted. Under it, every overdue job with its gap in plain days — “21 days overdue”, “missed 6 times” — not raw timestamps. If cron is stalled site-wide, the verdict names the likely cause: no traffic to fire WP-Cron, or a DISABLE_WP_CRON constant with no server cron behind it.
From any row, Run now fires the job immediately and captures output, errors, duration and whether it rescheduled itself — a two-second answer to “broken or just late?”. Delete always takes a snapshot first (hook, arguments, schedule, next run) and the Undo list restores any deletion exactly as it was.
Under Monitor, set the alert email — the heartbeat monitor emails you when cron stalls. Under Migrate, copy the exact crontab line for your server and watch the verify panel confirm the real cron is firing. Under Report branding, add your agency logo, name and colours and generate the cron-health report — print-ready HTML and a downloadable PDF.
The screens and safeguards you'll actually live with.
Every cron job is a hook with callbacks, and every callback lives in a file. The plugin traces each job's callbacks to the plugin, theme or core code that registered them. Owners come from where the code lives, not from guessing at hook names — which is why the ledger can name CartNudge Mailer where a raw list shows cartnudge_send_reminders.
Each job is checked against its own schedule and the site gets one verdict: on time, drifting, or stalled with the gap counted in hours. “Is cron working?” becomes a one-line answer — and when it isn't, the verdict points at the likely cause rather than leaving you a list of timestamps.
Deleted plugins leave their schedules behind. The plugin flags jobs no code has claimed — and it's honest about certainty: plugins register callbacks conditionally, so an unclaimed job is a “likely orphan”, never a verdict. The flag shows its evidence (no owner found across this many requests, over this long) and leaves the decision to you. Snapshot undo makes acting on it reversible.
Fires the job's callback immediately in a controlled request and records what happens: output, errors, how long it took, and whether the job rescheduled itself. Use it to test a suspect job on the spot instead of waiting a week to see whether the backup appears.
Delete never just deletes. The job's hook, arguments, schedule and next-run time are snapshotted before removal, and the Undo list puts any deleted job back exactly as it was, one click. Clean an inherited queue without holding your breath.
Records a timestamp on every request the site receives; when a request arrives after a silent gap, it detects the stall and emails you the gap, the last successful run and the likely cause. Honest physics: detection is opportunistic — WordPress code needs a request to run, so the alert fires at the first opportunity after the stall, not at the exact second it began. A site with zero traffic can't raise its own alarm; that's what the migration helper is for.
Real server cron is the reliable fix for everything visitor-triggered cron gets wrong. The helper shows the exact crontab line for your site — copy, paste into the server's crontab — and tells you which line to add to wp-config yourself if you choose to switch the fallback off. It never edits wp-config or the crontab itself. The verify panel then watches for the real cron's first calls and confirms it's firing before you rely on it.
The ledger, dressed for the client: your agency logo, name and colours, the site verdict, every job with its owner, what was overdue, what was repaired, what's now watched. Print-ready HTML and a real downloadable PDF — the scheduled work nobody sees, on paper for the retainer file.
One textarea, one Activate button. Paste the full VPC1.… key from your purchase email. The key covers the number of sites on your plan; move a site by deactivating on one and activating on another. On multisite, ledgers and snapshots are scoped per site.
The constant itself isn't the villain — set it with a real server cron behind it and you've done the right thing. The damage happens when it's set during a migration or debugging session and forgotten, with nothing firing the schedule at all. The verdict detects that state and names it, and the migration helper gets you to the correct version of the setup.