A complete guide with all the Mautic cron job setups you need so your Mautic runs perfectly in your VPS installation.
Setting up the right sequence of Mautic cron jobs
Although Mautic doesn’t normally allocate many server resources it’s still extremely important to plan the execution of Mautic cron jobs in the right sequence in order to avoid locking and cron job conflicts during Mautic cron job execution.
All the Mautic documentation suggests you avoid running multiple cron jobs at the same time.
I have been working exclusively with Open Source systems for many years, obviously one of the reasons I was drawn to Mautic was the low acquisition costs and the many advantages that this environment can provide,, such as analyzing, changing and even correcting bugs in the source code.
After an analysis of the Mautic source code, I understood that the right cron jobs sequence is fundamental for running all the outstanding Mautic features such as:
- List Updates;
- Campaign Updates;
- Campaign Executions;
- E-mail Processing;
- Monitored Mailbox Processing;
- Processing IP base updates;
- Removing old data from the Mautic Database.
Understand which Mautic Cron Jobs are the most important
Mautic has an extensive list of commands that can be used for database maintenance, cache cleaning, and platform updating; I listed the main Mautic commands that can be used as cron Mautic below:
Cron job to update Lists / Segments in Mautic
This is the first mautic cron that we configure because it is responsible for updating our smart lists/segments that have filters.
Remember that Mautic processes 300 leads by performing this task and you can increase or decrease this number of contacts depending on the features available on your server.
See the default setting for updating lists below:
php app/console mautic:segments:update
You can increase the number of leads by running this cron with the -batch-limit = X parameter, as follows:
php app/console mautic:segments:update --batch-limit=500
Cron jobs setup for Campaigns
Note that the Mautic separates this functionality in two crons: one is responsible for adding the leads in the campaigns (mautic:campaigns:update) and another is responsible for performing the necessary actions with these leads inside Mautic campaigns (mautic:campaigns:trigger).
Now, we have to set up the cron job responsible for inserting a lead into a specific campaign.
Remember that Mautic processes 100 events by performing this task and that you can increase or decrease this number of contacts depending on the features available on your server.
Here’s the default command for the campaign update task:
php app/console mautic:campaigns:rebuild
You can increase the number of events processed by executing this task with the paramenter –batch-limit=X, like this example below:
php app/console mautic:campaigns:update --batch-limit=200
Executing Campaign Events
Now we go to the second step which is the task of executing the decisions and events within the campaign.
Here’s the default command for the campaign execution task:
php app/console mautic:campaigns:trigger
You can increase the number of events processed by executing this task with parameter –batch-limit=X, like this example below:
php app/console mautic:campaigns:trigger --batch-limit=200
Cron Job for Batch E-mailing in Mautic
If you use the queue feature in Mautic to send email batches, you must also be sure to set up this task below:
php app/console mautic:emails:send
This will empower Mautic with the ability to send the emails that are in the queue according to the settings made in the panel itself.
Cron Job for Sending Scheduled Reports
If you schedule reports to be sent to clients, partners, etc., you should set up a cron responsible for generating and sending the scheduled reports in the background:
php app/console mautic:reports:scheduler
This Mautic feature is incredible for your customers and employees. It allows them to get an idea of how fluid your Digital Marketing is.
Mautic Cron to Deliver Scheduled Broadcast Emails
This task is responsible for sending the scheduled broadcast emails. These emails are not part of a campaign and may have a date / time to start sending. The basic cron for this command is:
php app/console mautic:broadcasts:send
Optional: This command also allows the –channel parameter where we can specify the channel we will use and –id where we specify the id of a specific channel. For now the –channel parameter only accepts the email value. See the complete command:
php app/console mautic:broadcasts:send --channel=email --id=X
Where x is the ID of your broadcast e-mail.
Setting up Large Scale Delivery on Mautic
The command mautic:broadcasts:send allows fine tuning for those marketers who send large-scale emails. Here at Powertic we have professionals specialized in solving most of the problems of reputation, monitoring and performance of deliveries and Mautic allows you to make some very interesting adjustments:
The –limit=X parameter describes how many contacts will be added to the command at each run. By default, Mautic includes 100 contacts which means that with each execution of the mautic command:broadcasts:send 100 contacts are processed and the next execution gets 100 more contacts and so on.
The –batch=X parameter informs the batch size of processed emails that will be sent to the Email Delivery Provider (remember that each provider has a limit). Sparkpost, for example, allows 1000 emails to be sent to each call in the API while SMTP usually allows 10 emails to be sent per batch.
mautic:broadcasts:send –min-contact-id=X –max-contact-id=X
These parameters allow you to enter a range of contacts so you can run parallel commands. This way you prevent repeat emails from being sent and increase the flow of emails for large submissions. You can have, for example, a cron that sends to contacts with IDs from 1 to 50000 and another parallel command that sends for 500001 to 100000.
Mautic Cron for sending Marketing Messages
When a “Marketing” campaign email is triggered or a broadcast email (segment email) and a contact has a defined frequency rule or there is a default set in the Mautic Settings, email can be sent to a queue to be processed.
Messages are queued with pending status, so any pending messages that have not reached the maximum number of retries will be processed using this command.
php app/console mautic:messages:send
It is highly recommended to use this command with the same frequency of sending mautic:broadcasts:send
Cron Mautic for Monitoring Bounces on Mautic
Mautic provides an incredible Bounces Monitoring feature that allows you to mark a lead as rejected after a hard-bounce. This functionality also has a unique cron job.
To configure the task responsible for monitoring bounces use the command:
php app/console mautic:email:fetch
This command performs a scan on your monitored inbox to find return emails. Although very useful it consumes a lot of server resources. I recommend using this command with caution in well-spaced time intervals.
Cron Mautic for Importing Contacts in the Background
Mautic offers a command to perform the import of contacts in the background, excellent for those who need to import a large number of contacts but have encountered problems with timeout.
To configure the task responsible for importing contacts in the background, use the command:
php app/console mautic:import
This command may take some time to execute depending on the number of contacts in the CSV file. In any case, you will receive a notification in the Mautic Dashboard when the import is complete.
Mautic Cron for Removing Old Mautic Data
Mautic update 2.1.0 introduced a new maintenance command feature called maintenance:cleanup. This command erases data from anonymous leads that are older than 365 days. This eliminates useless data from our database and consequently improves the performance of the tool.
This command removes log entries, IP, user notifications, visit history from Anonymous lead pages. Leads that have already been identified in your database will not be affected.
See the basic command example:
php app/console mautic:maintenance:cleanup
This command returns an output on the command line that informs which data has been deleted:
| Record type | Records affected |
| Audit log entries | 0 |
| UTM tag history | 0 |
| User notifications | 0 |
| Visitor page hits | 0 |
| Visitors | 0 |
By running the command with the
--dry-run parameter you can perform a test before actually deleting the data.
This is our recommendation when you’re not sure what you’re doing 😉
php app/console mautic:maintenance:cleanup --dry-run
The command has another parameter where we can specify the number of days that we want to keep in our database (by default the command uses 365 days)
php app/console mautic:maintenance:cleanup --days-old=90
In the example above, Mautic will erase all anonymous data older than 90 days
Important: If you use this command through a cron task, you must apply the –no-interaction parameter, otherwise the command will always request confirmation before execution.
Here’s an example of the command to use in CRON:
php app/console mautic:maintenance:cleanup --days-old=365 --no-interaction
We already know the main CRON tasks of Mautic, so let’s go to the next step: “divide and conquer“!
Configuring cron of Mautic Integrations (plugins)
Mautic has four commands to perform the synchronization of all integrations. I recommend using all of these commands every 5 minutes interleaving, ie do not run these commands at the same time. See the commands below:
These commands work with the Zoho CRM plugins, Hubspot, etc.
If you use multiple integrations and you are encountering performance issues running all of them at the same time, you can specify which integration should be performed by adding the –integration suffix to the command.
Cron Mautic Hubspot Integration
See below for cron for integration of Mautic with Hubspot:
Cron Mautic Salesforce Integration
See below for cron for integrating Mautic with Salesforce:
Cron Mautic Intigration for SugarCRM
See below for integration of Mautic with Sugarcrm to synchronize all leads:
mautic:integration:fetchleads --fetch-all --integration=Sugarcrm
Cron Mautic Integration for Pipedrive CRM
Here are the commands for integrating Mautic with Pipedrive:
Cron Mautic Integration for Zoho CRM
See below for integration of Mautic with ZohoCRM to synchronize all leads:
Cron Mautic Integration for Dynamics CRM
See below for integration of Mautic with Dynamics CRM to synchronize all leads::
php app/console mautic:integration:fetchleads -i Dynamics
Configuring the Mautic Cron
Now that we know the order of execution of the cron tasks of Mautic we must create a schedule so that during the period of 1 hour each task is executed completely in order and giving space so that the subsequent one can be executed completely also and thus to avoid run-overs or simultaneous executions.
Remember that one task will only run over another if you use the –force parameter. If Mautic attempts to start a task while the other is still running without the –force parameter the new task will wait until the last task has finished executing.
It will all depend on you manually performing the task and seeing how long it takes for it to run, in addition to the number of concurrent tasks from the other Mautic installations within your server.
Depending on the size of your base of leads, the amount of lists and number of campaigns in your installation of mautic, the correct approach can significantly increase Mautic’s performance on your server.
Scenario 1: Execution Schedule in a Large List
We use this approach in installations with more than 5 thousand leads. With this we unload the application server, the database server and also the service responsible for sending the emails (Amazon SES) since over the space of 1h we perform several executions with low load.
Remember that in a perfect scenario you must process your entire base of leads / lists / campaigns within 1 hour.
Here is an example of an installation where we have over 6,000 leads where we perform all cron tasks 2 times per hour:
|0||IP Lockup Download||–||–|
|1||Segment Update||3 min||1|
|5||Campaign Update||3 min||2|
|10||Campaign Execution||4 min||3|
|15||Email send||10 min||4|
|25||Monitored Email Read||5 min||5|
|30||Segment Update||3 min||1|
|35||Campaign Update||3 min||2|
|40||Campaign Execution||4 min||3|
|45||Email Send||10 min||4|
|50||Monitored Email Read||5 min||5|
|55||IP Lockup Download||–||–|
So we can distribute the execution of the CRON tasks within one hour without overloading the server and making sure that the following tasks are ready to run without running over.
Scenario 2: Execution Schedule on a Small List
We use this approach for installations with fewer than 5,000 leads. Thus we can have a less spaced-out execution since they take less time to complete.
The general rule for performing cron tasks well is to prevent them from running at the same time.
In smaller lists we use the following schedule:
|0||IP Lockup Download||–||–|
|1,10,20,30,40,50||Segment Update||1 min||1|
|2,12,22,32,42,52||Campaigns Update||2 min||2|
|4,14,24,34,44,54||Campaigns Execution||2 min||3|
|7,17,27,37,47,57||Email Send||3 min||4|
|9,19,29,39,49,59||Monitored Email Read||2 min||5|
This one gets a bit complicated, but let’s go:
Mautic recommends that you do not run cron jobs at the same time. So we create “spaces” of time for a task to be executed and then we run the next task. As each task takes an average of 2 minutes to execute and we have 5 different tasks each task will be executed every 10 minutes.
Weekly we run “on hand” every cron task of each installation we manage to see the log of the executions. Often Mautic “hangs” an execution at a certain point and the fix is to include the –force flag to the command like this:
Leave us your comments, questions or suggestions. Soon I will write more articles on configuration and management of the server.