Mautic cron jobs: which commands to run and in what order

A fresh Mautic install with no cron configured looks like it works. The interface loads and contacts come in, and you can even draw campaigns. Then nothing happens: emails stay unsent, segments never update and leads sit in the middle of the flow. Mautic cron jobs are the engine that executes everything you configure, and the order they run in (segments, then campaigns, then sending) matters as much as the fact that they run at all.

What cron is and why Mautic depends on it

Cron is the Linux task scheduler. It runs commands at intervals you define. Mautic depends on it because it is a queue-based application: instead of processing each action the instant an event happens (which would need a process running all the time), it collects the work and handles it in batches whenever the matching command is called.

In practice, there is always a gap between the event (a lead fills in a form) and the action (the welcome email goes out). That gap equals the cron interval, which is why the most time-sensitive commands run on short intervals. Schedule these commands in the operating system crontab, not in any scheduler inside Mautic itself. The system crontab is more reliable, keeps running when nobody is using the application, and does not need a web request to fire.

The essential Mautic cron jobs, in the right order

Three commands make up the core of the automation. The order between them is fixed, because each one uses the result of the one before.

1. mautic:segments:update updates the segments

This command recalculates which contacts belong to each dynamic segment by applying all the configured filters. A contact who just reached the score for a VIP segment only joins it after this command runs. Everything else builds on it, so it goes first.

php /var/www/mautic/bin/console mautic:segments:update --no-interaction

2. mautic:campaigns:rebuild recalculates campaign membership

The rebuild looks at the segments and forms that feed each campaign and adds or removes contacts based on what changed. A lead who entered a source segment only starts moving through the flow once the rebuild adds them to the campaign, and the rebuild only sees that change if segments:update has already run. That makes it second. (Current versions also expose this command as mautic:campaigns:update.)

php /var/www/mautic/bin/console mautic:campaigns:rebuild --no-interaction

3. mautic:campaigns:trigger fires the campaign actions

This one executes the scheduled actions in your automation flows. It queues campaign emails, applies tags, adjusts points and moves contacts through decisions. It acts on the contacts the rebuild already placed in each campaign, so it runs third. If you are still building those flows, the guide to Mautic campaigns covers the campaign side.

php /var/www/mautic/bin/console mautic:campaigns:trigger --no-interaction

4. mautic:emails:send flushes the email queue

When you set sending to queue (spool) mode, Mautic does not deliver emails right away. It holds them in a queue, and this command dispatches them to SMTP. So campaigns:trigger puts the email in the queue and emails:send sends it. Without queue mode, sending is synchronous and you can skip this job, but on any real volume the queue is what keeps the interface from freezing.

php /var/www/mautic/bin/console mautic:emails:send --no-interaction

Maintenance and optional cron jobs

Beyond the core, a few commands keep things healthy. Not every install needs all of them:

• mautic:email:fetch: connects to the monitored inbox and processes bounces and replies. You need it to keep the list clean and protect your domain reputation. (Note that the sending command is emails:send, plural, while the reading command is email:fetch, singular.)
• mautic:broadcasts:send: sends scheduled segment (broadcast) emails.
• mautic:messages:send: processes the queue of scheduled marketing messages.
• mautic:webhooks:process: flushes the webhook queue when webhooks run in queue mode.
• mautic:import: runs large imports in the background.
• mautic:iplookup:download: updates the GeoIP (MaxMind) database used to locate contacts.
• mautic:maintenance:cleanup: deletes old event logs and tracking data so the database does not grow without limit. It accepts --days-old to set the cutoff.

How to set up Mautic cron jobs in the Linux crontab

Edit the crontab of the user that runs Mautic (usually www-data on Debian and Ubuntu). Editing another user's crontab needs elevated privileges, so use sudo:

sudo crontab -u www-data -e

Paste the lines below. The core minutes are staggered (0/15/30/45, then 5/20/35/50, then 10/25/40/55) to follow the dependency order. Each command runs inside flock -n, which stops a new run from starting while the previous one is still going. All output goes to a dedicated log.

