Status pages

Email subscribers

Visitors of a status page can subscribe to incident emails. How they sign up, who gets what, what it costs, the limits, removing someone and what happens to their address.

Verified November 5, 2026

Visitors of a published page can ask for an email when you post about an incident. They confirm their address first, and every incident email lets them leave with one click.

Every published page offers this. There is no setting to hide the control, and you don't have to turn anything on. Nobody gets an email until you post an update with notify on, or an automatic post sends one.

How a visitor subscribes

  1. They open Subscribe, next to the language menu, and type their address. A page with more than one component also offers Only some components. Nothing chosen means all of them.
  2. They get a page that says "Check your email" and one confirmation email.
  3. The email's link opens a page with a Confirm subscription button, and pressing it confirms the address. Opening the link alone changes nothing, because mail scanners follow links. The link works for 7 days.

The form works without JavaScript and sets no cookie. It has its own address, /subscribe, on the page's default address and on its custom domain. Preview links don't show it. It takes submissions only from the page itself: there is no public API for subscribing, and a form on another site is refused.

The answer doesn't reveal who is subscribed. A known address and a new one get the same page, which says the link is on its way "unless this address is already subscribed".

Language. A subscriber's emails come in the language the page was showing when they subscribed: English, German, French, Italian, Spanish, Polish, Czech or Simplified Chinese. The fixed text is translated and your own text stays as you wrote it.

Changing a choice. Asking again with a confirmed address changes nothing. To change components or language, unsubscribe and subscribe again.

What the emails contain

The confirmation email has the subject "Confirm your subscription to Acme status", says what the address is signing up for and holds the confirmation button. It tells a person who didn't ask to ignore it. Nothing else goes to an address until it confirms.

An incident email is one update of a post:

PartExample
Subject[Acme status] Investigating: Elevated API errors
StatusThe update's status, translated
TitleThe post's title
TextThe update's text
AffectedThe public names of the components the post names, if any
LinkView incident, to the post on your page
FooterWhy they get this, an Unsubscribe link and "Sent by Norcube Monitor"

Each email has an HTML part and a plain text part. It holds what the update said when you posted it. Correcting a post afterwards sends nothing and doesn't change emails already queued.

Who gets what

An update goes to the subscribers that were confirmed when it was written, and only when you asked for it to be sent. Components decide the rest:

The subscriber choseThe post namesThey get it?
All componentsAnything, or nothingYes
Some componentsNo componentsYes
Some componentsAt least one of theirsYes
Some componentsOnly components not theirsNo
  • Choosing every component means the whole page, components you add later included.
  • The match uses the components the post names at that update. An update that changes the list is matched against the new list.
  • A component you remove from the layout stays in a subscriber's choice. If it was their only one, they hear only about posts that name no components.

An update is not sent:

  • On an unpublished page. A draft tells nobody. If you unpublish a page while emails are queued, those are dropped, aren't counted and aren't sent later.
  • For an organization blocked over unpaid invoices. Queued emails are dropped in the same way. Published pages stay up.

A failed send is tried up to 8 times, with waits growing from 1 minute to about an hour, and is then given up. A send that fails for good, or never goes out, counts nothing. In rare cases, when a worker stops right after the provider accepted an email, the same email goes out twice. It is counted once.

A long list takes time: about two minutes for 5,000 subscribers, or longer on a slow provider. Pages take turns, so one page's list doesn't hold up another page's emails.

Unsubscribing

Every incident email has an Unsubscribe link, and the List-Unsubscribe and List-Unsubscribe-Post headers that let a mail client offer its own one-click button (RFC 8058). The link opens a page with a button. The mail client's button needs no page.

Unsubscribing deletes the address and any email queued for it. The person sees "You're unsubscribed" and can subscribe again later. The confirmation email has no unsubscribe link, because ignoring it is enough.

Addresses that stop working

When an email can't be delivered for good, or the person marks it as spam, Norcube Monitor removes the address from your list, along with any email queued for it. You don't get a notice: the address is simply gone from the list, as after an unsubscribe, and nothing about it is kept.

  • A temporary delivery problem removes nobody. Delivery is retried.
  • Only the subscription the failed email belongs to is removed. The same address on another page, or in an alert channel, stays.
  • Such an address stays blocked at the email provider, so if it subscribes again the confirmation email may not arrive.

