Cron-Sentry
A visual control tower for WP-Cron.
- WordPress plugin
- Version 1.6.1
- In development
Downloads are not open yet. This product is still in development — the button will go live when the first public release is ready.
WordPress runs scheduled work through WP-Cron, which only fires when somebody loads a page. On a quiet site, events run late or never. On a busy one, they overlap and hammer the database. Neither failure announces itself — you find out when the emails stopped going or the invoices did not generate.
Cron-Sentry gives you a visual control tower for all of it. Every task that runs during cron is timed and measured, heavy tasks can be guarded so only one copy runs at a time, stalls are force-closed and re-queued, and a real system crontab can drive the whole thing on an exact schedule.
The instrumentation only attaches during cron dispatch, so normal page loads carry none of the cost. Everything it records goes into one indexed table with a retention window you set.
Inside the product
37 things Cron-Sentry takes off your plate, grouped by the job they do.
Finding the expensive task
Every cron dispatch is instrumented and stored, then ranked, so the job actually costing you is obvious rather than suspected.
Ranked by what hurts
Runs, average and maximum duration, peak memory and failure count per hook, ordered so failures and slow jobs surface first.
No cost outside cron
Profilers attach only when the request is a genuine cron dispatch, so front-end and admin page loads are completely unaffected.
Per-run drill-down
Each run shows its source, schedule, owning component, duration, memory delta, peak memory, argument signature and message.
Blame the right plugin
Callbacks are resolved back to the file that defined them and attributed to a specific plugin, theme or WordPress core.
Optional query profiling
Query saving is switched on during cron only, recording query count, total query time and the slowest single query per run.
Filterable history
The last hundred runs filtered by success, error, stalled, skipped, paused or running, with a clear-history action.
Stopping jobs colliding
Mark a heavy task as guarded and only one copy of it will ever run at a time. The rest are cancelled cleanly and retried.
One copy at a time
A guarded hook takes a lock for the stall-threshold duration, released as the run closes. A second copy cannot start underneath it.
Cancelled, not dropped
A colliding run is logged as skipped, its callbacks removed, and re-queued shortly after — so the work still happens, just not twice.
It tells you what to guard
Hooks are ranked by prior skips and stalls, runtime against interval, heavy plugin families and telling keywords, with the reason shown per pick.
Core hooks left alone
Twelve lightweight WordPress core hooks are never recommended for guarding, so the suggestions stay worth reading.
Guards apply during cron only
The whole mechanism bails immediately when the request is not a cron dispatch, so it cannot interfere with a normal page load.
Recovering from stalls
A five-minute internal sweep force-closes stuck runs, recovers the work, and a shutdown guard catches fatal errors mid-task.
Stuck runs force-closed
Anything still running past the stall threshold — five minutes by default — is closed as stalled with the elapsed time recorded.
The work is re-queued
After a stall the stale lock is cleared and the hook re-scheduled: on its own recurrence, or as a single event a minute out.
Fatal errors captured
A shutdown handler marks open runs as errored with the PHP message, file and line — the detail a fatal mid-cron normally swallows.
Timeouts judged, not guessed
A request that simply ends leaves the row open so the sweep can judge it against the threshold rather than mislabelling it.
Log kept in bounds
Rows past the retention window — fourteen days by default — are deleted in batches, so the table cannot grow without limit.
Alerts that do not flood
Two independent channels, throttled per hook, so a job failing every five minutes does not fill your inbox overnight.
Email and webhook
A plain-text email with type, hook, detail, site and timestamp, and a JSON webhook payload that Slack, Discord and Teams all accept as-is.
One alert per ten minutes
Throttled per hook and per alert type, so a flapping task produces a signal rather than a wall of identical messages.
Fires on what matters
Stalled runs and fatal errors, plus a manual test. Overlaps are logged and counted rather than alerted, because they are handled.
Test before you trust it
A send-test button bypasses the throttle and reports the result inline, so you know the channel works before you rely on it.
Driving cron properly
Two ways to run scheduled work on an actual schedule, instead of waiting for a visitor to happen along.
A secret heartbeat endpoint
A REST route guarded by a shared secret spawns the cron run and returns the due-event count, ready for a real crontab or an uptime monitor.
Copy-paste recipes
The exact wp-config line, the full heartbeat URL, a five-minute curl crontab entry and the WP-CLI equivalent, ready to paste.
Throttled loopback fallback
For sites with some traffic: an optional keepalive that fires only outside cron and admin requests, only when events are due, and only past its interval.
Rotatable key
The heartbeat key is generated at activation and can be regenerated from settings behind a confirmation, should it ever leak.
Test the trigger
A button calls your own heartbeat URL over HTTP and reports either success or the exact failure message, rather than leaving you to curl it.
Editing the schedule
Full write access to the WordPress cron array from the admin screen, keyed on each event's real argument signature.
Reschedule and re-time
Move an event to a new date and time while preserving its recurrence and its stored arguments exactly.
Change the recurrence
Switch an event between any registered schedule and a one-off, with the slug validated before anything is written.
Add and remove events
Schedule a new hook with a first-run time and recurrence, or unschedule a single occurrence without touching its siblings.
Custom intervals
Create and delete named schedules — slug, seconds and display label — which then merge into the schedule list site-wide.
Run now, accurately
A manual run resolves the event's real stored arguments by signature, so it mirrors the scheduled run rather than approximating it.
Pause without unscheduling
Pause a hook from the command line and it stays in the queue but has its callbacks removed at dispatch, and is logged as paused.
Setup, health and the command line
A guided start, an on-demand scan of what is actually wrong, and eight commands for agencies running this across many sites.
Six-step wizard
Welcome, cron mode, overlaps, alerts, fallback and finish — pre-ticking the recommendations only on a fresh install.
Nine-point health check
Cron mode, a live loopback test, the sweep schedule, overdue events, seven-day failures, the heartbeat key, the log table, timezone and PHP environment.
Eight WP-CLI subcommands
List, run, pause, resume, profile, history, health and purge — with table, CSV, JSON or YAML output for scripting across sites.
Action Scheduler bridge
Surfaces the WooCommerce and Action Scheduler queue alongside WP-Cron, appearing as a menu item only when it is detected.
Help in three layers
A categorised guide page with thirteen FAQs and a glossary, native contextual help tabs on every screen, and a quick-links sidebar.
Support from the plugin
Raise a ticket with an environment snapshot attached automatically, and receive agent replies back on a signed webhook.
Developers and agencies running sites where scheduled work actually matters — stores, membership sites and anything with a queue.
What it needs
- Platform
- WordPress 5.6 or newer
- PHP
- 7.2 or newer
- Tested to
- WordPress 7.0.2
Questions about Cron-Sentry?
Every product is backed by the Keen2Support helpdesk. Customers raise tickets from inside the software itself, and replies sync straight back — no separate portal to remember, no password to lose.