Status pages got marketed as table stakes. For a weekend prototype with three users, they are not. For a B2B SaaS with contracts and Slack channels full of "is it down?", they are one of the cheapest trust tools you can buy.
You probably need one if
- People use the product to do their job every day.
- You have (or want) uptime language in contracts.
- Support already fields repeat "is it just me?" tickets during blips.
- Prospects ask for operational maturity in sales calls.
- You have had at least one incident where customers heard nothing while you scrambled.
Three or more of those → stop debating and ship a page.
You can wait if
- Nobody outside your laptop depends on the service.
- You are pre-revenue and still pivoting weekly.
- The only users are teammates who sit next to the deploy channel.
Even then, keep a written incident habit. The page can come when the first customer would have used it.
What "small" still requires
- Hosted off your main app so a product outage does not take the page with it.
- A few components named the way customers think (Login, API, Billing) — not twenty microservices.
- Updates during incidents — even short ones. Silence reads as hiding.
- History — a green forever page with no incidents looks fake; real history builds trust.
Automation from monitoring helps, but only if the monitors are honest. A status page wired to flaky checks becomes a public false-alarm machine. Pair the page with trustworthy detection — see your status page is only as honest as your monitoring.
The decision in one line
If you would rather customers refresh a URL than email support during a bad hour, you need a status page. If nobody would think to look, wait — and set a reminder for the week you sign the customer who will.