# Core, staggered to respect the order: segments -> rebuild -> trigger
0,15,30,45 * * * * flock -n /tmp/mautic-segments.lock /usr/bin/php /var/www/mautic/bin/console mautic:segments:update --no-interaction >> /var/log/mautic-cron.log 2>&1
5,20,35,50 * * * * flock -n /tmp/mautic-rebuild.lock /usr/bin/php /var/www/mautic/bin/console mautic:campaigns:rebuild --no-interaction >> /var/log/mautic-cron.log 2>&1
10,25,40,55 * * * * flock -n /tmp/mautic-trigger.lock /usr/bin/php /var/www/mautic/bin/console mautic:campaigns:trigger --no-interaction >> /var/log/mautic-cron.log 2>&1

# Email queue sending
*/5 * * * * flock -n /tmp/mautic-emails.lock /usr/bin/php /var/www/mautic/bin/console mautic:emails:send --no-interaction >> /var/log/mautic-cron.log 2>&1

# Maintenance
*/15 * * * * flock -n /tmp/mautic-fetch.lock /usr/bin/php /var/www/mautic/bin/console mautic:email:fetch --no-interaction >> /var/log/mautic-cron.log 2>&1
0 4 1 * *   /usr/bin/php /var/www/mautic/bin/console mautic:iplookup:download --no-interaction >> /var/log/mautic-cron.log 2>&1
0 2 * * 0   /usr/bin/php /var/www/mautic/bin/console mautic:maintenance:cleanup --days-old=365 --no-interaction >> /var/log/mautic-cron.log 2>&1

Always use the full path to PHP and to the console. Cron does not inherit the environment variables from your shell, so a bare php may not even be found. Get the path with which php (it is usually /usr/bin/php or something like /usr/bin/php8.1) and point to the full console path too (/var/www/mautic/bin/console). The --no-interaction flag keeps a command from waiting for a confirmation that will never come.

If you are on shared hosting with cPanel, its cron scheduler runs the same bin/console commands. You enter the interval in a web form instead of the terminal, and you should check which system user runs the scripts so the Mautic file permissions match. If you have not installed Mautic yet, the walkthrough on how to install Mautic covers the server side first.

How to check that your Mautic cron jobs are running

After saving, confirm the commands are actually executing:

• sudo crontab -l -u www-data shows exactly what you scheduled.
• tail -f /var/log/mautic-cron.log follows each run in real time.
• tail -f /var/www/mautic/var/logs/mautic_prod.log shows internal activity and any errors.
• In the admin panel, the system log under Settings shows the same records from inside the interface.
• For an end-to-end test, add a contact to a campaign's source segment and wait a few minutes. The welcome email should arrive within the window of your configured intervals.

Mautic has no native dashboard for monitoring cron. To get alerted when a command stops running, use an external service such as Healthchecks.io or Cronitor and add a curl call with the ping URL to the end of each cron line. Each job pings when it finishes, and you get an alert when a ping fails to arrive on time.

When actions run late

The minimum delay always equals the cron interval. With a 15-minute schedule, an action can take up to 15 minutes to happen. If the delay is longer than the interval, usually one run had not finished when the next one started, or the command hit the PHP memory limit. The flock wrapper handles the first case, and the Mautic log will show the second.

Recheck your Mautic cron jobs every time you upgrade or touch the server. A major release like Mautic 7 raises the PHP requirements, so if the PHP binary path changes after an upgrade, update it in every crontab line and watch the logs.

You only need all of this on self-hosted Mautic. On the hosted version (Mautic Cloud, at mautic.com) the platform runs the infrastructure, cron included. For the full command reference, see the official Mautic cron jobs documentation.

Mautic cron jobs FAQ

In what order should Mautic cron jobs run?

Run mautic:segments:update first, then mautic:campaigns:rebuild, then mautic:campaigns:trigger. Segments have to be current before the rebuild decides who enters each campaign, and the rebuild has to finish before the trigger fires the actions. Staggering the minutes, as in the crontab above, keeps that order without one command running over another.

Can I use the cPanel scheduler instead of the Linux crontab?

Yes. It runs the same commands. On a VPS with root access, though, the terminal crontab is still the more reliable and transparent option.

Do I need cron jobs if I use hosted Mautic?

No. Cron configuration through crontab only applies to self-hosted Mautic, where you run your own server.

Does Mautic have a dashboard to monitor cron jobs?

No. Use an external ping service such as Healthchecks.io or Cronitor, as described in the section on checking your jobs.