# Email Monitor email event notification delivery and logs. Source: https://statusdashboard.com/docs/notifications/email > This is a plan-gated feature. If it isn't available in your account, visit the [Billing](/docs/org-mgmt/billing) page or contact support to review your options. This page covers HTML email format, send history, delivery logs, and the suppression list for event notifications. Open [Email history](/app/notifications/email/history), [Email delivery logs](/app/notifications/email/logs), and [Email suppression](/app/subscribers/email/suppression) in the admin console. For org-wide subscriber admin, see [Email subscribers](/docs/subscriptions/email). For how visitors subscribe on `/subscribe`, see [Email subscriptions](/docs/status-dashboards/subscriptions/email). When an event with **Notifications** enabled triggers a delivery, matching verified email subscribers receive a message describing the event at send time. For incidents and maintenance, the email includes an **Impact Analysis** section after the description when that field is set (before affected components). Description, impact analysis, and timeline messages keep the formatting you author in the event editor: **bold**, *italic*, strikethrough, links, bullet or numbered lists, and inline code. Email is the only notification channel that renders the full rich-text HTML body. For how **Visibility** and subscription toggles affect delivery across channels, see [Notifications overview — FAQ](/docs/notifications#frequently-asked-questions). Turning the dashboard **Subscriptions** Email toggle off hides public sign-up; existing verified subscribers still receive deliveries. *** ## Subject line **Incidents and maintenance** ``` [Business Name][event_type: current workflow status] event_title ``` **Informational events** ``` [Business Name][Informational Event] event_title ``` | Part | Description | | --------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Business Name** | Your organization's display name — the same value shown as **Business name** on the [Account](/app/account) page | | **event\_type** | `incident` or `maintenance` | | **current workflow status** | The event's latest workflow phase (e.g. `Investigating`, `In Progress`, `Resolved`) | | **event\_title** | The event title; truncated to 50 characters with `...` when longer | Examples: * `[Acme Corp][incident: Investigating] API degradation` * `[Acme Corp][maintenance: In Progress] Database upgrade` * `[Acme Corp][Informational Event] Planned maintenance window` ### Dashboard visibility and subscriptions For how **Visibility** and subscription toggles affect delivery across channels, see [Notifications overview — FAQ](/docs/notifications#frequently-asked-questions). Email-specific effects: | Setting | Effect on event notification emails | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Dashboard Visibility off** | Emails still send with full event content. No **View event** button or **Post-Mortem Available** callout (the dashboard would return 404). | | **Event not published** | Emails still send with full event content. No **View event** button or **Post-Mortem Available** callout (the event page would return 404). | | **Subscriptions toggle off** | Emails still send to existing subscribers. Sign-up and self-service manage flows are hidden; admins can still add and edit subscribers on [Email subscribers](/app/subscribers/email/subscribers). | | **Dashboard and event both public** | Emails include a **View event** button linking to the event on the status dashboard. A **Post-Mortem Available** callout is included when the report is published. | See [Subscriptions overview](/docs/status-dashboards/subscriptions) for what the dashboard subscription toggle controls on the public status page. ## Monthly email quota Event notification emails count against your organization's **emails per month** plan quota (UTC calendar month). Check usage on the [Overview](/app) page or via `GET /app/overview` (`emailMessages.count` vs `emailMessages.limit`). * **Subscription emails** (verify and manage links from your status dashboard) do **not** count toward this limit. * When you are at or over the limit, new event notifications are **not delivered**. Delivery stops at the limit (partial batches send only what remains). Skipped sends are **not retried**. * Event saves always succeed — quota applies only to asynchronous outbound delivery. ## Send history [Email history](/app/notifications/email/history) shows a UTC calendar-month bar graph of **event notification email sends** per day. Use it to answer usage questions such as how many emails you sent on a given day or how volume trended last month, without scanning individual delivery log rows. * Navigate **13 months** of history (current UTC month plus the prior 12) with previous/next month controls. * Counts match the same population as your monthly **emails per month** quota on [Overview](/app) (event notifications only; subscription verify/manage emails are excluded). * Days with no sends appear as zero-height bars. The summary line shows the month total. * All bucketing uses **UTC calendar days and months**. ## Delivery logs [Email delivery logs](/app/notifications/email/logs) are an **organization-wide** audit trail of outbound notification messages — not tied to a single event or dashboard row. They answer whether a message was accepted, delivered, bounced, or skipped before send. After StatusDashboard hands a notification off to your email provider, each row shows what happened next: | Field | Meaning | | ------------- | ---------------------------------------------------------------------------------------------------------- | | **Recipient** | Who the message was addressed to | | **Subject** | Message subject at send time | | **Type** | What triggered the send — event notification, subscription verify, or subscription manage | | **Status** | Aggregate outcome (see below) | | **Timeline** | Provider lifecycle events appended after handoff (accepted, sent, delivered, bounce, complaint, and so on) | Use **Filter by recipient** to search for a specific address. Logs are retained for **30 days**, then removed automatically. ### Status values | Status | Meaning | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Submitted** | Log row created; handoff to the provider may still be in progress | | **Sent** | Accepted by the provider for delivery | | **Delivered** | Provider confirmed delivery to the recipient's mail system | | **Bounced** | Permanent or transient delivery failure reported by the provider | | **Complained** | Recipient marked the message as spam (feedback-loop providers only) | | **Rejected** | Provider rejected the message before delivery | | **Failed** | Handoff failed before the provider accepted the message | | **Suppressed** | Send was **skipped** because the recipient is on your organization's [suppression list](#email-suppression-list) — the provider was never called and no quota is consumed. Clear on [Email suppression](/app/subscribers/email/suppression). | A **Suppressed** row is intentional: it records that a notification would have been sent but was blocked to protect your sending reputation. See [Email suppression list](#email-suppression-list) for how to clear an address when the underlying issue is fixed. ## Email suppression list Hard bounces and spam complaints can damage deliverability for everyone on your account. StatusDashboard maintains an **organization-wide suppression list** on [Email suppression](/app/subscribers/email/suppression) so bad addresses are not retried on every future notification. > Suppression is > **not** > the same as turning > **Notifications** > off on an event or clearing a subscriber's components. Those controls stop > *new* > notifications from being triggered. The suppression list blocks delivery to specific > **email addresses** > across all notification sends until you remove them. ### How addresses get on the list | Reason | When it is added | | ------------- | ---------------------------------------------------------------------------------- | | **Bounce** | The provider reports a **permanent** (hard) bounce for a tracked notification send | | **Complaint** | The provider reports a spam complaint for a tracked notification send | Soft or transient bounces do **not** add an entry. Each address appears once per organization with the reason, timestamps, and a short detail summary when available. Entries **do not expire**. They stay until an admin deletes them. ### Gmail and complaint feedback Gmail does not send spam-complaint feedback to StatusDashboard. A recipient who marks your message as spam in the Gmail web client will **not** automatically appear on this list (or on the provider's tenant suppression list). Other mailbox providers that participate in the standard feedback loop will generate complaint entries as expected. ### Removing an address Click **Remove** on a row and confirm. StatusDashboard removes the address from your organization's suppression list. If removal cannot be completed, the entry remains and you can retry — nothing is partially removed. * Removing an entry **allows future notification sends** to that address when the next qualifying event or subscription email runs. * StatusDashboard does **not** resend missed notifications automatically. * If the address is still invalid, the next send may hard-bounce and the address will be suppressed again. Only remove an address after you have confirmed the mailbox issue is fixed (typo corrected, mailbox restored, list owner updated, and so on). ## Frequently asked questions **Why does a delivery log show Suppressed instead of Bounced?** The recipient was already on your organization's [suppression list](#email-suppression-list) when the notification was evaluated. StatusDashboard skipped the send and wrote a **Suppressed** log row. Check the suppression list to see why the address was blocked and whether it is safe to remove. **An address bounced once — will we keep emailing them?** After a **permanent** bounce (or a complaint), the address is added to the [suppression list](#email-suppression-list) and future notification sends are skipped until you remove it. Soft bounces do not add a suppression entry; you may see a **Bounced** delivery log without a matching suppression row.