A broadcast can take hours to send, and it is often scheduled while nobody is watching. SendOps tells you how it went, so you don't have to keep the page open. ## What you'll be told Every notice links straight to the broadcast's page. | Notice | When it arrives | Who gets it | On by default | |---|---|---|---| | **Broadcast Sent** | The broadcast finished and everyone was sent to. | The creator | Yes | | **Broadcast Finished With Failures** | The broadcast finished, but some recipients could not be sent to. Includes the counts and the most common failure reasons. Sent *instead of* Broadcast Sent, never as well. | The creator, plus admins and owners | Yes | | **Broadcast Failed to Start** | The broadcast could not start, so nobody received it. Says why. | The creator, plus admins and owners | Yes | | **Broadcast Paused** | Sending stopped part way and is waiting for someone to resume it. Says why. | The creator, plus admins and owners | Yes — always delivered to admins and owners | | **Broadcast Waiting for AWS Quota** | Your AWS daily sending limit ran out mid-send. The broadcast will carry on by itself. At most once a day per broadcast. | The creator | Yes | | **Scheduled Broadcast Started** | A scheduled broadcast began sending. | The creator | No | | **Broadcast Still Sending** | The broadcast has been sending for about 3 hours and isn't done. Nothing is wrong — large sends are paced. Once per broadcast. | The creator | Yes (in-app only) | Each notice is sent once per event: a retry or a second worker never tells you twice. A broadcast that is paused, resumed and paused again tells you about each pause. A broadcast created with an API key or through the [MCP server](/ai-agents/mcp-server) has no creator. Admins and owners get all of its notices instead, alongside your org Slack and webhooks. ## Where notices go Broadcast notices reach the same places as every other SendOps notification: - **In-app** — the bell and **Notifications → Inbox**. - **Email** — on by default for everything except Scheduled Broadcast Started and Broadcast Still Sending. - **Org Slack** — if you've connected Slack under **Connections → Integrations**. Scheduled Broadcast Started and Broadcast Still Sending never go to Slack; they are personal updates, not team alerts. - **[Webhooks](/notifications/webhooks)** — subscribe an endpoint to the **Broadcasts** category. The payload is listed under [Broadcast payload](/notifications/webhooks#broadcast-payload). ## Changing what you get Open **Notifications → Preferences** and find the **Broadcasts** category. Turn each notice on or off, and pick its channels, like any other [notification type](/notifications/notification-types#broadcasts). Admins can change these for teammates from the **Team** tab. **Broadcast Paused** is always delivered to admins and owners: they can choose the channel, but not turn it off. A paused broadcast never restarts by itself, so somebody who can resume it has to hear about it. A creator who isn't an admin or owner can turn it off for themselves. ## Waiting for your AWS daily sending limit AWS caps how many emails your account can send in any 24 hours — your **daily sending limit** (AWS calls it the sending quota). A big broadcast can use it up part way through. When that happens, SendOps doesn't drop anyone. It puts the unsent recipients back in the queue and tries again about every hour. As AWS frees up room, sending carries on. Meanwhile the broadcast's badge reads **Sending · waiting for quota**, and its page says: > Waiting for your AWS daily sending limit — 1,200 of 5,000 sent. Resumes around 2:05 PM. The time is in your own time zone, with the date added if it's another day. Below it is a **How to raise your sending limit** link. If you ask through the [MCP server](/ai-agents/mcp-server), `broadcasts_get_status` gives the same thing as one sentence, with the time in UTC: > Waiting for your AWS daily sending limit — 1,200 of 5,000 sent, resumes around 14:05 UTC. You get one **Broadcast Waiting for AWS Quota** notice when the wait begins. Once the hold passes, the normal sending progress comes back. You don't need to do anything. You may occasionally see a different, shorter wait: *"SES didn't confirm the last batch — retrying shortly."* That one also clears by itself. Over MCP it reads *"Waiting briefly because SES did not confirm whether some emails were sent"*, followed by when it resumes. ### Raising the limit If you regularly hit the limit, ask AWS for a higher one. New production accounts usually start at 50,000 emails a day, and AWS raises it over time for accounts with clean sending — see [Initial sending limits](/sending-email/ses-production-access#initial-sending-limits). To ask for more sooner, open a sending-limit increase case in the AWS Support Center for the region you send from. If your account is still in the SES sandbox, the limit is just 200 emails a day. Request [production access](/sending-email/ses-production-access) first. ## If a broadcast pauses after 30 hours If 30 hours pass with the limit still used up and **nothing** sent, SendOps stops trying and pauses the broadcast. You get a **Broadcast Paused** notice that says: > Sending was paused because your AWS account's daily sending limit has stayed used up for over a day. Raise the limit with AWS or resume later. A broadcast that sends even a little each day is never paused this way — only one that is completely stuck. To finish the send: 1. Find out why the limit isn't freeing up. Usually something else on the same AWS account is using it, or the limit is too low for the audience. 2. Raise the limit with AWS (see [Raising the limit](#raising-the-limit)), or wait until other sending on the account has calmed down. 3. Open the broadcast and click **Resume**. It carries on with the recipients who haven't been sent to yet — nobody gets it twice. Resuming restarts the 30-hour clock. If the limit is still used up, the broadcast waits and retries hourly again. ## What's next? - See every broadcast state and per-recipient result in [Broadcasts](/sending-email/broadcasts). - See the full list of notices in [Notification Types](/notifications/notification-types). - Receive these notices in your own systems with [Webhooks](/notifications/webhooks).