Your instance has generated a "SMTP Sender Job Stuck" alertIssue Our monitoring system automatically creates cases titled "SMTP Sender Job Stuck" when we detect the SMTP Sender Job (sending email job) runs for longer than expected on your production instances. To validate, you need to be a system administrator on the instance. To verify the SMTP Sender job is still running, use KB0523599 - Verify that the SMTP Sender schedule job is running. Please note the emails have already been generated, which indicates the email notification is not part of the delay nor the event processor job. This alert only indicates the delivery of the send-ready emails to the target SMTP server is taking longer than expected. What is the SMTP Sender Job? The SMTP Sender Job is a scheduled job that runs every 2 minutes and is responsible for sending all outbound ready emails held on the instance. It will continue running until all send-ready emails are cleared from the instance.CausePotential causes for this alert: (not all causes are listed) A large backlog or spike in emails generated by the instance. This can be due to a planned bulk email campaign, a scheduled job creating unexpected amount of emails or an email loop.Large attachment(s) associated to the emails generated.Emails with a large amounts of recipients.(If using own SMTP server) the SMTP email server has a delivery rate limit and holding the emails sent. Sometimes a rate limit is applied to slow down the volume of emails that are able to be sent causing the SMTP Sender Job to run slower as it waits on the SMTP server.SMTP connection issues. If the connection between the instance and the the SMTP server is slow or times out, the SMTP Sender Job will also be slowed because of waiting for the connection.Slow SMTP server email processing. For example, if your SMTP server has its own antivirus scanning and is scanning each email received, this can cause a slower rate of emails being sent from the instance.Resolution Problems and Recommended Solutions for SMTP Sender Job Stuck You need to be a system administrator on the instance to validate. You are able to check yourself if the SMTP Sender job is still running from the following KB: KB0523599 - Verify that the SMTP Sender schedule job is running Case Possible problem Recommended solution Case 1 If you are using your own SMTP Server Please identify what is the cause of the SMTP Sender job taking time to deliver the emails by reviewing the email log table (sys_email). You can check with the following link: <instance>/sys_email_list.do?sysparm_filter_only=true&sysparm_query=type%3Dsend-ready%5Esys_created_onONLast%203%20months@javascript:gs.beginningOfLast3Months()@javascript:gs.endOfLast3Months()%5EORDERBYDESCsys_updated_on&sysparm_first_row=1&sysparm_view=& (change the time to match the reported alert timings) You should contact your mail admin to check if there are any issues with the connection or the rate of which emails are received by them from your instance. Finally, please engage with your network team to assist on resolving connection problems. However, when the SMTP server email processing is slow, consider reducing the amount of notification generated by the instance (disabling or tuning notifications), moving some scheduled reports to off-peak times and investigating with the SMTP server administrators on the options available to improve throughput performance. Case 2 If email in ready state have a large amounts of recipients *(usually with a low volume of emails). Consider reducing the recipient list by adjusting the email notification and adding the "unsubscribe" options to your notification. For more detail, review this blog. Case 3 Check if large attachment(s) are associated to those emails sent. To do so, open the sys_attachment table and search for those attachments. You can check with the following link: <instance>/sys_attachment_list.do?sysparm_filter_only=true&sysparm_query=table_name%3Dsys_email%5Esys_created_onONToday@javascript:gs.beginningOfToday()@javascript:gs.endOfToday()%5EORDERBYDESCsize_bytes&sysparm_first_row=1&sysparm_view=&(change the time to match the reported alert timings) If you see attachments with 'Size bytes' > 10,485,760 (10MB) at the time of the problem, they could be related to the delay. To avoid this in the future, identify what is creating those emails and consider sending the link to the attachments, instead of the attachment themselves. Case 4 If there are no large attachments involved, check if the target SMTP email server has a delivery rate limiting and holding the emails sent. It could also be related to SMTP connection issues. Consider enabling the sys_properties name glide.smtp.debug with value true for a short period of time. Once enabled, your instance nodes wrapper.log files will provide more detail on the sending process. They are available on your instance "Node Log File Download" section, under the name "wrapper_<YYYYMMDD>.log". After a few emails are sent, disable the property and review the wrapper log. You need to contact the target SMTP server administrator to check or inclusion list your instance. You might want to send them the evidence found on the wrapperr_<YYYYMMDD>.log files Case 5 If there is a large backlog or spike in emails ready to be sent, check if this is a planned bulk email campaign. The simple way to identify the email notification involved will be to open one of those emails, change to the "Outbox view" and check the "Originating Event and Notification" section Another way to identify the email notification involved on creating those emails, is to open the sys_email_log table and group by notification at the time of the alert. You can check with the following link: <instance>/sys_email_log_list.do?sysparm_query=email.type%3Dsend-ready%5Esys_created_onONToday@javascript:gs.beginningOfToday()@javascript:gs.endOfToday()%5EGROUPBYnotification&sysparm_first_row=1&sysparm_view=&sysparm_filter_only=true (change the time to match the reported alert timings) Try to spread the email generation over time. You will recognize them as their subject will be similar between those emails. Case 6 If there is an email loop between the instance and a user that has an auto-reply email sent back that is processed. You will recognise this problem because there are related to a large amount of emails on the email inbox table, most of them will look like bounced emails. More detail on this blog. Check if there is a business rule that "auto-reply" to incoming emails. Disable the notification/inbound action or using email filters on the instance or can also be addressed on the user side to stop the auto-replies. More information can be found on our documentation: Email Diagnostic (docs) Warning: It is important to test any changes on your development instance before making changes to production.