Why was my email sending paused or throttled?
Every email sending limit, throttle, hold, and pause explained in plain language — what triggered it, and exactly how to fix each one.
If your app's email suddenly stopped sending — or an email attempt came back with an error — this article maps every state to what happened and exactly what to do. None of these are punishments; they're the guardrails that keep your email landing in inboxes instead of spam folders.
The fastest way to see your exact situation: open Billing → Email Health. It shows your current limit, today's usage, delivery health, and a history of every limit change with its reason.
Daily sending limit reached
What happened: you used today's full allowance. Nothing is broken and nothing is flagged.
What to do: the counter resets at midnight UTC. If you're hitting the cap regularly, your limit grows automatically with healthy sending — and you can speed that up by declaring your use case on Billing → Email Health. See Understanding your email sending limits.
Email sending is temporarily throttled for THIS app
What happened: one specific app's bounce or spam-complaint rates spiked, so that app alone was throttled. Your workspace's other apps keep sending normally.
What to do: usually this means that app emailed a stale or purchased list. Clean out the bad addresses (anything that bounced) and stop emailing anyone who didn't opt in. The throttle lifts automatically as soon as the app's delivery health recovers — no request needed.
Your sending limit was reduced
(a step down the ladder)
What happened: your workspace's bounce rate (or spam-complaint rate) crossed the warning line over the last 24 hours, so your daily limit stepped down one level.
What to do: fix the underlying list problem, then just keep sending healthy email. After a 24-hour cooldown, healthy sending promotes you back up automatically. The Email Health page shows exactly which number crossed which line.
Sending is on hold pending review
(new-workspace hold)
What happened: our systems flagged unusual account-creation patterns around this workspace (for example, many workspaces created from the same account or network in a short window, or a sign-up email from a throwaway/temp-mail service). Sending isn't blocked — it's capped at a small daily allowance while flagged.
What to do:
- Click Request re-evaluation on Billing → Email Health. The hold clears automatically once the signal subsides.
- If your account email is a temp-mail address, switch your account to a permanent address first.
- Fastest path: complete payment identity verification (the same verification used for selling through your apps). Verified workspaces skip these holds entirely.
Email sending is paused for this workspace
This is the strongest lever, and the reason shown on Billing → Email Health tells you which kind it is:
High bounce or complaint rates. Sending paused because recipients were actively harmed (typically a spam complaint rate over 1% or bounces over 10%). Fix the list — remove every bounced address, only email people who opted in — then contact support to review and re-enable. These pauses need a human review because those rates put every customer's deliverability at risk.
Gmail flagged the sending domain. Google's own reporting shows recipients marking your domain's mail as spam at a high rate. Same fix as above: clean list, opted-in recipients only, then contact support.
Automated content-pattern review. Our systems detected near-identical email content being sent from multiple unrelated workspaces at once — a pattern associated with coordinated abuse. If your workspace was included by mistake (it can happen when several apps legitimately share the same template text), click Request re-evaluation on Billing → Email Health: the pause clears automatically once the pattern subsides and your own delivery health is clean. If it doesn't clear, contact support and a human will review it — include what your emails send and to whom.
A link in this email was flagged
(message rejected, not a pause)
What happened: one specific send was rejected because a link in it points to a domain flagged by Google's Web Risk service (malware or phishing). Nothing was charged, and your workspace's sending is otherwise unaffected.
What to do: remove or replace the flagged link and resend. If you own the domain and believe the flag is wrong, contact support to appeal — and check your own site for compromise first (a hacked site is the most common cause of a surprise flag).
Sender domain is not verified
What happened: the app tried to send from a domain that hasn't finished DNS verification.
What to do: open the editor's Email tab, add the DNS records shown, click Check again once they've propagated, then redeploy the app.
Still stuck?
Open a support ticket and tell us which state you're seeing on Billing → Email Health. Our support assistant can read your workspace's actual sending status and history, so you'll get a specific answer — not a generic checklist.