A status page that nobody is notified from is a page people have to remember to check. Almost nobody does, which is why the subscriber list, not the page itself, is the part of a status page that actually reduces support tickets during an incident. Setting it up is mostly a small number of decisions: which channels to offer, what to send on, and how to keep a subscriber list from teaching people to ignore it.
Pick channels by who is actually subscribing, not by what looks impressive
Status page subscriber channels typically split into two groups, and they serve different audiences even though vendors list them on the same signup form.
Email is the default for a reason: everyone has one, it costs nothing to send, and it is the channel someone checks when they are not actively firefighting. It is also the wrong channel for genuine emergencies, because nobody treats an unread inbox as urgent in real time.
SMS is for the smaller list of people who need to know within minutes, not the next time they check their inbox: an on-call engineer at a customer who integrates against your API, or an ops lead who has to decide whether to fail over. It costs real money per message (carrier fees do not disappear because the feature is convenient), which is the honest reason most vendors, RealUptime included, treat it as a distinct opt-in rather than bundling it with email by default.
Webhook and Slack channels exist for the audience that is not a person at all: a customer's own status-page aggregator, an internal dashboard, or a Slack channel where an ops team watches every vendor they depend on. These fan out server-to-server HTTP traffic from your infrastructure, which is why they tend to be a paid-tier feature rather than a free one: a webhook channel is a standing integration a vendor has to keep working and rate-limit responsibly, not a one-time email send.
Calendar feeds are the quiet fourth option worth offering specifically for maintenance windows: a subscriber who adds your maintenance schedule to their calendar as an ICS feed sees the next planned outage sitting on their actual calendar, which beats hoping they read an email three weeks before it matters.
The mistake to avoid is offering every channel to every subscriber by default. A signup form with five tabs (email, SMS, Slack, webhook, calendar) in front of someone who just wants email updates about your API is a worse experience than a form that defaults to email and reveals the rest for the subset of visitors who actually need them.
What should trigger a notification, and what should not
The rule that keeps a subscriber list valuable: notify on state changes a subscriber could not have predicted, not on every keystroke of an incident.
Concretely, these should send:
- A new incident opens. This is the "is it down" answer arriving before the question gets asked.
- An incident's status changes in a way that changes what the subscriber should expect. Moving from "investigating" to "identified" tells them a fix is understood, "identified" to "monitoring" tells them the fix is live and being watched, and "resolved" tells them it is over. Each of those is new information.
- A maintenance window is scheduled, with enough lead time that "planned" means something. A maintenance notice sent five minutes before the window starts is functionally the same as an unplanned outage from the subscriber's point of view.
- A maintenance window is starting, sent once, at the moment it begins, distinct from the earlier "scheduled" notice: someone who only reads the second one still knows work is happening right now.
- A maintenance window is cancelled, but only if it was announced in the first place. Cancelling a window nobody was told about has nothing to apologize for.
These should not send a fresh notification: editing an incident's internal notes, fixing a typo in a previous update, or adding detail to an update that does not change the customer-facing status. A subscriber who gets three emails for one incident because someone corrected a comma learns, correctly, that your notifications are not worth opening promptly. That is the actual cost of over-notifying: not that any single email is annoying, but that it trains the reader to stop treating your emails as urgent, which defeats the entire point of having a subscriber list.
Rescheduling a maintenance window is a middle case worth calling out specifically: moving the time or changing which part of the product is affected is new information and should re-notify. Fixing a typo in the title should not.
How often is too often, in practice
There is no fixed number of emails per incident that is correct, but there is a pattern worth watching for: if a single incident generates more than three or four subscriber notifications, look at what triggered each one before assuming the incident was just eventful. A ten-minute outage that generates six emails is usually a sign the trigger logic is firing on internal state changes a subscriber never asked about, not a sign the incident was unusually complicated. Compare that against a genuinely long incident: investigating, identified, monitoring, resolved is four sends over several hours, each one carrying real information, and nobody unsubscribes over that.
The same logic applies across incidents, not just within one. A service with a flapping check that opens and closes an incident every few minutes is not an incident at all, it is a detection problem, and subscriber notifications are the wrong place to absorb that noise. Fix the check's failure threshold before the subscriber list has to live with it; a flapping monitor that pages a human is annoying, the same monitor emailing every customer is a trust problem.
Confirmation and unsubscribe: the parts that protect deliverability, not just etiquette
Every subscriber should go through a confirmation step (a link they click, or a code they enter) before their first notification counts as delivered. This is not just good manners: an unconfirmed subscriber is someone who typed an email address into a box, which includes typos and, occasionally, someone else's address entirely. Sending real incident traffic to an unconfirmed address is how a status page's outbound email domain ends up flagged, which then delays every legitimate notification behind it.
Unsubscribing needs to be one click, from the email itself, with no login required. A subscriber who has to find a settings page and log in to stop receiving your emails will instead mark your messages as spam, which damages deliverability for every other subscriber on the same domain far more than a clean unsubscribe does.
What this looks like set up well
A subscriber picks email or SMS at signup, confirms once, and from then on hears from you exactly at the moments listed above: a new incident, a real status change, a scheduled maintenance window and its start, and resolution. Nothing else. A subscriber who wants their own systems wired in adds a webhook or a Slack channel instead of polling a page. Someone who wants the maintenance calendar on their actual calendar adds the feed once and never thinks about it again.
None of this requires a subscriber to trust that a human remembered to send the update. If the underlying checks are what open and close the incident (see status page best practices for the rest of that case), the notifications that go out are a direct report of what was measured, not a paraphrase written under pressure. That is also what the actual update text should say when it does go out: the incident communication templates worth using are specific about what happened, not vague about it, for the same reason a subscriber list only works if what arrives in it is worth opening.
RealUptime Status subscribers can pick email or SMS on any account, with webhook and Slack channels on paid plans for teams that want their own systems wired directly into incident and maintenance events, plus a calendar feed for maintenance windows on any account.