I added a status page to my SaaS before I have a single paying customer
Just shipped status.buildbase.app for my product. It monitors 7 services: website, auth, dashboard, docs, demo app, product API, and central API.
Here's why it feels backwards: I have 100+ signups and $0 MRR. Most people put up a status page after their first outage embarrasses them into it. I did it early for three reasons.
First, the outside-in view. Uptime dashboards behind the admin login are almost useless during an outage. You're checking the same stack that's probably broken. A public status page pings from external nodes and shows you what your users see. That's a completely different signal, and I want it as the default from day one.
Second, transparency is a habit, and habits are cheaper to build before there's a real cost to breaking them. If I wait until we have a paying customer to put one up, my first instinct during our first real outage will be to hide it and hope they don't notice. If a public status page is already the default, I don't get that option. The muscle is built before it's tested.
Third, Better Stack took 15 minutes to wire up. There is no meaningful cost to shipping it now. Waiting for a milestone to justify a 15-minute task is just procrastination dressed up as prioritization.
The honest tension I'm sitting with: the page shows "100% uptime" because monitoring literally started this week. That's not a real trust signal, it's just how the tool works. Going to add a footer note that historical data starts from launch date so it doesn't read as fake.
For anyone else pre-first-customer: at what stage did you put up a status page? Was it before, after, or during your first outage?
Link if you're curious: https://status.buildbase.app
Before the first customer is a sensible stage when setup and upkeep are this small. I would label the history with the monitoring start date, as you plan, and treat the early 100% as a data window rather than a reliability claim. I would also write a three-line incident update template now: affected capability, what users should expect, and the next update time. That makes the page useful on the first bad day without forcing you to compose policy while debugging.
Put mine up around the same stage, and the useful part turned out to be the incident log, not the uptime bar. A green page nobody was watching did nothing; the first honest "we dropped webhooks for 40 minutes, here's what we replayed" write-up was what people actually referenced later. Two things I'd add while it's cheap: monitor a real end-to-end path (signup or a test payment/webhook round trip), not just 7 HTTP 200s, because the outages that hurt are the ones where every service is up and the job queue is stuck. And write the incident template now, while you're calm — during the first real outage you won't want to compose prose. The "history starts at launch" footer is the right call, 100% with a week of data reads as a bug otherwise.
Got it. Looking into for cron jobs and other hooks