Fix MailWizz Cron Problems

The Problem

Campaigns are stuck in "sending" or never leave "draft" because one or more of the cron tasks MailWizz depends on isn't running — often invisible unless you know exactly where to look.

About this problem

When MailWizz cron jobs that used to work suddenly stop — campaigns stuck in "sending" or never leaving "draft" — the cause is typically a changed PHP CLI path after a server update, a permissions change, or a cron entry that silently stopped running without any obvious notification anywhere.

This is distinct from setting cron up for the first time — it's specifically for a previously working setup that's broken.

What's Included

• Auditing every existing cron entry related to MailWizz
• Fixing broken paths, permissions or PHP CLI version issues in the cron commands
• Re-testing each cron task individually
• Confirming a real campaign now sends end to end

What's NOT Included

• Setting up cron from scratch on an install that never had it (see "Configure MailWizz Cron Jobs")
• Non-MailWizz cron jobs on the same server
• Rewriting MailWizz's own cron scripts

How It Works

1. Audit every existing MailWizz-related cron entry currently configured on the server.
2. Check for broken PHP CLI paths, permission issues, or outdated commands causing silent failures.
3. Fix or recreate the broken entries with the correct paths and permissions.
4. Re-test each cron task individually to confirm it executes successfully on its own.
5. Run a real campaign through to completion to confirm the fix holds end to end.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

Why did my MailWizz cron jobs stop working after a server update?

Server updates sometimes change the PHP CLI binary path or version, which breaks cron entries that reference the old path — a very common trigger for previously working cron suddenly failing silently.

How do I check if a MailWizz cron job is actually running?

Checking the crontab shows it's scheduled, but confirming it executes successfully requires checking cron logs or MailWizz's own queue processing behaviour.

Can a permissions change break MailWizz cron jobs?

Yes — if file or folder permissions change (often after a backup restore or server migration), cron tasks can silently fail to read or write the files they need.

Why do some MailWizz cron tasks work but not others?

Each cron entry is independent, so a path or permission issue specific to one task's files won't necessarily affect the others — which is why auditing all of them individually matters.

Will fixing broken cron jobs recover campaigns stuck mid-send?

Usually yes — once cron is running correctly again, previously stuck campaigns typically resume processing from where they left off.

How often do MailWizz cron problems happen?

Most commonly right after a server-level change (PHP update, migration, permissions change) rather than spontaneously — which is often the first thing worth checking when cron stops working.