Short answer
WordPress 6.5 changed Site Health notifications from one email per failing test to a single aggregated digest. Aggregation applies only to tests whose status is recommended or critical; good and informational results are excluded. The digest is sent on the WP-Cron schedule (default interval of 86400 seconds, i.e. once per day), which means critical alerts are no longer immediate. There is no settings UI in 6.5 — behavior is controlled through filters, and the default preserves the new digest behavior unless a site explicitly opts out.
Which tests belong in the digest?
The sensible criterion — and the one core uses — is severity. Only results that demand administrator action (critical and recommended) generate mail at all; passing tests never did. Within that, a reasonable refinement is to treat the two tiers differently:
- Critical results justify faster delivery, because they often indicate security or breakage risk (e.g., outdated PHP, missing security updates).
- Recommended results are the main source of noise and are the best candidates for daily aggregation.
If you want per-test control, you can filter the results array before the digest is built — the email is constructed from the collected test results, so removing low-priority tests in a filter effectively suppresses them from the message.
Effect on timeliness of critical alerts
This is the real trade-off. Because the digest waits for the next scheduled cron run, a critical issue can sit unreported for up to the notification interval (24 hours by default). Two mitigations:
- Shorten the interval with the
wp_site_health_email_notification_interval filter (the value is in seconds).
- If you truly need immediate critical alerts, disable aggregation and return to per-test emails, accepting the noise, or route critical monitoring to an external tool (uptime monitor, error tracker) rather than email.
// Send the digest every 6 hours instead of daily.
add_filter( 'wp_site_health_email_notification_interval', function() {
return 6 * HOUR_IN_SECONDS;
} );
Opt-in vs. default, and backward compatibility
Core shipped this as a behavior change with no settings screen, so the "default" is digest mode for everyone. Backward compatibility is preserved in the sense that administrators still get notified of the same issues — just batched — and the escape hatches are code-level:
- Return
false from the aggregation-enabled filter to revert to individual emails.
- Define the
WP_DISABLE_SITE_HEALTH_EMAILS constant to silence Site Health mail entirely.
If a settings UI were added, the backward-compatible default would be digest-on (matching 6.5 behavior), with a checkbox for per-test emails. Changing the default back to individual emails in a later release would itself be a second breaking change.
Caveats and verification
Three things to check before relying on the digest:
- WP-Cron health. If cron is disabled or broken, the digest never sends and you get silence, not errors. Confirm cron runs (e.g., via WP-CLI:
wp cron event list).
- Plugin hooks. Plugins that hooked the old per-test email path may not fire under aggregation; audit any custom notification plugins.
- Live test. Trigger a recommended/critical result (for example, flag an outdated component) and confirm you receive one combined email rather than several.
Version assumption: this describes WordPress 6.5 behavior; verify against the release notes and wp-admin/includes/class-wp-site-health.php on your exact version, as filter names and defaults can change in later releases.
wordpress