Why did my app stop sending emails?

Look at the provider's log first, not your own

The confusing part of this failure is that nothing looks broken. Your code ran, the send function returned, no exception was thrown, and your own logs show messages going out. That is because your application log records what your code decided to do, and the provider's log records what happened to the message. When the two disagree, the provider is right. Open its activity view and filter to the window where sending stopped: you will normally see either silence after a timestamp, which means your code stopped calling, or a run of rejections with a reason attached, which means it called and was refused.

Do that before you change code, rotate an API key or re-send anything. Each of those makes the diagnosis harder, and one of them makes the problem worse: a re-send burst against an account already flagged for volume is the standard way to turn a temporary pause into a permanent one.

The four things that actually stop the sending

In rough order of how often each one turns out to be the answer:

• A plan limit you grew into Daily and monthly send caps are the most common cause and the least fair-feeling, because nothing about your system changed — your signups did. The limit gets crossed on a Tuesday that looks like every other Tuesday, and what gets dropped is whatever was queued last, which is usually your notification and lifecycle mail rather than the login emails sent earlier in the day.
• A provider pause Providers stop accounts on sudden volume changes, on a hard-bounce rate over a threshold, and on spam complaints. This one usually does come with a warning email — sent to whichever address was on the account when it was created, which in a small team is often nobody's inbox any more.
• Broken domain authentication SPF, DKIM and DMARC records live in DNS, so they break when DNS changes: a registrar migration, a record that replaced rather than appended, an expired verification, a rotated signing key. This one degrades before it stops — delivery fails at one mailbox provider first, then the bounce rate climbs, then the pause arrives.
• Your own code stopped calling A missing environment variable in one environment, a queue worker that died quietly, a feature flag left off after a deploy, an SDK upgrade that changed a required field. If the provider's log shows silence rather than rejections, this is your branch, and the answer is in your deploy history rather than your provider's dashboard.

Read the body, not the status code

This is what turns a ten-minute incident into a three-day one, and we have made the mistake more than once in our own system. A rejected call does not reliably arrive as an error. It arrives as an HTTP 200 with the failure inside the response body, and code that checks only the status code records a success. We have hit that exact shape with several different vendors: one answers 200 with a false success flag in the body when a token is missing a permission; another accepted a social post, reported a validation failure in the body, and our system — reading only the envelope — recorded the post as published and told the customer so. Nothing had been posted.

The rule that came out of it is short, and it applies to email as much as to anything else: treat a send as successful only when the response body says the provider accepted it, log the provider's own reason string when it does not, and alert on that string rather than on your own summary of it. The status line describes the conversation with the API. The body describes the email.

The same discipline covers rate limiting. A provider answering 429 is telling you something useful and temporary, and code with no backoff converts that into permanent loss, because the message is dropped and never retried. We ran without that backoff for longer than we should have, and what eventually surfaced it was not an alert. It was somebody going to look.

Make the next one loud

The fix that matters is not raising the limit, it is noticing before you reach it — and the alert should be on the ratio, not the count. "We used 80% of today's allowance by 2pm" is actionable; "we sent 100 messages" stops meaning anything the moment the plan changes. Our own volume crossed a hundred messages a day as signups grew, against a free-tier ceiling of exactly a hundred: roughly 107 on the day we finally looked, after sitting at 99 of 100 earlier that week. No part of the system said a word about it. The upgrade was the easy half. The alert we still owed ourselves was the half that mattered, and the reason it was missing is that the cap had never been near before, so nobody had thought of it as a number that moves.

Two more things worth doing while you are in here. Keep a second way into the account for when an email carrying a login does not arrive, for the reasons in our page on why magic link logins fail. And separate the mail that carries a login or a receipt from the mail that carries a campaign — by sending domain at minimum, ideally by provider — so that a marketing send tripping a complaint threshold cannot take your password resets down with it. Our page on setting up lifecycle emails covers what belongs in each stream. Building AgentCeres — the AI Growth Officer at agentceres.com — taught us the priority the expensive way: the messages a customer actually asked for are the ones you protect first.