Cronheart
| 开发者 | cronheart |
|---|---|
| 更新时间 | 2026年11月13日 21:58 |
| PHP版本: | 8.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
WP-Cron stopped and nothing told you. WordPress runs its scheduled jobs only when someone visits the site. On a quiet site, a backup, a newsletter or a cleanup can stay stalled for weeks before anyone notices. Uptime monitors do not catch it: the site answers over HTTPS just fine, it simply is not running its jobs.
Cronheart turns WP-Cron into a dead-man switch. The plugin pings cronheart.com every five minutes, and sends a
start, success or fail ping around every run of each event you register. If the pings stop, or a job fails, cronheart alerts you by email, Telegram, Slack, Discord, Microsoft Teams, Google Chat, PagerDuty or a signed webhook.
Setup in 4 steps
- Install and activate the plugin.
- Create a free account at cronheart.com.
- Add a monitor for your site that expects a ping every 5 minutes, and copy its UUID.
- Paste the UUID under Settings → Cronheart and save. The first heartbeat is sent on the next WP-Cron run.
- Site heartbeat. A 5-minute custom WP-Cron event whose only job is to ping cronheart. Proves WP-Cron itself is alive on this site.
- Per-event monitoring. Register any scheduled hook for start / success / fail pings with one PHP one-liner:
cronheart_monitor( 'my_nightly_report', 'xxxxxxxx-…' ); - PHP fatal-error capture. When a scheduled callback fatals or throws, the fail-ping body includes the
error_get_last()summary — the cronheart dashboard shows the cause without you tailingdebug.log. This holds for runs through a page request,wp-cron.php,ALTERNATE_WP_CRONand WP-CLI'swp cron event run. - Settings page. A read-only "Monitored events" table at Settings → Cronheart shows every hook the plugin is watching and where its UUID came from (constant, option, filter).
- Monitor picker. Save a cronheart.com API token and the site heartbeat field becomes a dropdown of your account's monitors instead of a hand-typed UUID. Entirely optional — without a token you paste the UUID as before, and any API hiccup falls back to that field. The token is write-only and never leaves wp-admin.
- Account overview and monitor management. With a token configured, Settings → Cronheart shows your plan and monitor budget, and a "Your monitors" table listing each monitor with its status and any active snooze. From that table you can pause, resume, snooze (1 hour, 4 hours, 1 day, or 1 week), or unsnooze a monitor; the change applies on cronheart.com immediately. Every action is an authenticated administrator request — nothing happens without your click.
- Per-event monitoring UI. A Settings → Cronheart Events screen lists the recurring WP-Cron events on your site and lets you, per event, either assign one of your monitors from a dropdown or auto-create an interval monitor for it in one click — no code required. This is the point-and-click alternative to the
cronheart_monitor()helper andCRONHEART_EVENT_<HOOK>_UUIDconstants, which still work. A constant overrides an assignment made on this screen; an assignment made on this screen overrides the helper. - Channel management. A Settings → Cronheart Channels screen lists your cronheart.com notification channels and lets you, per channel, send a real test alert through it or — for webhook channels — rotate the signing secret (revealed once). Creating channels stays on cronheart.com; this screen tests and maintains the ones you already have.
- Ping & alert history. A Settings → Cronheart History screen shows the most recent pings (kind, time, runtime) and alerts (kind, time, channels notified) for a monitor you pick (the picker lists up to 200 monitors) — a read-only at-a-glance log without leaving WordPress.
- Configuration through
wp-config.phpconstants for production (CRONHEART_HEARTBEAT_UUID,CRONHEART_EVENT_<HOOK>_UUID), with admin-UI fallback for sites where editingwp-config.phpis not practical.
- WordPress 6.0 or later.
- PHP 8.2 or later with the cURL extension (
curl), which most hosts enable. - A cronheart.com account; the free plan is enough. An API token is optional.
WP_DEBUG and WP_DEBUG_LOG on, a ping that fails leaves one line in the debug log. A third-party filter that throws while the plugin reads its settings is caught too. If cronheart goes down for a day, your wp_schedule_event callbacks still run normally; you just stop seeing pings on the dashboard. When the plugin cannot send pings safely (the PHP cURL extension is missing, or the endpoint setting is one it does not accept), it sends none and shows an error notice in wp-admin instead.
External services
This plugin sends HTTP requests to cronheart.com in two distinct situations: the monitoring pings your scheduled jobs send, and the account-management calls the admin settings page makes. Both are opt-in: without configuration the plugin loads and does nothing — no telemetry, no usage statistics, no anonymous reports.
1. Monitoring pings (front end / WP-Cron). Sent on every scheduled WP-Cron run, but only when you supply a monitor UUID. The exact data sent per ping:
- The per-monitor UUID you configured (path segment).
- A short body — capped at 10 KB — that is empty for
start/success/heartbeatpings. For afailping it holds the PHP error type, the file path and line, and the message of the fatal error or uncaught exception, or a one-line note that the event did not complete. - The bundled SDK's name and version in a
User-Agentheader (for examplecron-monitor-php-sdk/1.9).
https://cronheart.com/api/v1/.... Every such request carries the token as an Authorization: Bearer header and runs only while a logged-in administrator is on one of those screens — and, for the write actions below, only when that administrator clicks the control. Never on the front end, during WP-Cron, or in any other context. No token, no request. The calls are:
- Read your monitors —
GET /api/v1/monitors— to populate the heartbeat picker, the "Your monitors" table, the per-event assignment dropdowns, and the Cronheart History monitor picker. Sends nothing beyond the token and paging parameters. - Read your account —
GET /api/v1/account— to show your plan, monitor budget, and API rate-limit standing. Sends nothing beyond the token. - Lifecycle actions —
POST /api/v1/monitors/<uuid>/pause(or/resume,/snooze,/unsnooze) — sent when you click a pause / resume / snooze / unsnooze button. Sends the monitor's UUID (in the path) and the action; snooze also sends the chosen duration (1 hour, 4 hours, 1 day, or 1 week). - Create a monitor —
POST /api/v1/monitors— sent when you click "Auto-create & assign" for a recurring event on the Cronheart Events screen. Sends the event's hook name (as the monitor name), its schedule as an interval in seconds, the site timezone, and a grace period — all derived from the WP-Cron schedule — plus an idempotency key that is a SHA-256 hash of the site URL and the hook name (the URL itself is not sent), so a repeated click does not create a second monitor. - Read your channels —
GET /api/v1/channels— to populate the Cronheart Channels screen. Sends nothing beyond the token. - Send a test alert —
POST /api/v1/channels/<id>/test— sent when you click "Send test" on a channel. This delivers a real notification to that channel's destination (your configured email, Telegram, Slack, Discord, Microsoft Teams, Google Chat, PagerDuty, or webhook), so it is the one management call with an effect outside cronheart.com. Sends only the channel id (in the path). - Rotate a webhook secret —
POST /api/v1/channels/<id>/rotate-secret— sent when you click "Rotate secret" on a webhook channel. cronheart.com mints a new signing secret (shown to you once) and invalidates the previous one. Sends only the channel id (in the path); the new secret is shown in the page and never stored by the plugin. - Read ping & alert history —
GET /api/v1/monitors/<uuid>/pingsandGET /api/v1/monitors/<uuid>/alerts— to populate the Cronheart History screen for the monitor you select. Reads the most recent page only. Sends the monitor's UUID (in the path) and paging parameters.
cron-monitor/php-sdk PHP package (also open source, MIT-licensed). Both projects are maintained independently.
安装:
The plugin needs PHP 8.2 or later with the cURL extension (
curl), which most hosts enable. Without the extension the plugin sends no pings and shows an error notice in wp-admin.
- Install the plugin: WP Admin → Plugins → Add New → search for "Cronheart" → Install Now → Activate. Or upload
cronheart.zipfrom a GitHub release. - Sign up at cronheart.com and create a monitor for your site's heartbeat, with a 5-minute schedule. Copy the monitor UUID from the dashboard. Until a UUID is set, a notice on the Plugins screen and the Dashboard links to the setup; you can dismiss it.
- Configure the UUID. Either add it to
wp-config.phpwithdefine( 'CRONHEART_HEARTBEAT_UUID', 'xxxxxxxx-…' );(recommended), or paste it under Settings → Cronheart in the WP admin. - Done. If you saved the UUID under Settings, saving queues one heartbeat for the next WP-Cron run, so the first
heartbeatping shows on the cronheart dashboard shortly after. With thewp-config.phpconstant, the first ping arrives within five minutes. From then on it repeats every five minutes. - (Optional) To choose a monitor from a dropdown instead of pasting its UUID, create a Personal Access Token at cronheart.com (Account → API tokens) and save it under Settings → Cronheart. Every plan, the free one included, can use the API; the account email must be verified before a token can be created. The plugin works fully without a token. For production, prefer
define( 'CRONHEART_API_TOKEN', 'cmk_…' );inwp-config.phpto keep the account credential out of the database.
add_action( 'plugins_loaded', function () { cronheart_monitor( 'my_nightly_report', 'xxxxxxxx-…' ); }, 1 );
The hook then emits start / success (or fail on a fatal / thrown exception) pings on every scheduled run.屏幕截图:
常见问题:
Why not just use an uptime monitor?
An uptime monitor checks that your site answers requests. It does not know whether WordPress ran its scheduled jobs: a site can serve every page while its backups, emails and cleanups are stalled. Cronheart watches the jobs themselves, and alerts you when the heartbeat stops or a monitored job fails.
How long until I see the first ping?
Saving a monitor UUID under Settings queues one heartbeat for the next WP-Cron run, which on a site with visitors is the next page load. If you defined the UUID in wp-config.php instead, the first ping arrives within five minutes. After that the plugin pings every five minutes. On a site that has WP-Cron disabled, it happens on the next run of your system cron.
How do I monitor my own scheduled jobs, not just the site?
Two ways. With an API token saved under Settings → Cronheart, the Cronheart Events screen lists your recurring events and lets you assign a monitor to each, or create one in one click. Without a token, register a hook in code with cronheart_monitor( 'my_nightly_report', 'xxxxxxxx-…' );. A CRONHEART_EVENT_<HOOK>_UUID constant in wp-config.php then supplies or overrides that hook's UUID.
Is it free?
Yes. The Free plan on cronheart.com covers 20 monitors, needs no credit card and does not expire. Every plan, the free one included, has all notification channels and the REST API. Paid plans raise the monitor count and the API rate limit; see cronheart.com/pricing.
Does this work when WP-Cron is disabled (system-cron mode)?
Yes. If you set define( 'DISABLE_WP_CRON', true ); and trigger wp-cron.php from a real system cron, the plugin's cronheart_heartbeat_tick event still fires on each run — the trigger mechanism is different, the action chain is the same. Running events with WP-CLI (wp cron event run --due-now) works as well, including the fail ping of an event that throws.
What if my host blocks outgoing HTTPS?
The plugin will retry up to twice (three attempts in all, each limited to 3 seconds) after a connection error or a server error, then give up; an answer that refuses the ping, such as a wrong monitor UUID, is not retried. Your scheduled callbacks still run normally — the plugin never raises an exception that could break the cron runner. The monitor on cronheart.com reports the missed run. With WP_DEBUG and WP_DEBUG_LOG on, each ping that fails also leaves one line in wp-content/debug.log (a ping the service refuses, such as one with a wrong monitor UUID, too), with the reason but without the monitor UUID or the full ping URL.
Do I need an API token?
No — it is entirely optional. Paste a monitor UUID under Settings → Cronheart (or define it in wp-config.php) and the plugin works on any plan, including the free tier. A token only adds convenience: the settings page can then list your monitors and let you pick one from a dropdown instead of copying a UUID by hand. The token is an account-level credential, so for production prefer defining CRONHEART_API_TOKEN in wp-config.php over storing it in the database. The token features work on every plan, the free one included, but cronheart.com only lets an account with a verified email address create a token. If the token is refused or cronheart.com cannot be reached, the page shows a notice and falls back to manual UUID entry.
Where do I find my monitor UUID?
Sign in at cronheart.com, open the monitor you created, and copy the UUID shown under its name (it has a copy button), or take it from the address bar or from the end of the monitor's ping URL.
What happens to my scheduled jobs if cronheart.com is unreachable?
Nothing. The plugin catches every network / HTTP error from the SDK (and, with WP_DEBUG and WP_DEBUG_LOG on, writes one line per failed ping to the debug log) — your wp_schedule_event callbacks continue to run. You will stop seeing pings on the cronheart dashboard, and after the configured grace period cronheart sends you the down-alert. When cronheart comes back the next successful ping resolves the incident automatically.
Does the plugin track or report anything about my site?
No. The plugin sends a ping to cronheart only when you have configured a monitor UUID. The ping payload is the UUID, an optional short body excerpt (capped at 10 KB), and the SDK's User-Agent header. There is no anonymous-statistics beacon, no plugin-usage telemetry, no calls to any third-party analytics service.
Can I point the plugin at a non-production cronheart deployment (staging / private / self-hosted)?
Yes. Define CRONHEART_ENDPOINT in wp-config.php with the URL of your alternate deployment. For plain http:// endpoints (local development, private VPNs without TLS) also set CRONHEART_ALLOW_INSECURE_ENDPOINT to true. With both unset, the plugin pings the production cronheart.com over HTTPS. The API token is only ever sent over HTTPS, so with a plain http:// endpoint the settings screens fall back to manual UUID entry while pings keep working. An endpoint the plugin does not accept (one with no http:// or https:// scheme, or plain http:// without CRONHEART_ALLOW_INSECURE_ENDPOINT) stops all pings and shows an error notice in wp-admin; the plugin does not send them to cronheart.com instead. An empty CRONHEART_ENDPOINT means cronheart.com even when the cronheart_endpoint option is set, and a CRONHEART_ENDPOINT that is not a string is ignored.
What does the "Cronheart is not sending pings" notice mean?
The plugin shows this error notice on every wp-admin screen, to users who can manage options, when it cannot send pings safely; it then sends none. The notice names the cause. If the PHP cURL extension is not loaded on the server, ask your host to enable it. If the endpoint setting is not accepted, the notice says whether CRONHEART_ENDPOINT in wp-config.php or the cronheart_endpoint option holds it: use an https:// URL (a plain http:// URL also needs CRONHEART_ALLOW_INSECURE_ENDPOINT), or remove the setting to use cronheart.com. Until then your monitors alert that the jobs stopped checking in. The notice cannot be dismissed; it disappears on the next page load after the cause is fixed.
Where can I report bugs or request features?
Open an issue on GitHub.
更新日志:
0.6.0
- A setup notice on the Plugins and Dashboard screens until a heartbeat UUID is set; each user can dismiss it.
- A Settings link on the plugin's row in the Plugins list, and first-run steps on Settings → Cronheart.
- Saving a new heartbeat UUID queues one heartbeat for the next WP-Cron run, so the first ping does not wait for the five-minute tick.
- Links to the cronheart.com signup and guide carry a
ref=wp-pluginlabel. - Readme rewritten: shorter description, four-step setup, a fuller FAQ, refreshed screenshots.
- A third-party cron filter that throws no longer stops
wp plugin activateordeactivate, and no longer leaves a wrongcurrent_action()for a monitored event's own callbacks.
- A server without the PHP cURL extension no longer gets a fatal error on every request. The plugin then sends no pings and shows an error notice in wp-admin to users who can manage options.
- An endpoint setting the plugin rejects (no
http://orhttps://scheme, or plainhttp://withoutCRONHEART_ALLOW_INSECURE_ENDPOINT) now stops all pings and shows an error notice in wp-admin naming the constant or option that holds it. Before, the pings and the monitor UUIDs in them went to cronheart.com instead of the configured host. - A third-party filter that throws while the plugin reads its monitor settings no longer stops a monitored WP-Cron event's own callbacks, ends the rest of the run, or ends every request; the plugin skips the affected ping instead.
- The
cronheart_allow_insecure_endpointoption now readsfalse,no,offand any unrecognised value as false, like theCRONHEART_ALLOW_INSECURE_ENDPOINTconstant. - With
WP_DEBUGandWP_DEBUG_LOGon, each failed ping writes one line to the debug log, including a ping the service refuses (such as one with a wrong monitor UUID). The line never holds a monitor UUID, an API token or a full URL. - The plugin description is brought up to date: all eight alert channels, what a
failping's body and theUser-Agentheader contain, the idempotency key of the auto-create call, WP-CLI runs, the retry rules and where to find a monitor's UUID.
- A monitored WP-Cron event that throws or hits a fatal error now sends its
failping when it is run withwp cron event run(including--due-now), as hosts that drive WP-Cron from a system cron through WP-CLI do. Before, WordPress's own fatal-error handling ended the WP-CLI process before the plugin could send it, so the monitor received astartand nofailand stayed up. Runs through a page request,wp-cron.phporALTERNATE_WP_CRONalready sent it. Thefailis sent once, and the WP-CLI command's output and exit code are unchanged.
- A ping that meets a server error or a connection error is now tried up to three times instead of two. After a 503 that carries a whole-second
Retry-Afterthe bundled SDK waits for it; after any other failure it waits a short fixed step; all waits of one ping stay within the ping timeout, and a 4xx answer is not retried. The ping timeout is now 3 seconds per attempt, so one ping takes at most about 12 seconds when the service keeps answering 503 slowly and about 10 seconds when it is unreachable; a ping sent inline in a visitor's request (ALTERNATE_WP_CRON, or a monitored hook fired by a page request) is held for that time. Requests that use your account API token keep one retry. Bundlescron-monitor/php-sdk1.9. The FAQ answer about a blocked host no longer promises adebug.logline.
- Maintenance release with no change in behaviour. Code comments describe the limits of the cronheart.com monitor API (interval, monitor name length, grace period, channel ids) in the API's own terms. The development smoke script, which is not part of the plugin package, now fails within seconds on a wrong API token or monitor UUID and waits briefly for the pings to show up.
- Corrected the notice shown when an API token entered on the settings page is rejected: it now points to Account → API tokens on cronheart.com, where tokens are created, instead of Settings → API Tokens. Wording only; no behaviour change.
- Upgraded the bundled
cron-monitor/php-sdkto^1.5.2. The SDK keeps the API token and monitor UUIDs out of its own stack-frame arguments, which an error tracker records, when an API call or a ping fails, and it refuses a monitor UUID with a trailing newline before any request is made. The plugin validates the UUIDs its own admin screens save, but aCRONHEART_HEARTBEAT_UUIDorCRONHEART_EVENT_<HOOK>_UUIDconstant, acronheart_monitor()call or acronheart_monitor_mapfilter value reaches the SDK as written; with a trailing newline the older SDK sent the ping to a mangled address, which cronheart.com rejected. The ping still does not arrive, so the monitor keeps reporting missed runs until the value is fixed, but no request is sent; the WP-Cron run is unaffected either way. - Corrected the admin copy that tied the REST API to a paid plan. cronheart.com includes the API on every plan, the Free plan included; the plan sets the rate limit and the monitor cap. The Settings → Cronheart introduction no longer says API access needs a Starter plan and now says creating a token needs a verified email address, and the "does not include API access" notices on the settings, Events, Channels and History screens now say the plan does not allow the request. Wording only; no behaviour change.
- Channel management. A new Settings → Cronheart Channels screen lists your cronheart.com notification channels and lets you, per channel, send a real test alert through it or — for webhook channels only — rotate the signing secret (revealed once, then never shown again). Creating channels stays on cronheart.com for now; this screen tests and maintains the channels you already have.
- Ping & alert history. A new Settings → Cronheart History screen shows the most recent pings (kind / time / runtime) and alerts (kind / time / channels notified) for a monitor you pick (the picker lists up to 200 monitors). Read-only, and only the first page (latest 50 of each) — it never walks your whole history.
- Both screens reuse the same admin-AJAX contract as the earlier management UI (nonce,
manage_options, boundary validation, no public endpoint) and the throwing management client; "Send test" delivers a real notification, and the rotated webhook secret is shown once and never stored by the plugin. The runtime ping path is unchanged. - Upgraded the bundled
cron-monitor/php-sdkto^1.4. It adds the typed channel-test delivery exception, so a failed test send reports "the destination rejected delivery" distinctly from other errors, and it keeps monitor UUIDs and API tokens out of its log lines and error text. - A monitor status, ping kind or alert kind this version does not recognise yet is now shown as-is on the admin screens instead of failing the whole listing.
- The API token is now sent only over HTTPS. With a plain
http://endpoint the management screens fall back to manual UUID entry; pings keep working. - Tested up to WordPress 7.1.
- Corrected the FAQ: notification channels are available on every cronheart.com plan, including the free one.
- Corrected the description of the Cronheart Events screen: an assignment made there overrides the
cronheart_monitor()helper, and only aCRONHEART_EVENT_<HOOK>_UUIDconstant overrides the assignment. Earlier notes said the helper took precedence. - The "External services" disclosure now also covers the channel reads / test / rotate-secret calls and the history reads — including that "Send test" sends a real notification to the channel's destination.
- Per-event monitoring UI. A new Settings → Cronheart Events screen lists the site's recurring WP-Cron events and lets you, per event, assign one of your monitors from a dropdown or auto-create an interval monitor for it in one click — the point-and-click alternative to the
cronheart_monitor()helper andCRONHEART_EVENT_<HOOK>_UUIDconstants (both still work and still take precedence). - Auto-create. "Auto-create & assign" derives an interval monitor from the event's WP-Cron schedule — name from the hook, interval in seconds, site timezone, and a grace period — within cronheart.com's accepted ranges, and is offered only for unmapped, recurring events. It is idempotency-keyed so a double click is safe.
- The assign / auto-create actions go through the same admin-AJAX contract as 0.3.0 (nonce,
manage_options, boundary validation, no public endpoint); the request hook is always validated against the discovered event set, and assigning a monitor is a local option write that needs no token. The live controls are token-gated like the heartbeat picker; without a token the screen is a read-only view. - The "External services" disclosure now also covers the create call (
POST /api/v1/monitors), sent only when you click "Auto-create & assign".
- Account overview. With a cronheart.com API token configured, Settings → Cronheart now shows your plan, monitor budget (used / limit / remaining), and API rate-limit standing, with an upgrade nudge when you are near your monitor limit.
- Monitor management from wp-admin. A new "Your monitors" table lists each monitor with its status and any active snooze, and lets you pause, resume, snooze (1 hour / 4 hours / 1 day / 1 week), or unsnooze it — applied on cronheart.com immediately. This is the plugin's first admin-AJAX surface: every action is nonce-checked, capability-gated (manage_options), validated at the boundary, and degrades to a readable message rather than a fatal if the API call fails. No public (nopriv) endpoint is registered.
- Monitor status in the picker. The heartbeat dropdown now shows each monitor's status alongside its name.
- Upgraded the bundled
cron-monitor/php-sdkto^1.1, which adds the account and monitor-lifecycle endpoints these features use. - The "External services" disclosure has been rewritten to cover the new read (
GET /api/v1/account) and write (POST /api/v1/monitors/<uuid>/{pause,resume,snooze,unsnooze}) calls; all remain wp-admin-only, token-gated, and triggered by an administrator's explicit action.
- Documentation and screenshots for the monitor picker. No functional change from 0.2.0 — the plugin code is identical; this release refreshes the readme ("What it does", external-services disclosure, FAQ) and adds an updated settings-page screenshot showing the picker.
- Monitor picker. Save a cronheart.com API token under Settings → Cronheart and the heartbeat field becomes a dropdown of your monitors instead of a free-text UUID box. The selection still saves to the same
cronheart_heartbeat_uuidoption, so nothing changes about how pings are sent — only how you fill in the UUID. - Write-only API token field. The token is never echoed back into the page; it can be set in the database or, preferred for production, via a new
CRONHEART_API_TOKENconstant inwp-config.php. - wp-admin-only API call. Listing your monitors happens only on the settings page, only when a token is configured, and never on the front end or during WP-Cron. The runtime ping path is unchanged and carries no account credential. See the updated "External services" disclosure.
- Graceful fallback. If the listing fails — no API access on your plan, an invalid token, a rate limit, or a network error — the page shows a notice and falls back to manual UUID entry. The admin page never fatals.
- Upgraded the bundled
cron-monitor/php-sdkto^1.0, which adds the authenticated management-API client the picker uses.
- Directory review fix:
Contributors:set to the slug owner. No code changes.
- "Tested up to" 7.0. No code changes.
- Restored the Terms of Service and Privacy policy links. No code changes.
- Directory review fixes: dead links removed,
Contributors:corrected, CLI binaries dropped from the zip. No behaviour changes.
- "Tested up to" 6.9. No code changes.
- Release zip trimmed to runtime files, a copyright header in
LICENSE, changelog cleanup. No behaviour changes.
- Plugin Check fixes: direct-access guards and output escaping. No behaviour changes.
- Full readme for the Plugin Directory submission. No code changes.
- Endpoint override (
CRONHEART_ENDPOINT,CRONHEART_ALLOW_INSECURE_ENDPOINT) for staging, private or local deployments.
- First release: site heartbeat, per-event monitoring through
cronheart_monitor()and constants, the Settings → Cronheart page, and the PHP fatal error in the fail ping.