A status page that nobody is notified from is a page people have to remember to check. Almost nobody does. That 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 up subscriber notifications comes down to a small number of decisions. You choose which channels to offer, what to send on, and how to keep the list from teaching people to ignore it.
Which notification channels should a status page offer?
A status page should offer email by default and add SMS, webhook, Slack and calendar channels only for the audiences that need them. These channels split into groups that 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. Examples are an on-call engineer at a customer who integrates against your API, or an ops lead who has to decide whether to fail over. SMS costs real money per message, and carrier fees show up on published SMS price lists. That 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. Examples are a customer's own status-page aggregator, an internal dashboard, or a Slack channel where an ops team watches every vendor they depend on. Slack documents its incoming webhooks for exactly this kind of server-to-server post.
Webhook and Slack channels fan out HTTP traffic from your infrastructure. That 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 as an ICS feed (iCalendar, RFC 5545) sees the next planned outage on their actual calendar. That 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. The form can reveal the rest for the subset of visitors who need them.
What should trigger a notification?
A status page should notify on state changes a subscriber could not have predicted, not on every keystroke of an incident. That rule keeps a subscriber list valuable.
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. "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.
Some edits 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. No single email is the problem. The pattern 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. 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 many notifications per incident is too many?
More than three or four subscriber notifications for a single incident is the point to look at what triggered each one. There is no fixed number of emails per incident that is correct, but the pattern is worth watching.
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. It rarely means 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, but the same monitor emailing every customer is a trust problem.
Confirmation and unsubscribe: the parts that protect deliverability
Every subscriber should go through a confirmation step, either 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. The standard for the header that makes this possible is RFC 8058. A subscriber who has to find a settings page and log in to stop receiving your emails will instead mark your messages as spam. That damages deliverability for every other subscriber on the same domain far more than a clean unsubscribe does.
A well-run subscriber setup
A subscriber picks email or SMS at signup, confirms once, and from then on hears from you exactly at the moments listed above. Those moments are 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.
A subscriber also does not have 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.
The update text should hold to the same standard when it goes out. The incident communication templates worth using are specific about what happened, not vague about it. A subscriber list only works if what arrives in it is worth opening.
RealUptime Status subscribers can pick email or SMS on any account. Webhook and Slack channels are on paid plans, for teams that want their own systems wired directly into incident and maintenance events. A calendar feed for maintenance windows is available on any account.