How to Configure Cron Jobs in Mautic
Configuring cron jobs in Mautic means scheduling the core console commands in the right order so segments refresh, campaigns pick up the right contacts, and campaign actions actually run when they should. It matters because Mautic does not process that background work just because the UI is open – if cron is missing, misordered, or pointing to the wrong PHP binary, automations look fine on screen but stall in production.
Why cron jobs are mandatory in Mautic
Mautic depends on a fixed background sequence of segment refresh, campaign refresh, and campaign execution, and that sequence is what turns saved rules into actual automation. In practice, the system first needs to recalculate who belongs in a segment, then update who belongs in a campaign, and only after that can it process campaign actions for the contacts now eligible.
That order matters more than many teams expect. A common issue is assuming a contact who just submitted a form will immediately hit the next campaign step. What typically happens instead is that nothing moves until the relevant cron cycle runs, and if the jobs are out of order, the later job is working with stale membership data.
The 3 core Mautic cron jobs every working setup needs
`mautic:segments:update`
This job refreshes dynamic segment membership. If a segment is built from filters such as email activity, form submissions, tags, or field values, this is the command that recalculates who belongs there.
In practice, this is the first dependency in the chain. If segment membership is out of date, campaign membership will also be wrong, even if the campaign itself is configured correctly.
`mautic:campaigns:update`
This job updates campaign membership after the segment layer has been refreshed. If a campaign uses a segment as its source, this is the step that adds newly eligible contacts into the campaign and removes contacts who no longer qualify.
What typically happens in real deployments is that people focus on the campaign builder and forget this handoff layer. The campaign may be published, the segment may be correct, and yet no one enters the flow because the campaign update job is not running.
`mautic:campaigns:trigger`
This job executes due campaign events. Once a contact is in the campaign and reaches a scheduled action, this is the process that handles the actual event when its time arrives.
A common issue is treating this as optional because the first two jobs already “updated” everything. They did not. They only prepared the contact state. The trigger job is what processes the action itself.
How to write the cron commands
Every cron entry should call the PHP CLI binary and the full path to Mautic’s `bin/console` file. The command pattern is straightforward:
/path/to/php /path/to/mautic/bin/console mautic:segments:update
/path/to/php /path/to/mautic/bin/console mautic:campaigns:update
/path/to/php /path/to/mautic/bin/console mautic:campaigns:triggerIf you are adding them to a system scheduler, the cron expressions sit in front of those commands. A staggered pattern is usually safer than firing all three at the exact same minute:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /path/to/php /path/to/mautic/bin/console mautic:segments:update
1,6,11,16,21,26,31,36,41,46,51,56 * * * * /path/to/php /path/to/mautic/bin/console mautic:campaigns:update
2,7,12,17,22,27,32,37,42,47,52,57 * * * * /path/to/php /path/to/mautic/bin/console mautic:campaigns:triggerThe exact minute pattern is less important than the sequence. In practice, giving each job a small gap reduces the chance that campaign updates start before segment updates have finished.
Linux, VPS, and shared hosting behave differently
On a VPS or dedicated server
A server you control is usually the simplest case because you can schedule the commands directly in cron and choose the exact PHP binary. Even then, path mistakes are common. What typically happens is that `php` works in an interactive shell, but cron uses a different environment, so the job fails when it cannot find the expected binary or the console file.
Using absolute paths avoids most of that ambiguity. It also makes troubleshooting easier because you know exactly which executable and which Mautic installation the scheduler is calling.
On shared hosting or cPanel
Shared hosting adds another layer because the scheduler often expects a host-specific PHP path rather than a plain `php` command. What typically happens on those setups is that the job needs a full PHP CLI path and an absolute path to the console command, especially when the control panel and the website are not using the same PHP entry point.
A common issue is creating a URL-based cron because the hosting panel makes that look easier. Mautic’s scheduled automation is built around console commands, so a proper CLI command is the safer and more predictable setup.
How often to run Mautic cron jobs
Cron frequency is a trade-off between freshness and server load. Short intervals make segment changes and campaign actions feel more immediate. Longer intervals reduce process churn, but they also make automation timing drift because Mautic can only process work when the next scheduled run starts.
In practice, the practical breakdown of core versus optional scheduled tasks reinforces a useful rule: keep the three core campaign jobs running reliably first, then add feature-specific jobs only when the related features are actually in use. That matters because many slow or unstable setups are not failing because Mautic “needs more cron” – they are failing because too many unnecessary jobs were added before the baseline jobs were stable.
A common issue is running all three core jobs at the same exact minute. That looks tidy in a cron table, but it can create overlap. If `segments:update` is still busy when `campaigns:update` starts, campaign membership may lag behind by a cycle. The same applies to `campaigns:trigger` starting before the campaign update pass has finished.
Practical scheduling logic that avoids stale data
Keep the jobs in sequence
The safest logic is simple:
- Update segment membership
- Update campaign membership
- Trigger campaign actions
That sequence mirrors how data actually moves through Mautic. If you reverse it, the later stages have nothing reliable to act on.
Leave enough time between jobs
You do not need huge gaps, but you do need some separation if the database is busy or segment rules are complex. In practice, larger contact volumes, more segment filters, and heavier campaign logic all increase the chance that overlapping jobs will slow each other down.
What typically happens on smaller systems is that everything finishes quickly enough that overlap is not obvious until activity grows. Then delayed sends, inconsistent campaign entry, or “why didn’t this contact move?” tickets start appearing even though the cron table technically exists.
Match expectations to cron reality
If a campaign action is meant to happen at a specific time, cron cadence still controls the real execution window. A common issue is expecting exact, wall-clock precision from a scheduler that only checks work periodically. Mautic will process the action on the next available trigger cycle, not continuously in the background.
Optional cron jobs depend on the features you use
Once the core three jobs are stable, the rest of the cron setup depends on which parts of Mautic are active in the environment. Broadcast sending, monitored inboxes, and other background features typically need their own scheduled processing rather than relying on the campaign jobs alone.
In practice, this is where overconfiguration starts. Teams often copy a long list of cron commands from another install without checking whether those features are enabled. That adds noise, wastes resources, and makes troubleshooting harder because there are more moving parts than the setup actually needs.
The more reliable approach is to start with the essential campaign flow, confirm it works end to end, and then add only the extra scheduled tasks required by the features in production.
Common Mautic cron job mistakes
Running the commands out of order
This breaks the data flow. Segment changes need to happen before campaign membership updates, and campaign membership needs to exist before triggers can process actions.
Using incomplete paths
Relative paths are fragile in cron. A common issue is that the command works when pasted into a shell from the Mautic directory, but fails in the scheduler because cron runs from a different working directory.
Scheduling everything at the same time
This increases the chance of overlapping processes and stale results. In practice, even a one-minute offset between core jobs can make the flow more predictable.
Assuming the UI will compensate for missing cron
It will not. You can publish campaigns, build segments, and create actions in the interface, but the actual background processing still depends on the scheduler.
Forgetting that optional features may need their own jobs
Core campaign automation is not the same thing as every other background process in Mautic. What typically happens is that one feature appears broken when the real issue is simply that its related cron task was never added.
A practical way to validate the setup
The easiest way to think about validation is to follow the same chain as the cron jobs themselves. First, check whether contacts are entering the right segments. Then check whether those contacts appear in the expected campaigns. Then check whether campaign actions begin firing after the next trigger cycle.
If the first step works but the second does not, the problem is usually around campaign update scheduling. If the first two work but actions do not fire, the trigger layer is the likely gap. In practice, breaking the process into those three checkpoints is much faster than staring at the campaign builder and guessing.
Share With Others
