No-activity alerts, digests, or reminders are not arriving

Troubleshoot WordPress cron, feature settings, effective recipients, licence state, and mail delivery for scheduled messages.

Written By Kelsey

Last updated About 1 month ago

No-activity checks, weekly digests, post-launch reminders, and automatic expiry depend on WordPress scheduled events. They also depend on an active Always Alert licence and the site’s existing mail transport.

1. Confirm the feature is enabled

Go to Always Alert → Monitoring and check:

  • No-activity alerts are enabled and have a suitable threshold.

  • Weekly digest is enabled.

  • Post-launch monitoring is active and has not expired.

  • The relevant direct recipient is valid, or the fallback recipient is valid when the direct field is blank.

Save Monitoring Settings after corrections.

2. Confirm Always Alert is running

Open Always Alert → Dashboard.

Fallback injection and scheduled monitoring are paused when the licence is inactive or Always Alert is disabled. Resolve any setup or licence notice before continuing.

3. Read the dashboard schedule cards

Review the WordPress scheduled-events and feature cards. Look for:

  • a future scheduled run;

  • the most recent check or send;

  • a feature that is off, expired, or waiting for its next cron tick;

  • a recipient shown as coming from the fallback setting.

WordPress cron is traffic-driven by default. A quiet site may run scheduled tasks late unless the host calls wp-cron.php from a real server cron.

4. Confirm the no-activity condition is actually met

The alert only becomes relevant after no eligible activity has been observed for the configured period. Excluded or unrelated WordPress mail does not reset the eligible-activity clock.

If the threshold is seven days, do not expect an alert after a shorter quiet period.

5. Check the activity log

Review Always Alert → Logs for monitoring checks, sends, failures, and expiry events. The status and reason can show whether the scheduler ran and whether WordPress accepted an operational email.

6. Test the underlying mail transport

Run Always Alert → Tools → Send Handoff Test.

If the test fails, investigate SMTP credentials, provider connectivity, host restrictions, and the site’s mail plugin.

If the test succeeds but scheduled messages do not arrive, inspect the provider log and receiving mailbox for rejection, suppression, spam, quarantine, or rules.

7. Check WordPress cron

Use your host’s cron tools, WP-CLI, or a trusted cron-inspection plugin to confirm WordPress scheduled events are running.

Common causes include:

  • DISABLE_WP_CRON is enabled without a replacement server cron;

  • the site receives too little traffic to trigger timely runs;

  • loopback requests are blocked;

  • a security or hosting rule blocks wp-cron.php;

  • a fatal error interrupts a cron request;

  • the site’s timezone or clock is incorrect.

Correct the cron system rather than repeatedly toggling the monitoring setting.

8. Re-test after correction

Confirm the dashboard shows future schedules, run a controlled form submission, and review the next expected digest or reminder window. For a no-activity feature, use a safe staging test or temporarily selected threshold rather than manufacturing a misleading production outage.

Related articles