> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senderz.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Notifications
> The bell in the top bar: what Senderz tells you about, which notices also arrive by email, how noisy things like bounces are batched into one daily notice, and how reading and dismissing work across your team.
Senderz posts a notice when something needs your attention or when something you started has finished. Notices live behind the bell in the top bar.
They are not a log of everything that happens. They are the short list of things worth interrupting you for.
## Where to find them
The bell sits in the top bar on every screen. A red badge shows how many notices you have not read yet. Above 99 it shows `99+`.
Opens a panel with your five most recent notices. Each one shows a title, a
line of detail, and how long ago it arrived.
Choose **See all notifications** at the bottom of the panel. You can also
open the command palette and search for **Notifications**.
The full list has two tabs, **All** and **Unread**, and shows up to the 50 most recent notices. There is no sidebar entry for it and no older-than-50 archive.
## Reading and clearing
Click it. That marks it read, and if the notice links somewhere it takes you
straight there. A campaign failure opens the campaign, an import notice opens
the import report, a domain notice opens Domains.
**Mark all as read** clears the badge. Nothing is deleted, so you can still
read the notices afterwards.
The **X** on a notice removes it from the bell and from the list. This cannot
be undone.
Most notices belong to the workspace, not to you personally. Marking one read
or dismissing it changes it for everyone in the workspace. If a teammate says a
notice disappeared, someone dismissed it.
## Who receives what
| Audience | Which notices |
| ----------------------------------- | ------------------------------------------------------------- |
| Everyone in the workspace | Deliverability, campaign, contact, integration and AI notices |
| Owners and admins only | Billing and plan notices, one private copy each |
| The person who submitted a campaign | The approval decision on that campaign |
## Categories
Every notice carries one of these categories: **System**, **Campaigns**, **Contacts**, **Deliverability**, **Integrations**, **Billing** and **AI**.
The list can only be filtered by **All** and **Unread** today. There is no
category filter in the interface, and no way to turn an individual category
off.
## What generates a notice
| Notice | Also emailed |
| ----------------------------------------------------------------------- | --------------------------- |
| Addresses suppressed in the last 24 hours, as one daily digest | No |
| A sending domain lost its verification, and again when it comes back | Yes, to the workspace owner |
| A sending domain appeared on a spam blocklist, and again when it clears | No |
| A dedicated sending IP request was approved or declined | No |
See [Domains and authentication](/en/deliverability/domains) for what to fix
when a domain loses verification.
| Notice | Also emailed |
| ----------------------------------------------------------------- | ----------------------------------- |
| A campaign failed, or sent but some recipients failed | No |
| A campaign was submitted for approval | Yes, to the approvers |
| A campaign was approved, rejected, or sent back for changes | Yes, to the person who submitted it |
| A unique coupon code pool is running low or has run out | No |
| A campaign or automation is still using a coupon that was deleted | No |
A coupon notice matters because sends are skipped once the pool empties. See
[Coupons](/en/messaging/coupons).
| Notice | Also emailed |
| ------------------------------------------------------------------------- | ------------ |
| A contact import finished, with how many were added and how many rejected | No |
| A contact import failed, with the reason | No |
Import notices link to the import report, which lists the rejected rows and
why. See [Importing contacts](/en/audience/import).
| Notice | Also emailed |
| ----------------------------------------------------------------- | ------------ |
| A store was connected | No |
| A store was disconnected | No |
| A store needs to be reconnected because its authorisation expired | No |
The reconnect notice is the important one. Until you act on it, orders and
customer updates stop arriving. See [Integrations](/en/integrations/overview).
| Notice | Also emailed |
| -------------------------------------- | ------------ |
| You are approaching your contact limit | No |
| Your plan was upgraded automatically | Yes |
| Your plan upgrade needs your approval | Yes |
| An automatic upgrade did not complete | Yes |
| A subscription payment failed | Yes |
Billing notices go to owners and admins only. Emails also go to the billing
email address on the workspace if one is set.
| Notice | Also emailed |
| ------------------------------------------------------------------------ | ------------ |
| Your AI provider rejected the key, denied access, or ran out of quota | No |
| Your configured model was unavailable so Senderz switched to another one | No |
| You reached 80% or 100% of your monthly AI budget | No |
These only appear if you have connected your own AI provider. See
[AI provider](/en/integrations/ai-provider).
| Notice | Also emailed |
| ------------------------------------------------------------------ | --------------------------- |
| A WooCommerce customer sync finished | Yes, to the workspace owner |
| An SMS Sender ID was approved, rejected or revoked | Yes, to the workspace owner |
| Accelerated warmup for a domain was approved or declined | Yes, to the workspace owner |
| Past profiles were added to an automation, or that backfill failed | No |
## Noisy events are batched, not repeated
A single campaign can produce hundreds of bounces. One notice per bounce would make the bell useless, so Senderz groups them.
One notice a day, covering the previous 24 hours. It counts hard bounces,
spam complaints and repeated soft bounces on email, and links to your
suppression list.
Store connect, disconnect, reconnect, domain verification, blocklist and AI
provider notices are limited to one per day for the same store, domain or
problem.
Other batching rules worth knowing:
* **Imports** produce one notice per import, not one per row.
* **AI budget** produces one notice per threshold per calendar month.
* **A campaign failure** updates the existing notice instead of adding a second one, and returns to unread when the detail changes.
* **Coupon pool** warnings are checked at most once every few minutes, and repeat at most once a day per coupon.
Because a notice is deduplicated by day, a problem that persists across several
days produces one notice per day until it is resolved. That is intentional.
It is a reminder, not a new incident.
## Billing notices also open a dialog
A billing or plan notice does not only sit in the bell. The next time you open Senderz as an owner or admin, it opens as a dialog with a link to **Settings → Plans & billing**. Closing the dialog marks that notice read.
This is deliberate. A missed contact limit or a failed payment changes what you are allowed to send, so it should not be possible to scroll past it.
## AI budget notices are an estimate of your own bill
If you set a monthly AI budget, Senderz warns you at 80% and again at 100% of it.
The figure is an estimate built from published model rates for the calls you made. AI usage is billed to you directly by your AI provider, never by Senderz. If you used a model with no published rate on file, the notice says so, and the real total is higher than the number shown.
## Limits
* The list holds the 50 most recent notices. There is no paging and no archive beyond that.
* Filtering is **All** or **Unread** only.
* Dismissing is permanent, and for workspace notices it removes the notice for everyone.
* You cannot choose which notices you receive, and you cannot switch a category to email only.
* Notices are not a delivery guarantee. For anything that also sends email, treat the email as the record.