Email Reader / SMTP Sender job stuckDescriptionWhen an alert is generated for either of these jobs being stuck, you can diagnose and remedy stuck jobs, as well as find common causes. Please review KB0521382 - Troubleshooting Outbound Email or KB0520595 - Troubleshooting Inbound Email to see if one of these solves your issue. Steps to diagnose and remedy stuck jobs Email Diagnostics, if anything is non-operational, note the reason in the incidentAre any emails being created? Email Reader: type = received SMTP Sender: type = sent Check the sys_trigger jobs. How long have they been running? Any errors? Note: If the job is not running and the next run date is in the past, set the job to error and then back to ready. Navigate directly to the node the job(s) is running on and look at the worker(s)Open the worker and view the stack trace. Refresh the browser, not the stats page refresh button Is the stack changing or staying the same?Here is where it must be determined if the job is running slow or something like a loop is causing it to run indefinitely. The stack trace notifies where all of the time is being spent. Look for any sys_id of a particular script/inbound action/notification, etc Create the corresponding debug property and set it to true : glide.pop3.debug | glide.smtp.debug | glide.imap.debug) View the localhost and wrapper logs. Get an example of one message sent or received from each of these logs and post to the incident. The wrapper logs will give you the most detailed logging of the actual network protocol commands between the application server and the mail server along with timestamps to see where the possible slowdown is occurring. Common Causes Emails are looping. A notification is going out to a user which is sending it back to the instance, which then again triggers the notification. This can be corrected in either of the three places causing the loop. Notification going out to the userThe recipient sending messages back to the instance (customer action needed)Inbound actions updating records and triggering another notification Email bounce backs. Similar to email looping but in this case the notification is bounced by the receiving email server for one reason or another. The same correction points are here as the email looping but ultimately the customer will want to understand the reason for the bounce backs and correct it.An influx of inbound or outbound emails. This could be caused by a runaway script, testing, or something outside of the instance. Many times this is actually email looping or bounce backs.Slow email server connection. This will be validated after setting the debug logging on and viewing the wrapper logs. Not uncommon for private mail servers to take a long time to validate recipients (1 second per recipient is way too long). This could point to a network issue, an AD issue, a load balancer issue, etc. Resources xmlstats.do - <notification.stats> gives a snapshot of some valuable data concerning inbound and outbound email processing.big data - http://stats.servicenow.net/instance_view?impala=true&selection=<instance-name> - valuable metrics for production instances - can give data over time to help pinpoint when an issue began to occur.KB0521382 - Troubleshooting Outbound EmailKB0520595 - Troubleshooting Inbound Email