Add a Free Status Page to Your SaaS With BetterStack (2026)

Photo by Luke Chesser on Unsplash

You can put a hosted, custom-domain status page in front of your SaaS in about ten minutes, for free, using BetterStack. A status page is a public page — usually at an address like status.yourdomain.com — that shows whether your service is up, tracks incidents, and lets customers subscribe for updates instead of emailing you "is it just me?" during an outage. BetterStack's free tier includes uptime monitors and a status page on your own domain, which is the exact combination a solo founder wants and most competitors lock behind paid plans. This guide covers when you actually need one, what to monitor, and the full setup, wired up the way I'd do it for a Next.js SaaS.

TL;DR

• BetterStack's free tier includes 10 monitors, 10 heartbeats, and one status page on a custom domain with 3-minute checks.
• Set up your monitors first, then build the status page from them — the page is a view over your monitoring, not a separate thing.
• Monitor what customers actually feel: your landing page, your app, your login/auth path, and any critical third-party dependency.
• Point status.yourdomain.com at BetterStack via a DNS record. That subdomain convention (see status.stripe.com) is what users expect.
• You don't need this at zero users. You need it the first time an outage generates support tickets you had to answer one by one.

What a status page is (and why it's not vanity)

A status page is a dedicated page that tells your users whether your service is operational, without them having to contact you. That's the entire job, and it's more valuable than it sounds. According to BetterStack's own documentation, the primary purpose is to let users check status themselves — which directly removes load from you during exactly the moments you're most stressed.

Think about the mechanics of an outage for a solo founder. Something breaks. Within minutes, the emails start: "Is the app down?" "I can't log in." "Did my payment go through?" Each one demands a reply, and you're trying to fix the actual problem at the same time. A status page short-circuits that loop. You post one update, and every worried customer sees it instead of opening a ticket. It converts a flood of one-to-one support into a single one-to-many broadcast.

There's a trust dimension too. Every serious SaaS you use has a status page — status.stripe.com, status.slack.com, and so on. Publishing one signals that you take reliability seriously enough to be transparent about it. Counterintuitively, admitting when you're down builds more confidence than pretending you never are. Customers don't expect perfect uptime; they expect honesty when things break.

The flip side, and I'll be straight about this: a status page is not monitoring. It's a display over your monitoring. If you don't have monitors watching your service, a status page is just a green box you forget to update. The value comes from the two working together — automated checks detect the problem, the status page communicates it. That's why the setup order matters, and why we start with monitors.

When you actually need one

Not every project needs a status page on day one, and I'd rather you spend early time on the product. Here's the honest trigger line: you need a status page the first time an outage costs you more in support replies than the setup would have cost you in time. For most SaaS, that's somewhere between your first ten and first hundred paying customers.

Before you have paying users, skip it. An outage annoys nobody who'll email you, and your time is better spent shipping. The exception is if you're selling reliability itself — an API, a monitoring tool, anything where uptime is the product. Then a status page is table stakes from launch, because prospects will look for it as due diligence.

Once you have paying customers who depend on your app during their workday, the calculus flips. The first time you have a bad thirty minutes and spend the following two hours answering "is it back yet?" emails one at a time, you'll wish you had a page. Setting one up beforehand is cheap insurance. It also pairs naturally with the rest of your operational tooling — if you've already added Sentry error tracking to your Next.js SaaS, you have the "something broke" detection; a status page is the "and here's how we tell customers" half.

If you're thinking about your broader support setup, a status page slots in alongside the tools I covered in customer support tools for solo founders — it's arguably the highest-leverage one, because it deflects tickets before they're created rather than helping you answer them faster.

What to monitor

The mistake I see founders make is monitoring the wrong thing — pinging their homepage and calling it done, while the actual app silently fails. Monitor what your customers feel, not what's easy to check. Here's the priority order for a typical SaaS.

Start with your marketing site and your app as separate monitors. These often live on different hosts or domains, and one can be up while the other is down. Your landing page being fine doesn't mean paying customers can log in.

Next, monitor a real functional path, not just "does the server respond with a 200." The login and authentication flow is the one that matters most — if auth is down, your entire app is effectively down for everyone even if every page loads. A monitor that hits a health-check endpoint verifying your database connection and auth provider are reachable is worth ten monitors that just check whether the front page renders.

Then add your critical third-party dependencies. If your app can't function without Stripe, Supabase, or your email provider, an outage in any of them is your outage as far as customers are concerned. BetterStack's free tier gives you 10 monitors, which is plenty to cover your site, app, health check, and your handful of critical vendors.

Here's how the pieces connect once you've got monitors feeding a status page:

flowchart LR
    A[Uptime monitors<br/>site, app, auth, vendors] -->|check every 3 min| B[BetterStack]
    B -->|outage detected| C[Status page<br/>status.yourdomain.com]
    B -->|alert| D[You: Slack / email]
    C -->|automatic update| E[Subscribed customers]
    D -->|you post update| C

The heartbeat monitors are worth a mention too. A heartbeat is the inverse of an uptime check: instead of BetterStack pinging you, your background job pings BetterStack on a schedule, and if the ping doesn't arrive, you get alerted. That's how you catch a cron job or a nightly email sequence that silently stopped running — the kind of failure a normal uptime check never sees. The free tier includes 10 of these.

Setting it up, step by step

The setup genuinely takes about ten minutes. Here's the sequence, following BetterStack's getting-started guide.

First, create your monitors. In the BetterStack dashboard, add a monitor for each thing from the previous section — your marketing URL, your app URL, a health-check endpoint. Point each at the URL and let BetterStack start checking. On the free tier these run every 3 minutes, which is fine for a SaaS at this stage; you're not running a stock exchange.

Second, create the status page. Go to Status pages → Create a status page, enter your company name (it shows in the top-left of the page), and either take a *.betteruptime.com subdomain or configure your own. I'd configure your own from the start — it's free and it looks far more professional.

Third, personalize it. Add your logo, your website URL, and your brand color. This is a customer-facing page, so it's worth the two minutes to make it look like it belongs to your product rather than a generic template.

Fourth, attach your monitors. Click the Structure tab, then drag your monitors from the Available column to the Selected column. Give each a friendly public name — customers should see "Web app" and "Login," not the raw internal URL. You can group related services and add short descriptions.

Fifth, save. The moment you click Save changes, the page is live at your chosen URL. That's it — you now have a public status page backed by real monitoring.

There's one more thing worth doing while you're calm, because you won't want to think about it mid-outage: prepare your incident updates in advance. When something breaks, a monitor going red will flip the affected service on your page automatically, but the message to customers is yours to write. BetterStack provides incident communication templates you can build from, and drafting two or three ahead of time — "investigating," "identified, working on a fix," "resolved" — means that during a real incident you're editing a sentence, not composing under pressure. Good incident updates are short, honest, and frequent: acknowledge fast, say what you know, and give a next-update time even if the answer is "we're still looking."

If you want the finishing touch, BetterStack lets you embed status announcements directly into your own site, so an active incident can show a banner inside your app, not just on the standalone page. That's optional, but it's a nice way to meet customers where they already are.

Pointing it at your own domain

The subdomain convention exists for a reason: users instinctively try status.yourdomain.com when they think your app is down. Meeting that expectation is worth the five minutes of DNS work. BetterStack's docs note that most companies use exactly this status. subdomain format, citing status.stripe.com and status.slack.com as the pattern to follow.

The mechanics are the same DNS work you'd do for any subdomain. In your domain registrar or DNS provider, you add a CNAME record for status pointing at the target BetterStack gives you in the custom-domain settings, and BetterStack provisions the SSL certificate so the page is served over HTTPS. If you've already set up a custom domain on Vercel for your SaaS, this is the same muscle memory — one more CNAME record in the same dashboard.

A quick word on public versus private. Most SaaS want a public status page anyone can see. But BetterStack also supports password-protected private pages, which is the right call for an internal tool or a B2B product where you only want specific clients seeing system status. You choose per page, so you can even run both — a public one for customers and a private, more detailed one for your own team.

How BetterStack compares on the free tier

BetterStack isn't the only free status page tool, and picking based on the actual free-tier limits beats picking based on brand recognition. Here's how the realistic free options compare for a solo SaaS.

| Tool | Free monitors | Custom domain (free) | Check frequency | Notes | | --- | --- | --- | --- | --- | | BetterStack | 10 | Yes | 3 min | Status page + monitoring + heartbeats in one | | UptimeRobot | 50 | Limited | 5 min | More monitors, status page more basic | | Instatus | Status page focused | Yes | Bring your own monitoring | Great page, no built-in monitoring | | Statuspage (Atlassian) | Limited free | No on free | N/A | Polished but pricier as you grow | | Self-hosted (Uptime Kuma) | Unlimited | Yes | Configurable | Free but you run and maintain it |

The reason I reach for BetterStack for an indie SaaS is that it bundles the monitoring and the status page and heartbeats into one free account with a custom domain — you're not stitching together two services. UptimeRobot gives you more raw monitors, which is great if you have many endpoints, but its status page is more basic. Instatus makes a beautiful page but expects you to bring monitoring from elsewhere. And self-hosting Uptime Kuma is genuinely free forever, but now you're operating another service — which, for a solo founder whose time is the scarcest resource, usually defeats the purpose.

Whatever you pick, the principle holds: the tool matters less than actually having the two halves — detection and communication — working together before your first real outage.

Frequently asked questions

Is BetterStack's status page really free?

Yes. The free tier includes 10 monitors, 10 heartbeats, and one status page with a custom domain and 3-minute checks. Custom domain support on a free plan is genuinely unusual — many competitors reserve it for paid tiers.

What should a SaaS status page monitor?

Monitor what customers experience: your marketing site, your app, and critically your login/auth path, plus any third-party service your app can't function without (Stripe, your database, your email provider). A health-check endpoint that verifies your database and auth are reachable beats a simple homepage ping.

Do I need a status page for a brand-new SaaS?

Usually not before you have paying customers, unless reliability is your product (an API or monitoring tool). The trigger is your first outage that generates support tickets — set one up before that happens, since it's cheap and fast.

How do I get status.mydomain.com to work?

Add a CNAME record for the status subdomain in your DNS provider, pointing at the target BetterStack provides in its custom-domain settings. BetterStack issues the SSL certificate automatically so the page serves over HTTPS.

Can I make a status page private?

Yes. BetterStack supports password-protected status pages, which suits internal tools or B2B products where only specific clients should see system status. You set visibility per page and can run public and private pages side by side.

What's the difference between a monitor and a heartbeat?

An uptime monitor pings your service to check it's up. A heartbeat is the reverse — your background job pings BetterStack on a schedule, and if the expected ping doesn't arrive, you're alerted. Heartbeats catch silent failures in cron jobs and scheduled tasks that uptime checks miss.

Wrapping up

A status page is one of the highest-leverage things a solo founder can set up, precisely because it does its best work when you're at your most stretched — mid-outage, trying to fix the thing while customers pile up in your inbox. BetterStack makes it a ten-minute job on a free plan: create monitors for what customers actually feel, build a status page over them, point status.yourdomain.com at it, and you've turned a support flood into a single broadcast. Do it before you need it, not during the outage that teaches you why.

If you're building your SaaS with AI coding tools and want the monitoring, error-tracking, and support integrations laid out with copy-paste setup guides, the Coding Capybaras marketplace has the wiring for the operational stack that sits around a status page — Sentry, PostHog, and the rest — so you're not researching each one from scratch.