> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# When You Hit a Limit
> What a full ceiling refuses, which recipients get dropped and under exactly which reason in your send statistics, when the counters renew, and how to unblock.
# When you hit a limit
Limits do not all bite the same way. A **stored-resource ceiling** refuses a click — you cannot create the thing. A **send quota** refuses nothing you can see at the time: the campaign runs, and some recipients simply do not receive the message, with a reason recorded in the statistics. This page tells you which is which, names the reasons exactly as they appear, and says how to get moving again.
Written for **all three roles**: the refusal codes are for Dev, the drop reasons for Marketing reading a campaign report, the unblocking paths for Product/Ops.
**Enforcement is rolling out.** Counters are live and visible for every organisation, and **AI credits are enforced today**. Send quotas and stored-resource ceilings are being switched on progressively — until enforcement is active for your organisation, the gauges fill up but nothing is refused. Ask your Notifizz contact where your organisation stands.
## TL;DR
* **Ceiling full → creation refused.** A `409` with the code `limit_exceeded:`, plus the limit and what you currently own. Same refusal from the dashboard, the copilot and MCP.
* **Volume exhausted → recipients dropped.** The first recipients of the batch go out; the tail is dropped and counted under `quota_exceeded:` in the campaign's send statistics.
* **A channel your plan does not carry behaves like an exhausted one** — every recipient on that step is dropped under that channel's reason.
* **Capability off → the action is refused outright.** That is not a quota, and no amount of waiting fixes it.
* **Nothing you already own is ever taken away.** Ceilings refuse new creations only.
* Renewal is **UTC**: monthly grants at the start of the calendar month, daily grants at midnight.
## Two limits, two behaviours
| | Stored-resource ceiling | Send quota |
| ------------ | ---------------------------------------- | ------------------------------------------------- |
| Bounds | What you own | What you consume this period |
| You find out | Immediately — the creation is refused | Afterwards — in the campaign's send statistics |
| Effect | Nothing is created | Part of the audience does not receive the message |
| Fixed by | Archiving, deleting, or a higher ceiling | Waiting for renewal, or more volume |
## A ceiling is full: the creation is refused
### What gets refused
| Gesture | Resource |
| ----------------------------------------- | -------------- |
| Create a campaign | `campaigns` |
| Duplicate a campaign | `campaigns` |
| Create an environment | `environments` |
| Create an email layout, or duplicate one | `layouts` |
| Create an email section, or duplicate one | `sections` |
| Upload a file to the asset library | `assets` |
The check sits at the creation point itself, not in the interface, so **every path is covered by the same verdict** — the dashboard, the AI copilot, and tools run from your IDE over MCP all get the same answer.
### What the refusal says
```json theme={null}
{
"code": "limit_exceeded:campaigns",
"limit": 40,
"current": 40
}
```
HTTP `409`. The code carries the resource that is full; `limit` is your effective ceiling and `current` is what you own right now (the figures above are illustrative — yours come from your plan). For assets the two are in **megabytes**, everything else is a count.
### What is *not* refused
Editing is never gated. An organisation that ends up over a ceiling — after a plan change, or a tightened contract — keeps every campaign, every component and every asset, and keeps editing all of them. Only a **new** creation is refused.
### How to free capacity
The count is taken live, so it drops the moment you clean up:
* **Archive a campaign.** Archived campaigns do not count; the slot is immediately available.
* **Delete an asset** from the library. Its megabytes come straight off the total.
* **Delete a layout or a section** you no longer use. Version history was never counted, so only the component itself matters.
If none of that applies, the ceiling itself has to move — see [unblocking](#how-to-unblock).
## Volume is exhausted: recipients are dropped
### Where it happens
A campaign step resolves its audience, drops the recipients that are ineligible or malformed, and only then asks for credits — for exactly the recipients that would otherwise have been sent to. You are never billed for a recipient who was going to be filtered out anyway.
If the remaining credits do not cover the batch, the **first** recipients are sent (their order is preserved) and the **tail** is dropped. Both bounds apply at once: the step's channel *and* the cross-channel total. Whichever runs out first caps the batch.
Only campaigns in the `Live` status consume. Editing, Implementation, Review and Offline runs — review simulations included — never draw on your volume.
### The reasons you will see
Dropped recipients are counted by reason on the campaign's **Sends** widget, under a line reading *N recipient(s) filtered out of M*. The quota reasons are:
| Reason code | Shown as |
| ------------------------- | ------------------------------------ |
| `quota_exceeded:global` | Sending quota reached (all channels) |
| `quota_exceeded:email` | Email quota reached |
| `quota_exceeded:inapp` | Notification center quota reached |
| `quota_exceeded:webpush` | Web push quota reached |
| `quota_exceeded:slack` | Slack quota reached |
| `quota_exceeded:webhook` | Webhook quota reached |
| `quota_exceeded:sms` | SMS quota reached |
| `quota_exceeded:courrier` | Postal mail quota reached |
| `quota_exceeded:whatsapp` | WhatsApp quota reached |
Seeing `quota_exceeded:global` alongside a healthy channel gauge is the normal case, not a bug: the channel had room, the cross-channel total did not.
These reasons are classified as **warnings**, not errors. A quota drop says nothing is wrong with your integration — it says the budget ran out.
### A closed channel looks like an exhausted one
If your plan does not carry a channel, that channel has no credits at all — so a step on it drops **every** recipient under its own quota reason. The gauge for it reads *Not included in your plan* rather than showing a remaining count. The fix is a plan or capability change, never patience.
### The other reasons in the same breakdown
The Sends breakdown mixes quota drops with every other reason a recipient did not receive a message. Knowing which is which saves a wrong diagnosis:
| Reason code | Shown as | Meaning | Classified as |
| --------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------- |
| `missing_id` | Missing id | The recipient had no identifier | Error — fix the integration |
| `missing_email` | Missing email | An email step, and no address | Error — fix the integration |
| `invalid_email` | Invalid email | The address did not pass validation | Error — fix the integration |
| `suppressed` | Address suppressed (bounce, spam or deletion) | The address is on your organisation's suppression list | Error — the address is unusable |
| `unsubscribed` | Unsubscribed | A promotional send, and the person opted out | Warning — a deliberate choice |
| `not_in_first_send` | Not in the first send | The campaign only mails its original audience, and this recipient joined later | Warning — the mode working as designed |
| `objective_already_reached` | Objective already reached | The recipient already did the thing the campaign was chasing | **Success** — this number going up is good news |
| `quota_exceeded:*` | *(see above)* | Out of credits | Warning — the budget ran out |
`notification_pressure_exceeded` (*Notification pressure exceeded*) is reserved for a future per-recipient daily cap and is never emitted today.
See [delivery history and stats](/docs/operations/delivery-history-and-stats) for the rest of the funnel.
### The blocked-send log
The **Billing & usage** page ends with **Recent blocked sends**: one line per refusal, naming how many sends were blocked and on which resource. It only ever lists sends that were genuinely blocked — the would-be refusals recorded for calibration during the rollout are deliberately kept out, so an entry there always means a delivery did not happen.
## A capability is off: the action is refused
This is not a quota and it does not renew. The action is simply unavailable:
| Refused | Capability |
| ---------------------------------------- | ---------------------- |
| Adding a web push step to a campaign | Web push channel |
| Launching a broadcast to a CRM segment | Marketing broadcasts |
| Configuring your own tracking domain | Custom tracking domain |
| Connecting a connector still marked beta | Beta connectors |
Each refusal says so explicitly, and each gates **creation only** — a campaign that already carries a push step keeps sending, an active tracking domain keeps serving. The single exception is beta connectors, which also stop *receiving*: a suspended source ingests nothing until the capability is back.
## When the counters renew
| What | Renews |
| ----------------------- | --------------------------------- |
| Monthly volume (sends) | Start of the UTC calendar month |
| Daily pool (AI credits) | UTC midnight |
| Stored resources | Never — a ceiling is not a budget |
Monthly periods are the UTC calendar month for **every** organisation, not an anniversary of your subscription date. A plan grant expires with its period: **unused volume does not carry over**. Credits bought as a pack are the exception and carry their own validity.
## How to unblock
Open **Billing & usage** → *Usage*. *Current period* tells you which volume is exhausted; *Stored resources* tells you which ceiling is full. A blocked send names its resource in *Recent blocked sends*.
Ceilings respond immediately: archive a campaign, delete unused assets or components. Volume does not — nothing you delete gives back a credit already spent.
Monthly volume returns at the start of the UTC month, the AI pool at UTC midnight. For a one-off spike this is often the whole answer.
The *Subscription* tab of the same page carries the plan change and, where your plan marks a resource as purchasable, the one-off packs. A pack becomes its own credit lot straight away.
Limits and capabilities can be raised for a single organisation without moving tiers. That is how closed betas and non-standard contracts are handled — talk to your Notifizz contact.
The billing page stays reachable on every plan, including a lapsed one — it is the way back.
## FAQ
Check the campaign's Sends breakdown. A quota tail shows as `quota_exceeded:` on the step's channel, on the cross-channel total, or both — and the recipients who did receive it are the first of the batch, not a random half. If the reason says `unsubscribed` or `suppressed` instead, it was consent, not budget.
Because every send costs one credit on its channel and one on the cross-channel total. The total is a separate bound, and the tighter of the two caps a batch. It is what stops a single generous channel from uncapping your whole footprint.
Not for delivery failures — the credit is taken when the message is handed off, and a bounce is a delivery outcome, not a metering error. AI credits are different: a run that fails before producing anything is refunded. See [AI credits](/docs/plans/ai-credits).
No. Only `Live` campaigns consume. A campaign in Review can be simulated as often as you like, and it costs nothing — which is the point of having a review step at all.
Yes, exactly the same. The ceiling is checked where the campaign is actually created, so the dashboard, the copilot and MCP all hit one verdict. The tool surfaces the same `limit_exceeded:campaigns` refusal.
Nothing that exists. You keep and can keep editing every campaign, component and asset you own. Only new creations are refused, until you archive or delete enough to come back under the ceiling.
Almost certainly not — it is a channel your plan does not carry. A closed channel has no credits, so every recipient on that step is dropped under its quota reason. The gauge for it reads *Not included in your plan*.
## See also
Metered volume, stored resources and capabilities — what each one bounds.
The daily pool: what burns it, and what stops when it is empty.
The rest of the funnel, after a recipient survives every filter.
Statuses — and why only `Live` consumes.