When to Use a Status Page vs Just Emailing Customers

Your SaaS went down at 2 AM. The question is not whether to tell your customers. It's where. And for most indie hackers, the honest answer is not the status page you set up in an afternoon because real companies have one. It's email.

Here's the uncomfortable bit. A status page with no visitors isn't communication. It's a prop. We put together a full roundup of status page tools this week, and the tools are good. The question this post answers is different. When do you actually need one?

What Is a Status Page Actually For?

A status page does one job well. It answers "is it down for everyone or just me?" for people who have no direct line to you. Strangers evaluating your product, users who never open your emails, a procurement team checking your uptime history before signing.

Notice what all of those have in common. Scale and anonymity. A status page is broadcast infrastructure for an audience you can't reach individually.

Now flip it around. If you have 40 paying customers, you don't have an anonymous audience. You have a list of names. You know which of them are affected. Broadcasting to strangers is solving a problem you don't have yet.

When Is a Status Page Just Theater?

Three signs, and most early-stage projects show all of them.

Nobody visits it. Check the analytics. If your status page gets four hits a month and two are you, it isn't informing anyone. It's decoration.

You forget to update it. This is the killer. An unattended status page defaults to green. So during your real outage, the page says all systems operational while customers stare at error screens. That's worse than having no page, because now you look dishonest instead of just small. Solo founders mid-incident are debugging, not updating comms tools. Be realistic about which one you'll drop.

It exists to look bigger than you are. Buyers aren't fooled, and the maintenance debt is real.

When Does Email Win?

Under about 100 paying customers, email wins on every axis that matters.

It's push, not pull. The status page requires customers to wonder whether something's wrong and go check. Email lands in front of them with the answer before most of them noticed.

It's personal. "We broke something, here's what happened, here's what we're doing" from a founder builds more trust at small scale than any uptime widget. Some of my most loyal users came out of a well-handled outage email.

And it's free at this size. Kit is free up to 10,000 subscribers with unlimited broadcasts, which covers any indie SaaS customer base several times over. Beehiiv is free to 2,500 subscribers with unlimited sends. Either one holds your customer segment and sends an incident email in five minutes. You'll likely already run one of them for your newsletter anyway.

The incident email itself is three sentences. What broke. What still works. When you'll update them. Send the fix confirmation later, that second email is where the trust actually gets built.

What Does Each Path Cost?

The money is honestly a rounding error either way. Instatus has a free status page with 15 monitors, capped at 200 subscribers. OpenStatus is free for one monitor and one page at 10-minute checks, and its Starter plan runs $30/month. Email is $0 at indie scale on either tool above.

The real cost is attention. A status page is one more thing that must be correct during the worst 40 minutes of your month. An email is written once, when you need it. Pay the attention cost only when the page produces something back, and that requires visitors.

How Do You Decide?

flowchart TD
    A[Something broke. Who needs to know?] --> B{Do buyers or B2B customers ask for a status page?}
    B -- yes --> C[Run a status page and update it religiously]
    B -- no --> D{More than ~100 customers, or strangers checking if you're down?}
    D -- yes --> C
    D -- no --> E[Email your customers directly]
    C --> F[Still send the email. The page never replaces it.]

One nuance the diagram can't hold. The two are not rivals forever. Once you do run a status page, incident email stays in the loop, because the page informs strangers while email reaches the people paying you. Pairing the page with uptime monitoring so it updates itself removes most of the stale-green risk, and decent log management is what tells you what to write in that first email.

The Bottom Line

Under 100 customers, put the afternoon into your incident email template, not a status page. Past that, or the day a B2B buyer asks, stand the page up, wire it to your uptime monitor so it can't lie, and keep emailing the humans who pay you. The status page is for strangers. The email is for customers. Don't confuse the audiences.

Handled an outage well by email? Tell me how it went on X @devtoolpicks.