Skip to content

Mautic Step 2 – Cron Jobs

Dear Reader,

This is the third post on “My Journey into Mautic”. I’m getting Mautic – a Marketing Automation Tool – setup and running on my own server. Along the way I’m sharing what I’ve learned in hopes that it helps someone, or at least helps me the next time I go down the road.

Maintaining Mautic from the command line

This time we are talking about the cron jobs necessary to make Mautic run. Mautic has several commands that are necessary to execute that are not web based. They are run from the command line manually (dumb idea) or using a scheduler like cron on Linux. As with my “Installing Mautic” post, this post is only interesting to those of you self-hosting Mautic.

There is a great manual page on this titles “Cron Jobs”. It tells you a lot of what I’ll tell you here. If you haven’t read it yet, I highly recommend you start there.

The jobs

There are 4 main cron jobs that need to run. All of them are commands build on top of the symfony/console package. Symfony/console is my favorite package to install from packagist. Most of my projects are run form the cli and I use symfony/console for all of them. The heart of the Mautic console commands is app/console. So all of the commands look like this:

$ php /path/to/mautic/app/console mautic:command

You need to locate the app directory on your installation and adjust the examples accordingly.

The 4 jobs that you need to run regularly are:

  • mautic:segments:update
  • mautic:campaigns:rebuild
  • mautic:campaigns:trigger
  • mautic:messages:send

The last one is necessary if you are using Mautic to send out marketing campaigns. Currently, I am not, I’m still fighting with the MailChimp integration in hopes of making that work instead. However, I have this one enabled anyhow.

My current install for Mautic is very low volume. I think there are currently 10 contacts in the DB. Even so, the manual recommends that you stagger the jobs so that they don’t all run at once. They recommend the following.

0,15,30,45 <— mautic:segments:update
5,20,35,50 <— mautic:campaigns:update
10,25,40,55 <— mautic:campaigns:trigger

The problem I ran into

All of this is pretty standard stuff if you are familiar with Linux and crontab. There is one thing that bit me in the butt, and it’s the reason I am blogging this, permissions.

Originally, I had all of those setup in my crontab. My “my crontab” I mean the cron tab for my personal account on the server. Since I am a member of the group that the web server runs under – mine is not a shared hosting environment, my sites are the only sites on the server – so I should have been able to do everything, right? Nope. The thing I forgot is that most everything is created with 0755 permissions. This means I can see the files created by the web server, but I can’t modify them. This hits you pretty quick when running any of these commands form any accounts that doesn’t have write permissions, because they all write to the app/logs/*.log files.

The obvious solution was to simply move them to the crontab of the account that my web server runs under, right? Yep, expect that that account has it’s shell set to nologin. This means that I can’t easily test them, or run them as a one-off for example clearing the cache. All system accounts are setup this way to adhere to the Best Practice Principal of Least Privilege.

The answer is yes, to add them into the account that the web server runs under, but you have to add the following to the beginning of the crontab.


NOW at least the cron jobs can run without a problem. I still have to jump through a couple of hoops to clear the cache.


Permissions will bite you in the butt every time on *nix systems. Be careful with them. The answer is almost never :

$ chmod -R 777 *

There is usually a way to get things done that don’t compromise your application’s security.

If you a reading this thinking “Well D’uh!” Again, this is more to remind me for next time than anything else. :) If it helps you along the way, I’m happy.

Until next time,
I <3 |<