Mautic E-Mail Spool Queue: How to prevent it from filling the whole disk?

Hi Mautic Community,

we’ve been using Mautic for many years now and it became a valued part of our infrastructure. Couldn’t praise it more! We still use it on an old Bitnami instance in combination with SES.

Recently, we’ve run into some issues with sending larger amounts of e-mails out. We noticed that at some point, the actions counter in our campaign stalled and no further mail got out through SES.

So, with some help of ChatGPT, we decided to switch to the email queue instead of sending out mails directly. This worked just fine with an email campaign that went out to around 1.6k users.

However, on Halloween we wanted to target a much larger group of around 9k. When we tried that, we quickly ran out of disk space. So we doubled the space in EC2 (to 20 GB), just to notice that the whole new space got consumed just as quickly. It should be mentioned that this was just a a normal newsletter, nothing big to be sent out. Since we couldn’t expand the disk space further (EC2 has a limit of 6hrs between changes), we ended up shutting down mautic repeatedly, cleaning the spool folder (which we found out to be the culprit) and started it again. And again.

While doing this, we also tried to tweak the number of emails that would be sent out at each cron job run (it was 600, we lowered it to 100) and also to slow down the messages:send cronjob. But it did not really help. Eventually, we switched back to “send directly”, which solved the disk space issue, but showed the “stalling issue” once again.

We are wondering now what the recommended setup for SES is, i.e. how to configure it properly (ChatGPT recommended to use the SES API option), and how to set the parameters in both mautic and crontab to not consume the whole disk space again.

For your reference, here’s our current crontab setup:

```
0-57/3 * * * * su daemon -s /bin/sh -c “/opt/bitnami/php/bin/php -q /opt/bitnami/apps/mautic/htdocs/bin/console mautic:segments:update” #mautic-segments-cron

1-58/3 * * * * su daemon -s /bin/sh -c “/opt/bitnami/php/bin/php -q /opt/bitnami/apps/mautic/htdocs/bin/console mautic:campaigns:rebuild” #mautic-campaings-rebuild-cron

2-59/3 * * * * su daemon -s /bin/sh -c “/opt/bitnami/php/bin/php -q /opt/bitnami/apps/mautic/htdocs/bin/console mautic:campaigns:trigger” #mautic-campaigns-trigger-cron

*/1 * * * * su daemon -s /bin/sh -c “/opt/bitnami/php/bin/php -q /opt/bitnami/apps/mautic/htdocs/bin/console mautic:webhooks:process” #mautic-webhooks-cron

*/10 * * * * su daemon -s /bin/sh -c “/opt/bitnami/php/bin/php -q /opt/bitnami/apps/mautic/htdocs/bin/console mautic:messages:send” #mautic-messages-send-cron

# Clear spool folder every 6 hrs (we just added this)

0 */6 * * * find /opt/bitnami/apps/mautic/spool -type f -mtime +2 -delete
```

Your software
My Mautic version is: Can’t see any version in the UI, but the copyright date is 2025
My PHP version is: 7.2.34
My Database type and version is: Ver 8.0.22 for Linux on x86_64 (MySQL Community Server - GPL)

Thanks in advance for your support!

Hi,

Really brief:

  • make sure to use segement emails
  • do not delete from the queue - this causes lost emails!
  • Key: Control the pace at which emails are added to the queue. Mautic:broadcast:send is the console command in charge, so in your Cron job add a little condition that checks the number of queue entries (ls -1 |wc -l does the job) and only proceed if below threshold.
  • All Mautic:email:send and SES business is of course needed but irrelevant for your issues.

Best, Ekke

(Written on mobile while traveling towards Mauticon :tada: so please forgive inaccurate details…)

P.S. you can find the Mautic version in the lower right corner of the UI.

Also, somebody in your team should really know the version - afterall you are running an outdated one (unless you purchased the extended support for security fixes for version 4, “ELTS”)…