Why Customers Expect to Hear From You During Downtime

When your service goes down, silence is the worst thing you can offer. Users assume the worst — that you do not know, do not care, or are hiding the problem. The research is consistent: customers who hear about an incident from you are dramatically more forgiving than those who discover it themselves. One study by Forrester found that proactive communication during outages reduces churn-intent by more than 40% compared to no communication at all.

A public status page is the first half of the solution. It gives users a place to check. But a status page by itself is a passive channel — it only helps the users who think to visit it during an incident. The second half is an active channel: notifying customers directly, by email, the moment an incident starts. That is what this guide is about.

Trust is earned in the worst moments — Every incident is a test of your transparency. Customers remember how you communicated far longer than they remember the outage itself.
Support load drops dramatically — When users already know there is an incident and receive automatic updates, "is the site down?" tickets evaporate.
Enterprise buyers check for this — Procurement teams increasingly require subscriber-based incident notifications as part of their vendor evaluation. Its absence is a red flag.

Active vs Passive Status Pages — The Subscriber Gap

Most free and self-hosted status page tools give you a page and stop there. Users can bookmark the URL, but they have to remember to check it. That is a passive channel. During a major incident, passive means slow — most of your affected users will never see the page until they are already frustrated.

An active status page lets customers subscribe by email. When an incident is created, updated, or resolved — or when scheduled maintenance starts or ends — subscribers get a notification automatically. No login. No app. No RSS reader. Just an email that hits their inbox the same way a shipment notification does.

The gap between "we have a status page" and "our customers actually know when something is broken" is huge. Subscribers close it. If you are using a tool that does not support subscriber email notifications, you have a status page in name only.

What a Good Subscriber Flow Looks Like

A good subscriber flow respects three constraints: it must be easy for customers, it must be spam-resistant for you, and it must comply with email and privacy regulations. Here are the non-negotiables:

Double opt-in — When a visitor enters their email, you send a confirmation email first. Only after they click the confirmation link are they actually subscribed. This prevents malicious actors from signing up other people's addresses and protects your sender reputation.
RFC 8058 one-click unsubscribe — Every notification email must include a one-click unsubscribe header that lets mail clients (Gmail, Outlook, Apple Mail) show an "Unsubscribe" button next to the sender name. Since February 2024, Google and Yahoo require this for bulk senders. Skipping it will tank your deliverability.
No account required — Customers should not have to create an account or log in to subscribe. The subscribe form is a single email field. Friction kills subscription rates.
Instant removal — When a user unsubscribes, their record is deleted immediately. No "it may take 7 days" language. No CAPTCHA. No "are you sure?" confirmation step.
GDPR-friendly — Store only what you need (email + verification timestamp + unsubscribe token). Document it in your privacy policy. Provide an unambiguous consent step (that is what the double opt-in is).

If you are building this yourself, every one of these requirements is a small amount of work that adds up. If you are using a monitoring platform with status pages built in, it should already be handled. Before picking a tool, check the actual unsubscribe flow — click "subscribe" on their demo, confirm the email, then click unsubscribe. If it takes more than one click, your customers will hate it.

Which Events Should Trigger a Notification

Resist the urge to notify subscribers about everything. Over-notification is the fastest way to train your subscribers to ignore you, and it causes them to unsubscribe for real. A tight, opinionated event set works best:

Incident created — Something is broken. Send this the moment the incident is opened on the status page. This is the most important email you will ever send to a subscriber — it is the one that determines whether they forgive you or not.
Incident update posted — New information about an active incident. Only send if there is substantive new info: identified root cause, a fix deployed, or a revised ETA. Do not send "we are still looking into it" as an email — put that on the page.
Incident resolved — The issue is fixed and service is restored. Always send this. Subscribers need closure — without the resolved email, they will keep checking the page and wondering.
Maintenance scheduled — An upcoming maintenance window is announced. Send when the window is created, with enough lead time for customers to plan around it (at least 24 hours where possible).
Maintenance started / ended — The window has begun or finished. Useful for shorter windows where customers might otherwise think it is an unplanned outage.

