Body: <p>Our last mailing stopped after 2000 out of about 3400 being sent. I aborted that and created a new mailing (trying to target the rest of the intended recipients). This job has now stopped att 1000 of the 2308 intended.</p>
  <p>The mailing job log looks ok, but I can't find any real result codes.</p>
  <p>We are using an SMTP relay with <a href="https://mailersend.com" rel="nofollow noreferrer">https://mailersend.com</a> which, as far as I can see, reports no errors.</p>
  <p>Our mailing job runs on every invocation (cronjob runs every 5 minutes), sending 200 per batch with 1 second delay between each mail.</p>
  <p>Any tips on how to debug this is appreciated!</p>
  <p><strong>Update: The Mailing Scheduler job probably crashes</strong></p>
  <p>The mailing jobs around when it actually sent anything shows two log entries:</p>
  <pre><code>Starting execution of Mailings scheduler
  </code></pre>
  <p>and</p>
  <pre><code>Finished execution of Mailings scheduler with result: Success (a:1:{s:9:&quot;processed&quot;;i:0;})
  </code></pre>
  <p>After some time only the &quot;Starting...&quot; is logged, where would a reason for not completing be shown?</p>
  <p>I also now discovered that the &quot;Reminder sender&quot; job hadn't been executed since the time when the mailing sender stopped. If i pause the mailing the &quot;Reminder sender&quot; job executes again.</p>
  <p>I am guessing that jobs execute in some non-random order and that the mailer sender jobs runs before the &quot;Reminder sender&quot;. This would then indicate that the scheduler &quot;crashes&quot; when it tries to execute the next batch of mailings. Is this a clue?</p>
  <p>Also running the Mailing Scheduler job manually from &quot;Administer-&gt;Scheduled jobs&quot; results in a completely white screen...</p>
  <p><strong>Update: Where is the error code from the SMTP send?</strong></p>
  <p>We discovered that the root cause for this was that our SMTP relay service just recently had introduced a daily request limit of 1000. Duh!</p>
  <p>According to their documentation they will then return error code 429 on that request.</p>
  <p>So to answer the question in the title, the question becomes &quot;Where do I find the return code for the SMTP request and why does the mail scheduler stop/crash for this error code rather than displaying it somewhere?&quot;</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-04-07T09:15:05.663Z
Comments.Text: A couple of things to consider - have you sent bigger email sets in the past or is this the first time? What SMTP service are you using? How often is your mailing cron running? Some of the answers will help direct where best to look.
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-04-07T09:22:53.507Z
Comments.Text: Thanks. Updated with some answers. We have sent many times over the years but only twice using mailersend, both successful. And there has probably been a few upgrades of CiviCRM since the last mailing.
Comments.UserDisplayName: thoni56
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-04-08T10:33:05.030Z
Comments.Text: Ok so probably focussing on the WSOD when you run the job manually might be the best way to see whats going wrong. And yes, if the cron fails it will not run other jobs.
Comments.UserDisplayName: Parvez Saleh
Tags: <civimail><scheduled-job><debug>
Title: Mailings stops - how to debug
ThreadText: # Mailings stops - how to debug
  
  (Asked by: username_0 on 2022-04-07)
  
  Our last mailing stopped after 2000 out of about 3400 being sent. I aborted that and created a new mailing (trying to target the rest of the intended recipients). This job has now stopped att 1000 of the 2308 intended.
  The mailing job log looks ok, but I can't find any real result codes.
  We are using an SMTP relay with https://mailersend.com which, as far as I can see, reports no errors.
  Our mailing job runs on every invocation (cronjob runs every 5 minutes), sending 200 per batch with 1 second delay between each mail.
  Any tips on how to debug this is appreciated!
  Update: The Mailing Scheduler job probably crashes
  The mailing jobs around when it actually sent anything shows two log entries:
  Starting execution of Mailings scheduler
  
  and
  Finished execution of Mailings scheduler with result: Success (a:1:{s:9:"processed";i:0;})
  
  After some time only the "Starting..." is logged, where would a reason for not completing be shown?
  I also now discovered that the "Reminder sender" job hadn't been executed since the time when the mailing sender stopped. If i pause the mailing the "Reminder sender" job executes again.
  I am guessing that jobs execute in some non-random order and that the mailer sender jobs runs before the "Reminder sender". This would then indicate that the scheduler "crashes" when it tries to execute the next batch of mailings. Is this a clue?
  Also running the Mailing Scheduler job manually from "Administer->Scheduled jobs" results in a completely white screen...
  Update: Where is the error code from the SMTP send?
  We discovered that the root cause for this was that our SMTP relay service just recently had introduced a daily request limit of 1000. Duh!
  According to their documentation they will then return error code 429 on that request.
  So to answer the question in the title, the question becomes "Where do I find the return code for the SMTP request and why does the mail scheduler stop/crash for this error code rather than displaying it somewhere?"
  
  **Tags:** civimail, scheduled-job, debug
  
  > **Comments:**
  > **username_1**: A couple of things to consider - have you sent bigger email sets in the past or is this the first time? What SMTP service are you using? How often is your mailing cron running? Some of the answers will help direct where best to look.  
  > **username_0**: Thanks. Updated with some answers. We have sent many times over the years but only twice using mailersend, both successful. And there has probably been a few upgrades of CiviCRM since the last mailing.  
  > **username_1**: Ok so probably focussing on the WSOD when you run the job manually might be the best way to see whats going wrong. And yes, if the cron fails it will not run other jobs.  
  
  ---
  
  ## 0 answers
  
  