When the schedule stops running, the usual responses are: install WP Crontrol, reinstall everything and hope, or set up server cron by hand. Here's the honest breakdown against all three.
WP Crontrol is a good free plugin on over a million sites — it views, edits, adds and runs cron jobs well. But it hands you the raw hook list and leaves the hard questions to you: whose job is slidestack_cleanup, does 21 days late matter, is deleting it safe? Reinstalling everything feels decisive and usually changes nothing — the stale schedules survive in the database, and the actual cause (no traffic to fire WP-Cron, or a forgotten DISABLE_WP_CRON) survives the weekend of work untouched. Hand-rolled server cron is the right destination reached the hard way: one crontab line over SSH, no confirmation it's firing, and nothing watching it afterwards. WP Cron Repair (this site) treats cron as something to diagnose, not just edit: every job attributed to the plugin that owns it, overdue gaps stated in plain days with a site-level verdict, likely-orphan flags with honest language, run-now with output captured, delete with snapshot undo — and on Pro, stall alerts by email, the server-cron migration helper with a verify panel, and the branded cron-health report with a real PDF.
| Feature | WP Cron Repair | WP Crontrol | Reinstall everything | Server cron by hand |
|---|---|---|---|---|
| Shows every scheduled job | ✓ Full inventory | ✓ Does this well | ✗ Blind | ✗ Crontab shows one line, not WP's queue |
| Attributes each job to its owner | ✓ Plugin named per row | ✗ Raw hook names | ✗ No | ✗ No |
| Says what's overdue, in plain days | ✓ + site health verdict | ◐ Next-run times; you do the maths | ✗ No | ✗ No |
| Finds schedules from deleted plugins | ✓ Likely-orphan flags, with evidence | ◐ If you recognise the unfamiliar hooks | ✗ Reinstalling leaves them queued | ✗ Not its layer |
| Run-now with output capture | ✓ Output, errors, duration | ◐ Runs it; captures nothing | ✗ No | ◐ wp-cli if you're comfortable there |
| Delete with undo | ✓ Snapshot first, one-click restore | ✗ Permanent | ✗ N/A | ✗ N/A |
| Alerts when cron stalls | ✓ Heartbeat email (Pro) — opportunistic, honestly | ✗ Nothing watches | ✗ Nothing watches | ✗ Nothing watches |
| Gets you onto real server cron | ✓ Exact crontab line + verify panel (Pro) | ✗ Docs suggest it; you're on your own | ✗ No | ✓ That is the job — done by hand, unverified |
| Client-ready evidence | ✓ Branded report + PDF (Pro) | ✗ Nothing | ✗ Nothing | ✗ Nothing on paper |
| Cost | From $49/yr · $599 lifetime | Free | A lost weekend | Free + SSH confidence |
You know your hooks by name, you can tell an orphan from a live job on sight, and you want a free editor — WP Crontrol is excellent at being exactly that, and we'd rather say so than pretend otherwise. Likewise, if you're comfortable in a crontab and only look after your own site, hand-rolled server cron plus wp-cli is a perfectly honest setup. The one alternative we'd talk you out of is reinstalling everything: it doesn't clear stale schedules, it doesn't touch the cause, and it costs a weekend to change nothing.
Clients' sites depend on schedules you're responsible for, and you want every job attributed, every gap diagnosed, and every repair reversible — with stall alerts that arrive by email, a verified migration to real server cron, and a branded report for the retainer file. It also pairs with WP Drift Auditor without overlap: Drift Auditor checks cron policy; this fixes cron reality. That's us.
One honest line: the heartbeat monitor obeys physics — WordPress code runs only when a request arrives, so stall detection is opportunistic, at the first opportunity after the gap, never magically at the exact second. And "likely orphan" means likely: conditional registration makes certainty impossible, so we flag with evidence instead of declaring — and snapshot undo makes acting on a flag reversible anyway.