hamzanaimat

The date on that hook is the useful part. mailpoet/cron/daemon-trigger last ran on 22 July, so whatever broke, broke then — everything since is the backlog growing behind it.

That hook is a self-rescheduling one: each run is what queues the next run. Nothing else re-arms it. So a single run that dies — a fatal, a timeout, a blocked request — stops the chain permanently, and nothing in the logs says “I have stopped”, because the thing that would have written the next entry is the thing that died. That is why it can sit for six weeks looking like a scheduling problem when it is really one failed run in July.

Two things to separate first, because they have opposite fixes. Press Run on one past-due action in WooCommerce → Status → Scheduled Actions. If it completes, the jobs are fine and nothing is triggering the queue. If it errors, the job is broken — and your 6 failed are already that kind, so no cron change will clear those.

Then re-arm MailPoet: MailPoet → Settings → Advanced → “Newsletter Task Scheduler”. MailPoet’s own troubleshooting for this is to set it to the WordPress built-in cron option. If it is currently on the server/Linux cron setting and that cron was changed or removed at some point, that matches exactly what you are seeing — a hard stop on one date and nothing since. Switching it makes MailPoet schedule a fresh trigger instead of waiting on the dead one.

The database version mismatch you were told about is worth doing too, but it is separate — WooCommerce → Status → Tools → Update database. It will not restart MailPoet’s daemon.

Worth knowing before you chase this on the mail side: subscriber notifications do not go out through your site’s own mail. Jetpack sends them from its servers, so SMTP settings, WP Mail SMTP and your host’s mail logs are all the wrong place to look — they will show nothing either way.

What actually triggers the send is the post transitioning to published. Three things break that, in rough order of likelihood:

1. The post was scheduled and published late by a missed-schedule recovery rather than at its scheduled moment. Posts that arrive that way frequently do not fire the notification.
2. Jetpack → Settings → Newsletter has the subscription setting switched off, or the post was published while the connection was broken.
3. The post is in a category or format excluded from notifications.

Quickest test: publish a short post immediately, not scheduled, and see whether it goes out. If an immediate publish sends and a scheduled one does not, it is the missed-schedule path and the fix is a real cron rather than anything in Jetpack.

You have two separate problems in that list, and they need opposite fixes — worth splitting them before you change anything.

Go to WooCommerce → Status → Scheduled Actions and press Run on one past-due action. If it completes, the job itself is fine and nothing is triggering the queue automatically — that is a scheduling problem. If it errors, the job is broken and no amount of cron work will help.

Your failed ones are already the second kind. Open the Failed tab: it names the hook, and the hook name tells you which plugin owns it. That is the one to chase, because failed actions never retry on their own.

For the past-due ones, the moderator is right that it is usually loopback. WP-Cron works by your server making an HTTP request back to your own site at /wp-cron.php; if a firewall, a security plugin or your host blocks that, the queue silently never runs. Tools → Site Health names a failed loopback request explicitly.

Do not bulk-delete the 97. Deleting them removes the evidence and the jobs still never ran.