Snagbane Cron Monitor
| 开发者 | snagbane |
|---|---|
| 更新时间 | 2026年9月25日 06:30 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
If your scheduled posts are not publishing, your backups stopped running, or a plugin says its task is "queued" and never gets further, the usual advice is the same everywhere: check whether WP-Cron is disabled, trigger it by hand, install something that pings it once and calls it a day. None of that answers the actual question, which is whether your scheduled tasks are really not running, or whether your site is simply quiet.
That distinction is the whole problem. WP-Cron is not a real system cron. It only fires when somebody visits the site, so a low-traffic site naturally goes hours between ticks. That is not the same thing as a backup silently failing for a week -- but most cron checkers treat the two identically, and you get either constant false alarms on a quiet site or a real failure nobody notices.
Cron Monitor watches two separate signals instead of one:
- A heartbeat -- has WP-Cron actually run recently at all?
- A per-task grace window -- did each individually scheduled event fire within a reasonable time of when it was due?
- Working -- cron ran recently and tasks are firing.
- Running late -- a little behind. Often normal on a low-traffic site.
- Not working -- the site had visitors, which normally trigger cron, and it still has not run.
- Not enough data yet -- just installed, no baseline yet.
- Cannot record anything -- the plugin could not create the table it keeps history in, usually a database user without permission to create tables. It says so rather than reporting an all-clear it has no basis for.
DISABLE_WP_CRON set is recognised as the healthy setup it is, rather than reported as broken because WordPress is not the one spawning the request.
What you get
- The honest verdict above, on its own admin page and as a dashboard widget.
- A 30-day history of every scheduled task this site ran or missed, fully paginated. Everything kept is shown; there is no cap on either.
- Multisite support, including sites created after the plugin was network-activated.
- No configuration. It starts watching the moment you activate it.
- Available in English, German, Spanish, French, Italian, Dutch, Polish and Brazilian Portuguese.
- Why it broke, not just that it broke. Runs the checks a developer would run by hand: whether this site can reach its own wp-cron.php, whether something is answering that request with a password prompt or a refusal, whether the run lock is stuck, and whether scheduled events belong to a plugin that is no longer installed. Each answer comes with the specific next step.
- Which plugin is responsible for any given task, by name.
- What your tasks cost -- duration and peak memory for every run, ranked by total time, with a per-day trend that catches a task getting slower as the data underneath it grows.
- Tasks that start and never finish -- the case a "did it run" check reports as a success, and the reason everything scheduled behind it never gets its turn.
- "Run now" for any overdue task, without waiting for the next tick.
- Email and webhook alerts (Slack, Discord and anything else that accepts an incoming webhook), de-duplicated so a stuck task tells you once rather than every few minutes.
安装:
- Install through the WordPress plugins screen, or upload the plugin files to
/wp-content/plugins/snagbane-cron-monitor. - Activate it through the "Plugins" screen.
- Open "Cron Monitor" in your admin sidebar. There is nothing to configure -- the verdict is there on the first page load, and the history fills in as cron runs.
屏幕截图:
常见问题:
My scheduled posts are not publishing. Will this tell me why?
It will tell you whether the cause is cron. A post scheduled for a time that has passed and never went live means WordPress never got to run its publishing task, and this plugin shows you whether cron has been running at all, when it last ran, and which tasks were missed. If cron is running fine and the post still did not publish, the cause is elsewhere and you have ruled out the most common culprit. Pro goes further and tells you which specific thing is blocking cron.
Will this tell me my site is broken just because it is quiet?
No, and that is the specific thing this plugin exists to get right. A stale heartbeat is only reported as "Not working" when the site actually had recent visitors and cron still did not run. Otherwise it is reported as "Running late", which is a much less alarming and much more accurate thing to say.
Does this replace WP-Cron, or change how my tasks run?
No. It only observes. It never reschedules, disables or modifies another plugin's events. The one thing it schedules is its own five-minute heartbeat, which does nothing except give WP-Cron a predictable reason to tick.
I use a real server cron with DISABLE_WP_CRON. Does that work?
Yes, and it is detected. With that constant set, the verdict switches to checking whether your server cron is actually reaching wp-cron.php, and says so plainly either way instead of reporting the healthiest possible setup as a fault.
What is in the history log?
Every individually scheduled task this plugin watched, whether it ran or was missed, with how late it was. Not just the overall heartbeat. Thirty days on every install, and the screen shows all of it.
Does the free version name the plugin behind a missed task?
No. Naming the plugin or theme responsible is a Pro feature. The free log shows that a task ran or was missed, and when.
Does it slow my site down?
No. A front-end page view reads one option and, at most once a minute, writes it back. Everything else happens inside the WP-Cron request, which is a background request already.
更新日志:
0.3.1
- Fixed: on the Add-Ons screen, every plan's "Purchase" button in the Pro add-on's details opened checkout for the largest plan. Each button now opens its own plan.
- Fixed: on a host where the table could not be created, the plugin reported "Working" -- a confident all-clear from a plugin that had not managed to store a single row. It now says so plainly instead.
- Fixed: a site that a network activation skipped got its table but never its scheduled events, so it recorded nothing and its log was never trimmed.
- Fixed: network deactivation stopped at 200 sites, leaving a daily event scheduled on every site past that with nothing left to run it.
- Fixed: a fresh install on a server-cron site was declared broken for up to an hour, until the first crontab tick. It now says there is not enough data yet, which is what is actually true.
- Fixed: a cron request that did no work -- because another one held the lock -- still stamped the heartbeat and reported the tasks the other request was busy running as missed. Whether a request did the work is now decided on what it was actually seen to do, with the lock only as a fallback, so a run long enough to lose its lock to a later request still reports correctly and a request that was turned away reports nothing.
- Added: the history now shows how late each task was, which was recorded all along and never displayed, and a task that failed is marked as failed rather than shown as having run.
- Fixed: a fatal error inside the cron request the first time this plugin ever caught a missed task. The review-prompt listener was registered to receive one argument and declared as needing three, which PHP 8 raises an ArgumentCountError for -- so WP-Cron died at the exact moment the plugin did its job. It took the rest of the queue down with it.
- Fixed: tasks were reported as missed when a second cron request arrived while the first was still running. WordPress allows one cron run at a time and the second request returns immediately without doing anything, but it is still a cron request -- so every task the first request was busy running looked overdue from inside it. On a busy site, where overlapping cron requests are normal, that produced failures that never happened. This now checks the run lock and only reports on a request that actually processed the queue.
- Fixed: on multisite, network activation only reached the first 100 sites, and deactivation and deletion the same.
get_sites()defaults to 100 and has no "all" value, so every site past the hundredth silently had no tables and no scheduled events -- and kept its table forever on deletion. Activation now covers 200 sites inline and every site beyond that sets itself up on its first load; deletion pages through the whole network. - Fixed: the schema version was recorded even when the table could not be created, for instance on a database user without CREATE. The plugin then believed it was installed and every write went to a table that was not there. The version is now recorded only once the table is confirmed.
- Fixed: on a host where the table genuinely cannot be created, the plugin retried on every single request, front end included. It now retries at most once an hour.
- Fixed: deleting the plugin left its review-prompt option and, on a site with WP-Cron disabled, both of its scheduled events behind.
- Added: the plugin is now translatable, and ships translated into German, Spanish, French, Italian, Dutch, Polish and Brazilian Portuguese. A translation template is included, and further community translations at translate.wordpress.org are welcome -- anything published there is used in preference to the copies bundled here.
- Changed: the review prompt now waits for three confirmed missed tasks rather than one. One can be the tail of a single bad afternoon on the host, and a plugin installed this morning asking for a review this afternoon is a nag however it is worded.
- Changed: history is one fixed 30-day window on every install, kept and displayed in full, with pagination. Previously the log was retained for 14 days and only the last five rows were shown.
- Changed: renamed from "Snagbane - Cron Verdict" to "Snagbane Cron Monitor" (slug: snagbane-cron-monitor). All internal class, function, constant, hook, option and table names updated to match.
- Fixed: the
Plugin URIheader pointed at this plugin's own wordpress.org listing page, which WordPress.org's header requirements disallow. Now points to cronmonitor.snagbane.com. - Fixed: the plugin header's
Descriptionwas over WordPress.org's length limit for that field, as was this readme's short description. - Changed: header
LicensefromGPL-2.0-or-latertoGPLv2 or later, matching WordPress.org's own documented example.
- Added: an optional, one-time review prompt on this plugin's own admin page after it catches a genuinely missed cron job, rather than on a timer. Dismissible, never shown again once answered either way, and not tied to any tracking or external service.
- Fixed: the Text Domain header and every translation call now match the repository slug the plugin's name generates.
- Changed: readme rewritten so the description uses the phrases people actually search for. No code changes.
- Fixed: the Text Domain header and every translation call were corrected to match the plugin's own folder name, clearing 34 mismatch errors reported by WordPress.org's Plugin Check tool.
- Hardening: direct database queries against this plugin's own log table are individually documented with the reason no caching API applies, and the multisite uninstall loop moved into its own function so its variables are not assigned at global scope.
- Fixed: a hook scheduled more than once at the exact same due timestamp with different arguments -- a pattern some batch-processing plugins use -- could have one occurrence vanish from history, logged as neither ran nor missed. Every occurrence is now tracked independently.
- First release: heartbeat and per-task verdict engine, dashboard widget, history log.