That is five event types — not fifty. Per-event idempotency on the backend ensures you never double-send if a worker retries. Customers should never receive two emails for the same event.

Step-by-Step: Enable Subscribers in GoPinger

If you already have a GoPinger status page (or are about to create one — see our complete status page setup guide), enabling email subscribers takes about thirty seconds:

Create a status page — From the dashboard, open Status Pages and create a new page. Pick a slug, add your services, and publish. The public URL (gopinger.com/status/your-slug) is live immediately.
Turn on subscribers — Subscribers are enabled by default. Your public status page already has a subscribe form visible to visitors. No toggle, no configuration, no extra cost.
Verify the email flow — Enter your own email on the public page. You should receive a verification email within seconds. Click the link. You are now a subscriber.
Post a test incident — From the dashboard, create a test incident on the status page. All verified subscribers receive an email automatically. Open the email — you will see the incident title, description, status, timestamp, and the one-click unsubscribe link at the bottom.
Resolve and verify — Mark the incident resolved from the dashboard. Subscribers receive a resolution email. Click the unsubscribe link — you are removed instantly, no login required.

That is the entire setup. Status pages with email subscribers are included on every plan, starting with the free plan — with no per-subscriber fees. Learn more on the dedicated status page subscribers feature page, or see how it fits into the broader status pages feature.

Copywriting Tips for Incident Emails

Good incident emails are short, direct, and honest. Bad incident emails sound like they were written by a legal team trying to avoid liability. Here is what works:

Subject line says what is broken — Not "Service Advisory" or "Status Update". Say "API Gateway — Elevated Error Rates" or "Login Unavailable". Users should know from the subject line whether this affects them.
Lead with the impact — First sentence: what does not work, who is affected, since when. Everything else comes after.
Give a time estimate, even a rough one — "We expect resolution within the hour" is far better than silence. Users would rather hear a rough estimate than nothing.
Avoid corporate hedging — Do not write "some users may be experiencing intermittent issues with certain features." Write "the API is returning 500 errors for all requests."
Take responsibility — Do not blame vendors, weather, cosmic rays, or "an unexpected issue." Own it: "We deployed a bad database migration at 14:02 UTC."
Close with what you are doing — "Our team is rolling back the migration and monitoring recovery." Users want to know the ship is being steered.

Pre-write templates for each incident phase — investigating, identified, monitoring, resolved. Under pressure, your team will not have time to craft careful copy. Good templates ensure consistent, professional communication even when the engineer on-call is firefighting.

Measuring Success

Once subscribers are live, track a few simple metrics to confirm the channel is actually working:

Subscriber growth rate — Steady growth means the subscribe form is visible and users find value in it. If growth is flat, add prominent links to your status page from your product, docs, support emails, and 4xx/5xx error pages.
Email open rate for incident emails — Incident emails should have extremely high open rates (60-80% is normal). If yours are lower, your sender reputation may be damaged or your subject lines may be too vague.
Unsubscribe rate after incidents — A small spike after each incident is normal. A large spike means either the incident was severe enough to cause churn, or your communication tone was off. Investigate either way.
Support ticket volume during incidents — The killer metric. Compare ticket volume for incidents before and after enabling subscribers. Teams typically see 40-60% fewer incident-related tickets once active communication is in place.

A status page is a phone book. Subscribers are the phone call. You need both. If your current tool gives you one without the other, you are half-covered during every incident — and your customers are the ones paying for it.

Every GoPinger plan — including the free tier — includes a status page with email subscribers, double opt-in verification, RFC 8058 one-click unsubscribe, and automatic notifications for all five incident event types. No add-ons. No paid tiers. No per-subscriber pricing. See the feature details, check the pricing page, or read our guide on incident management to see how subscribers fit into the full incident lifecycle.