Monitor email notification delivery, sending health, and logs.
This page covers HTML email format, sending health, send history, delivery logs, and the suppression list for event notifications. Open Email deliverability, Email history, Email delivery logs, and Email suppression in the admin console. For org-wide subscriber admin, see Email subscribers. For how visitors subscribe on /subscribe, see Email subscriptions.
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. 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_titleInformational 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 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. 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. |
| 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 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 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.
Email deliverability
Email deliverability shows whether event-notification email sending is healthy, warned, or paused for your organization, plus bounce and complaint rates and active reputation findings for a selectable UTC window (7, 14, or 30 calendar days).
- Overview includes a one-word deliverability status on the Email row when email is entitled.
- Paused sending means new event notifications are not delivered until sending is restored — review Email suppression, delivery logs, and contact support if you need help.
- Bounce and complaint rates measure all outbound email for your organization in the selected window, including subscription verify and manage messages. Event-notification-only volume is on Email history and the monthly quota on Overview.
- Daily breakdown uses UTC calendar days. The current day is only counted through the time you load or refresh the page — not the full 24 hours until midnight UTC.
- Findings list open sending-health issues — such as elevated bounces, complaints, or blocklist listings — with a short description and severity. Use them to decide what to review in suppression and delivery logs.
Sending health statuses
Overview and Email deliverability show one Sending health status for your organization. If more than one issue applies at the same time, you see the one that matters most for delivery — for example Paused when sending is blocked, even if bounce rates are also elevated, because that is when mail stops going out.
| Status | What it means | Do emails go out? |
|---|---|---|
| Healthy | Sending is enabled and reputation monitoring reports no elevated concern. | Yes — event notifications, subscription verify, and subscription manage mail send normally (subject to monthly quota and suppression). |
| Warning | Reputation monitoring reports an elevated concern (for example rising bounces or complaints). | Yes — sending is still enabled. Treat this as a signal to review suppression, delivery logs, and list quality before conditions worsen. |
| Critical | Reputation monitoring reports a serious concern. | Usually yes until sending is explicitly Paused — but you should act immediately. StatusDashboard may pause sending automatically when reputation thresholds are breached. |
| Paused | Outbound email for your organization is blocked at the sending layer. | No — new sends are rejected. This applies to all outbound mail for the org (event notifications and subscription emails). |
| Restored | Sending was paused and has been turned back on; previous issues may still be monitored. | Yes — mail sends again, but reputation may remain under watch. |
| Pending | Email is entitled, but your organization's dedicated sending setup is not ready yet. | Not yet — wait until setup completes (typically shortly after first use). |
| Unavailable | StatusDashboard could not load sending health (temporary error). | Unknown until the status loads again — check back or refresh. Other email features may still reflect delivery outcomes in logs. |
StatusDashboard does not define the exact bounce or complaint percentages that trigger Warning, Critical, or Paused. Those thresholds are enforced by automated reputation monitoring on your organization's isolated sending channel. When available, Findings on the deliverability page describe what changed (bounce rate, complaints, blocklist listings, and similar) in plain language.
When email stops (and what happens to a new event)
Sending stops only when status is Paused (or Pending before setup completes). Warning and Critical are alerts — they do not by themselves turn off the Monthly email quota counter on Overview, but they mean you should fix list and content issues before a pause.
When you publish an event with Notifications enabled:
- The event save always succeeds — deliverability does not block editing or publishing.
- Notification delivery runs asynchronously after publish (not inline with the save).
- If sending is Paused at handoff time, each recipient send is rejected, logged as Failed in delivery logs, and not retried when sending is restored later.
- StatusDashboard does not queue paused mail for a later automatic resend. Missed notifications stay missed unless you trigger a new notification (for example a follow-up event update) after sending is healthy again.
That pause behavior is different from these cases:
| Situation | What happens |
|---|---|
| Monthly quota reached | Remaining recipients in that batch are skipped; logged as quota exhaustion. Not retried next month. |
| Suppression list | Recipient skipped before send; Suppressed log row. No quota consumed. |
| Temporary rate limiting | Unsent recipients in the batch may be deferred briefly and retried when capacity is available. |
You cannot pause, resume, or change sending rules from the admin console — StatusDashboard manages those automatically based on sending health. Contact support if you need sending restored.
Send history
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 (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 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 — the provider was never called and no quota is consumed. Clear on 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 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 so bad addresses are not retried on every future notification.
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 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 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.