# SMS Monitor SMS event notification delivery and logs. Source: https://statusdashboard.com/docs/notifications/sms > 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 SMS message format, send history, delivery logs, and the suppression list for event notifications. Open [SMS history](/app/notifications/sms/history), [SMS delivery logs](/app/notifications/sms/logs), and [SMS suppression](/app/subscribers/sms/suppression) in the admin console. For org-wide subscriber admin, see [SMS subscribers](/docs/subscriptions/sms). For how visitors subscribe on `/subscribe`, see [SMS subscriptions](/docs/status-dashboards/subscriptions/sms). When an event with **Notifications** enabled triggers a delivery, matching verified SMS subscribers receive a short text describing the event at send time. Description and impact analysis are flattened to plain text (lists appear as lines; link URLs may appear in the message body). Messages are kept concise and include opt-out language. A short link to the event is included when the dashboard and event are public. For how **Visibility** and subscription toggles affect delivery across channels, see [Notifications overview — FAQ](/docs/notifications#frequently-asked-questions). Turning the dashboard **Subscriptions** SMS toggle off hides public sign-up; existing verified subscribers still receive deliveries. *** ## Message format Messages are kept concise (ideally a single SMS segment) in this general shape: **Incidents and maintenance** ``` [Business Name] Incident: current workflow status. event_title https://your-status-host/l/shortCode Reply STOP to cancel ``` **Informational events** ``` [Business Name] Info: event_title https://your-status-host/l/shortCode Reply STOP to cancel ``` | Part | Description | | ----------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Business Name** | Your organization's display name — the same value shown as **Business name** on the [Account](/app/account) page | | **event type / status** | Short labels such as `Incident: Investigating` or `Maint: In Progress` (informational uses `Info`) | | **event\_title** | The event title; truncated when needed so the full message stays short | | **short link** | Temporary link to the event on your status dashboard (`/l/…`) | | **STOP line** | Opt-out language required for compliant SMS | Examples: * `[Acme Corp] Incident: Investigating. API degradation` plus short link and STOP line * `[Acme Corp] Maint: In Progress. Database upgrade` plus short link and STOP line * `[Acme Corp] Info: Planned maintenance window` plus short link and STOP line ### Dashboard visibility and subscriptions For how **Visibility** and subscription toggles affect delivery across channels, see [Notifications overview — FAQ](/docs/notifications#frequently-asked-questions). SMS-specific effects: | Setting | Effect on event notification SMS | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Dashboard Visibility off** | SMS still send with the event summary. No short link is included (the dashboard would return 404). | | **Event not published** | SMS still send with the event summary. No short link is included (the event page would return 404). | | **Subscriptions toggle off** | SMS still send to existing subscribers. Sign-up and self-service manage flows are hidden; admins can still add and edit subscribers on [SMS subscribers](/app/subscribers/sms/subscribers). | | **Dashboard and event both public** | SMS include a short link to the event on the status dashboard. | See [Subscriptions overview](/docs/status-dashboards/subscriptions) for what the dashboard subscription toggle controls on the public status page. ### Short links Event (and subscription) SMS use temporary **short links** on your status dashboard host so the text stays short. * Links are created per send and **expire automatically** after a retention window (event-view links are retained for **30 days**). * Opening a short link on the **wrong** host (or after expiry) does not reveal the target — visitors see an in-app message on that status page (not the platform “status page doesn’t exist” page). * Open short links on the **live** status dashboard hostname for that dashboard. ## Monthly SMS quota Event notification SMS count against your organization's **SMS messages per month** plan quota (UTC calendar month). Check usage against your plan limit (`enabledFeatures.smsMessages`). * **Subscription SMS** (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 [SMS history](/app/notifications/sms/history) shows a UTC calendar-month bar graph of **event notification SMS sends** per day. Navigate **13 months** of history with previous/next month controls. Counts match your monthly SMS quota population on [Overview](/app) (event notifications only). All bucketing uses UTC calendar days and months. ## Delivery logs [SMS delivery logs](/app/notifications/sms/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, blocked, or skipped before send. After StatusDashboard hands a notification off to your messaging provider, each row shows what happened next: | Field | Meaning | | ------------- | -------------------------------------------------------------------------------------------------------- | | **Recipient** | Who the message was addressed to (phone number) | | **Preview** | Truncated message body 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, queued, delivered, blocked, and so on) | Use **Filter by recipient** to search for a specific number. 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 | | **Queued** / **Pending** | Intermediate provider states while delivery is in progress | | **Delivered** | Provider confirmed delivery (or carrier acceptance, depending on country) | | **Blocked** | Permanent-class failure reported by the provider (invalid number, carrier block, spam, protect, and so on) | | **Failed** | Handoff failed before the provider accepted the message | | **Skipped** | Send was **skipped** because the recipient is on your organization's [suppression list](#suppression) — the provider was never called and no quota is consumed. Clear on [SMS suppression](/app/subscribers/sms/suppression). | A **Skipped** row is intentional: it records that a notification would have been sent but was suppressed to protect deliverability and honor opt-outs. See [Suppression](#suppression) for how to clear a number when the underlying issue is fixed. ## Suppression Hard failures and opt-outs can damage deliverability and compliance for everyone on your account. StatusDashboard maintains an **organization-wide suppression list** on [SMS suppression](/app/subscribers/sms/suppression) so problem destinations are not retried on every future notification. When a number is suppressed, **all outbound texts** to that destination are skipped — event alerts, verification texts, and manage links. The send is recorded in [delivery logs](#delivery-logs) as **Skipped** (no quota consumed). > Suppression is > **not** > the same as turning > **Notifications** > off on an event, clearing a subscriber's components, or deleting a subscriber row. Those controls affect > *who is subscribed* > or > *what triggers a send* > . The suppression list stops delivery to specific > **phone numbers** > until the entry is cleared. ### STOP and START Event and subscription texts include **Reply STOP to cancel**. When someone replies **STOP** (or an equivalent keyword such as **END**, **CANCEL**, or **UNSUBSCRIBE**): * Their number is added to your suppression list with reason **Opt-out**. * **No further texts are sent** until the suppression is cleared. * They **remain on your subscriber list** — phone, dashboard, and component selections are unchanged. STOP is a delivery suppression, not a subscription delete. To receive texts again, the subscriber can reply **START** (or an equivalent re-opt-in keyword such as **UNSTOP** or **YES**). StatusDashboard clears the **Opt-out** suppression for your organization. Texts resume on the **next** qualifying send — missed alerts are **not** sent again automatically. They must still be a verified subscriber with at least one component selected to receive event notifications. ### Subscriber preferences vs. suppressed delivery | Action | Subscriber list | Future texts | | ------------------------------------------------ | ------------------------------ | ------------------------------------- | | Clear all components (manage page or admin edit) | Kept; status **No components** | None until components are added again | | Reply **STOP** | Kept; selections unchanged | None until opt-out is cleared | | Admin **Delete subscriber** | Removed from that dashboard | None | ### How numbers get on the list | Reason | When it is added | | ---------------------- | --------------------------------------------------------------------------- | | **Opt-out** | The recipient replies with STOP (or an equivalent keyword) | | **Invalid** | The provider reports the destination number as invalid | | **Carrier blocked** | The carrier or device blocks messages to that destination | | **Spam** / **Protect** | The provider or protect rules block the message as abusive or non-compliant | **START** clears **Opt-out** suppressions only. Suppressions for invalid, carrier blocked, spam, or protect are **not** cleared by START — fix the underlying issue, then remove the row as an admin when appropriate. ### Transient failures vs. permanent suppressions A single failed delivery does **not** always add a permanent suppression. | What happened | Suppression list | What to expect next | | -------------------------------------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------- | | **Temporary issue** (phone off, out of coverage, busy network) | Usually **not** added | The next send may succeed — check the [delivery log](#delivery-logs) timeline | | **STOP reply** | **Opt-out** added | Future sends skipped until **START** or you remove the suppression after confirming consent | | **Invalid**, **carrier blocked**, **spam**, or **protect** | Added with matching reason | Future sends skipped until you remove the suppression after fixing the issue | Entries **do not expire**. They stay until an admin deletes them (or a carrier-level opt-out continues to reject sends independently). ### Removing a number Click **Remove** on a row and confirm. That clears the number from StatusDashboard's suppression list for your organization. * Removing an entry **allows future sends** when the next qualifying event or subscription text runs (unless the carrier still rejects the destination). * If the recipient previously opted out with STOP, they should text **START** as well. Removing a row here alone may not be enough — a failed send can re-add an **Opt-out** suppression automatically. * StatusDashboard does **not** resend missed notifications automatically. * If the number is still invalid or opted out at the carrier, the next send may fail and the number may be suppressed again. Only remove a number after you have confirmed it is appropriate to resume contact (consent restored, typo fixed, and so on). ## Frequently asked questions **Why does a delivery log show Skipped instead of Blocked?** The recipient was already on your organization's [suppression list](#suppression) when the notification was evaluated. StatusDashboard skipped the send and wrote a **Skipped** log row. Check the suppression list to see why the number was suppressed and whether it is safe to remove. **A number failed once — will we keep texting them?** After a **permanent-class** failure (invalid, carrier blocked, spam, protect) or an **opt-out**, the number is added to the [suppression list](#suppression) and future notification sends are skipped until you remove it. Transient failures do not always add a suppression entry; you may see a failed timeline event without a matching suppression row. **Why does a short link show “Link not valid”?** The status dashboard still loaded — only that link is unusable. Common causes: the temporary link expired, the code was mistyped, or it was opened on a different status-dashboard host. This is different from the platform message that the **entire** status page does not exist.