What it costs

Each email sent counts as the email_notifications metric, the same one as email alerts. This covers confirmation emails too. It is your organization's usage, not the subscriber's. See Pricing.

  • An email counts once, when it is sent. Failed and dropped emails count nothing.
  • One post with three updates, all with notify on, sent to 1,000 subscribers, is 3,000 emails.
  • Confirmation emails go out whoever typed the address. A script filling in your form can cause up to 100 of them an hour for each page, which is the rate limit below.
  • An email that bounces still counts, because it was sent. The address then leaves the list.

The limit

Your organization has limit 504, max_status_page_subscribers: a safety cap of 5,000 confirmed subscribers per organization, counted over all its pages. A plan can set a different value. To raise it, contact support.

  • Unconfirmed addresses don't count, so nobody can fill the cap with addresses that never confirm.
  • An address subscribed to two of your pages counts twice.
  • A value of 0 means nobody can subscribe.
  • At the limit, the form says "This page isn't taking new subscribers right now." An address that tries to confirm at that point sees "We couldn't add you", with the same reason, and can use its link again while it still works.
  • An organization blocked over unpaid invoices takes no new subscribers either, and visitors see the same message.
  • Lowering the limit deletes nobody. An email then stops at the new limit, with the oldest subscribers first.

Rate limits on the form

LimitValue
Per client network10 requests an hour
Per page100 requests an hour
Confirmation emails1 a day per address, per page

A client network is the visitor's address, or its /64 for IPv6. A visitor over either of the first two sees "Too many tries from your network. Please try again later." An address asking twice in a day gets no second email, and the page answers as usual.

See and remove subscribers

In the dashboard, a page's subscribers section shows the count and the list, and lets you remove someone or export a CSV. From a terminal (CLI 0.24.0 or later):

nrc monitor status-pages subscribers list acme
nrc monitor status-pages subscribers delete acme <subscriber>

The CLI has no commands for the count or the export. nrc api reaches them.

Through the API:

MethodPathAction
GET/status-pages/{id}/subscribers/count{ "confirmed": 120, "pending": 3 }. No addresses.
GET/status-pages/{id}/subscribersThe addresses, confirmed and pending, newest first, with cursor paging.
GET/status-pages/{id}/subscribers/exportAll of them as CSV.
DELETE/status-pages/{id}/subscribers/{subscriberId}Removes one, with any email queued for it.

Removing someone sends them nothing, keeps no record of the address, and doesn't stop them subscribing again. The audit log records the removal by subscriber id, without the address.

The CSV has the columns email, status, locale, components, createdAt and confirmedAt. components holds component ids separated by spaces, and is empty for a subscriber of the whole page. Times are UTC. A cell a spreadsheet would run as a formula gets a leading '. The audit log records each export, with its count.

There is no import, and no way to add an address by hand: every subscriber confirms for themselves. Addresses need their own permission. See Limits, scope and permissions.

The sender

Emails come from [email protected], and the display name is the page's name. There are no custom sender domains and no reply-to setting today, so a reply doesn't reach you. Links in the email use the page's custom domain while one is active.

If you change the page's address, emails already sent keep the old one, which redirects for 30 days. A mail client's one-click unsubscribe keeps working after that. The link opened in a browser may not.

What happens to the data

  • Stored: the address, its language, its chosen components and the times it signed up and confirmed. The client's network address is used for the rate limit, and is not stored with the subscriber.
  • Unconfirmed addresses are removed after 7 days, counted from their last confirmation email.
  • Unsubscribing deletes the address. So does your removing it, and deleting the page or the organization.
  • Unpublishing keeps subscribers. They hear from the page again once it is published again and you post.
  • Addresses stay in Monitor's database. They don't go to logs, the audit log, the page's public data or the edge store, and only the mail provider (Mailgun) gets them, to deliver. The form passes through Cloudflare on its way. The database is encrypted at rest, and the column has no separate encryption.
  • Delivery records hold no address, and go after 30 days.

On this page