Tallwatch
Back to blog
2 min read
Status pagesGuide

How to subscribe customers to status updates without spamming them

Status email should feel like a smoke alarm, not a newsletter. Here is how to set expectations, cadence, and unsubscribe so people stay subscribed.

NK

Nabin Khair

Founder

How to subscribe customers to status updates without spamming them

A status subscriber list dies two ways: you never email, so nobody bothers joining, or you email like a product launch blog during every blip. The useful middle is rare, clear, and easy to leave.

What people think they signed up for

"Tell me when your product is broken or recovering." Not changelog. Not tips. Not "we are excited to announce." Put that sentence on the subscribe form.

Cadence rules

  • Investigating: once, quickly.
  • Updates: when impact changes, or at the interval you promised (status copy).
  • Resolved: once, with end time.

Do not send five "still looking" notes with no new facts. Do not skip resolve because you are tired, or subscribers refresh forever.

Maintenance

Announce planned windows that customers will feel. Skip tiny internal restarts. If everything is a maintenance email, they will filter you.

Unsubscribe is a feature

One click, no guilt screen. People who leave are not enemies; they are inbox triage. Fighting them creates spam complaints that hurt everyone.

Who should be on the list

  • Customers who asked
  • Admins who opted in from the status page
  • Maybe a support alias

Not your entire marketing CRM. Mixing those lists is how status mail inherits promotional reputation problems.

Status pages that support email subscribers with unsubscribe in the message (Tallwatch included) are for incident traffic. Keep product news in the product news tool. Different jobs, different lists.

Related

Keep reading

False alerts and status pages.

Incident timelines customers can follow (without a novel)

Incident timelines customers can follow (without a novel)

A good public timeline is a sequence of dated facts. Not a blog post, not a void: enough for someone refreshing on their phone.

NKNabin Khair
Why your status page shouldn't live on the same servers as your app

Why your status page shouldn't live on the same servers as your app

If the product is down and status.yourdomain.com is too, you have lost the one URL customers use to decide whether to wait or panic.

NKNabin Khair
How many status page components is too many?

How many status page components is too many?

Twenty microservices on a status page confuse customers and guarantee permanent yellow. Name what they buy, then stop.

NKNabin Khair