Email Queue thread logic

The process of email distribution follows the general logic below:


  • Notification threads generate emails and send them to email_queue table
  • Email Queue threads will take emails from email_queue table and try to send it to the subscriber(s)
  • Each Email Queue thread locks emails for 30 minutes
  • If an email is successfully sent, then it will be moved from email_queue table to email_queue_delete_log table

1. What is the logic when emails are unable to be sent?

Sometimes, an email can fail to deliver or experience delays in delivery due to following reasons:

  • Network failure
  • Email server error
  • When Notifications OFF system-wide

If an email fails to send upon the 1st attempt for any one of these reasons above, the email remains locked for 30 minutes before system will try to send it next time

For any given burst, please be sure that  Notifications ON system-wide is enabled under Admin > Status Monitor before the burst is sent, otherwise the bursts will not received for more than 30 minutes due to the email queue thread locking behavior described above

2. Email/burst logging

The system variable EMAIL_LOGGING must be set to "Y" in order for email-YYYY-MM-DD.log to be included in the error logs under Admin > Status Monitor > Errors & Logs. 

email-YYYY-MM-DD.log can be helpful to troubleshoot/monitor email distribution behavior

3. Multithreading

The system variable EMAIL_QUEUE_PROCESSING_THREADS_NUMBER and the concept of multithreading in email sending process was introduced starting in version 6.3.0

What is a safe value for EMAIL_QUEUE_PROCESSING_THREADS_NUMBER?

  • The value is "1" by default
  • The optimal value depends on the number of CPU cores and also the number of emails/recipients for bursts in a given time period
  • We recommend to start with a value of 5 and monitor CPU usage during burst delivery
  • In the most substantial use-cases, the upper limit is typically between 20-30 threads at a maximum