Subscriber notifications

Subscriber notifications are the push half of a status page. Rather than requiring customers to check, the page lets them subscribe — by email, SMS, webhook or a chat integration — and sends them updates when status changes. For anyone who depends on your service to run their own, this is the difference between finding out from you and finding out from their own customers.

What gets sent matters more than the mechanism. The useful set is small: an incident opening, meaningful updates while it runs, resolution, and scheduled maintenance before it starts. Sending more than that turns a channel people opted into for outages into one they mute, and a muted subscription is worse than no subscription because both sides believe communication is happening.

The delivery path has the same independence requirement as the page itself, and it is the half most often forgotten. Notifications sent by a worker inside the infrastructure that just failed will not be sent. Sending them from a separate path — and having them queued durably so a delivery that fails is retried rather than lost — is what makes the promise real.

One overlooked audience: your own support and sales teams. They are asked first and are often told last, and subscribing them to the same feed removes an entire category of internal confusion during an incident.