Questions about Mautic 4.4.13 Cron Jobs: segments:rebuild vs update, and sequential vs parallel execution

Product Support Mautic 4 Install/Upgrade Support
1

Hi everyone,

I’ve recently taken over the maintenance of a Mautic instance from a former colleague. It is currently running on version 4.4.13, which was upgraded from an older version by my predecessor.

We’ve been having some issues with our cron jobs, so I turned to the official documentation for help. However, the information there doesn’t quite match our current setup, and I’m not sure if our configurations are just outdated remnants or if they are valid.

I would appreciate some clarity on the following points:

1. Segment Crons (segments:update vs segments:rebuild) In our environment, we have two separate cron jobs configured: mautic:segments:update and mautic:segments:rebuild. However, the documentation only mentions update. What is the actual difference between these two commands, and is the rebuild command still necessary?

2. Cron Scheduling (Sequential vs Parallel) The official documentation suggests scheduling the core cron jobs independently at different times. In our setup, they are chained together and executed sequentially via a single custom PHP script.

  • Can these cron jobs run completely independently without causing issues if they overlap?

  • If our segments:update process takes a long time, is it actually safer to keep them running sequentially through a PHP script like we do now?

Thank you in advance for your help!

2

On 4.4 those two are the same command. mautic:segments:rebuild is just an alias of mautic:segments:update, so you’re running the same job twice and can drop the rebuild cron. You can confirm it on your box with php bin/console list mautic, the aliases show up next to the command.

Running them independently is fine in my experience. The segment and campaign commands take a lock so a second copy of the same command won’t start while the first is still running, though different commands can overlap. The order that matters is segments:update, then campaigns:update, then campaigns:trigger, so if you split them up give each a few minutes of offset, something like */15 for segments, 5 past for campaigns:update and 10 past for trigger. If segments:update is really slow, run it once by hand with -vvv and check var/logs before deciding to keep the chained script, since it’s usually one big segment with heavy filters doing the damage.

3

One important limitation of Mautic 4.4 is that a targeted segment update is not dependency-aware.

A “segment chain” means that one segment depends on another. For example:

  • Segment A: contacts from Germany .
  • Segment B: contacts from Segment A who also have a particular score.
  • Campaign C: contacts from Segment B.

In this case, Segment B depends on Segment A. If Segment B is updated before Segment A, it may use the previous membership of Segment A. As a result, some contacts may be missing from Segment B until the next complete processing cycle.

Running:

php app/console mautic:segments:update --list-id=<ID>

updates only the selected segment. It does not automatically walk through all prerequisite segments and process them in dependency order. The same applies when the command is started manually, from a custom script, or by an external scheduler.

mautic:segments:update and mautic:segments:rebuild are effectively aliases. Selecting one segment by ID is therefore not the same as running the complete segment-processing chain.

For dependent segments, the safe order is:

  1. Update the source or prerequisite segments.
  2. Update the segments that depend on them.
  3. Rebuild campaign membership.
  4. Trigger campaign events.

For example:

php app/console mautic:segments:update --list-id=<source-segment-id>
php app/console mautic:segments:update --list-id=<dependent-segment-id>
php app/console mautic:campaigns:update
php app/console mautic:campaigns:trigger

For a normal full-cycle cron setup, the usual order is:

php app/console mautic:segments:update
php app/console mautic:campaigns:update
php app/console mautic:campaigns:trigger

Parallel execution should be used carefully. It may be acceptable for completely independent segments, but it is unsafe to assume that parallel workers will resolve a dependency chain correctly. If two dependent segments are processed at the same time, the second one may read stale data from the first one. The result can depend on timing and may change between runs.

Database locking can prevent two identical jobs from running simultaneously, but it does not establish the correct order between different segment IDs.

Dependency-aware chain handling was improved in Mautic 7. With Mautic 4, a targeted segment run should therefore be treated as a low-level operation. The external script or scheduler must know the dependency order and execute the required steps explicitly.

In short, --list-id is useful for controlled maintenance, but it is not a replacement for the complete segment and campaign processing cycle.

4

Hello everyone,

The recent critical PHP security incident (severity 9.2) is a clear reminder of the risks associated with running outdated and unsupported software.

Keeping PHP and other infrastructure components up to date is essential for maintaining security and stability. This incident provides yet another strong reason to prioritize migration to actively supported versions.

However, there are exceptions to every rule. In real-world production environments, upgrading is not always immediately feasible due to application compatibility, legacy dependencies, operational constraints, or the complexity of existing infrastructure.

To address these challenges, our engineering team at Sales Snap has developed an internal APT repository containing maintained builds of legacy PHP versions, including PHP 7.4 and PHP 8.0, for Ubuntu 22.04 LTS and Ubuntu 24.04 LTS.

This repository is part of our infrastructure maintenance strategy and is intended to help organizations maintain legacy environments while preparing for migration to supported software versions.

We are considering making this repository publicly available to the community.

If there is sufficient interest, we would be happy to provide open access to these packages and share our work with other organizations facing similar challenges.

We believe that sharing practical solutions and technical expertise benefits the entire ecosystem. Security challenges affect all of us, and collaboration is one of the most effective ways to address them.

Our goal is not to encourage continued reliance on outdated software, but to provide a safer transitional solution for environments where immediate upgrades are not possible.