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

Product Support
1

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!

2

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…)

1 Like
3

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”)…

4

Thanks for your response.

  • We’re already using segment emails.
  • Deleting the folder regularly was a recommendation by ChatGPT to avoid overflow. I know that this might delete mails, but it was better than crashing the whole server (which still happens, though, if we try to send a lot of e-mails)
  • Regarding “mautic:broadcast:send”: I thought it was “mautic:messages:send”

I did not understand this sentence:

All Mautic:email:send and SES business is of course needed but irrelevant for your issues.

We have SES in place, but not “SES business”. And no “mautic:email:send”, but “mautic:messages:send”

5

Thanks for the hint to the version number. It’s 3.1.2.

We installed Mautic via Bitnami back in the days. Unfortunately, they dropped their support for it. But since we have no experience in setting it up ourselves (and migrating the data), we kept it running.

6

Oh god!
it’s too older better to update your mautic and please take a backup of your current db and import them into newer version’s db in the presence of experienced Mautic Dev.

7

ok sorry, let me rephrase :slight_smile:

  • mautic:messages:send is indeed what I wrote, but that got emojified …
  • By “business” I meant “stuff”, not an SES product.

Background is: Your issue is about filling the queue too fast, not about taking stuff from the queue.

8

I already made a backup and wanted to test-drive the upgrade locally on my Mac, before I try implementing it on EC2 and doing the upgrade there, in a clean new instance.

1 Like
9

Thanks for the clarification.

10

Do you happen to know “what” is filling up your storage?