How to Build a Public Status Page for Your SaaS in 10 Minutes
The moment something breaks, customers don't know if it's your service, their internet connection, or their browser having a bad day, so a lot of them do the same thing: email support. During an actual outage, that means your team is fixing the problem and simultaneously fielding a flood of nearly identical "is this just me?" tickets, at exactly the moment they have the least time to answer them. A status page exists to intercept that. Point people at it, and most of them will check it before writing in.
This walks through setting one up in Downdar, from nothing to a working, live page.
What You Will Need
A Downdar account with at least one monitor already set up, whatever you'd want reflected on the page. If you haven't created any monitors yet, do that first, a status page is only useful once it has something real to report on.
Step 1: Create the Status Page
The /api/v1/status/create endpoint needs just a name to get started, everything else is optional and can be set later:
New pages start as a draft with an empty layout, nothing shows publicly until you add monitors and publish it, so there's no risk of a half-configured page going live by accident. You can just as easily do this step from your Downdar dashboard instead.
Step 2: Customize the Page's Appearance
A status page has a handful of real settings worth knowing about: theme (dark by default, or light), display_mode (compact by default, or detailed), show_targets (whether the actual monitor URLs are visible on the page, off by default), a title_url if you want the page's title to link back to your main site, and background, header, and text colors if you want to match your own branding rather than the theme defaults.
Step 3: Add Monitors and Publish
A fresh page has an empty layout, so the next step is adding the monitors you want visible. This doesn't have to be everything in your account, an internal admin tool or a staging environment monitor has no reason to be on a customer-facing page, only add what customers would actually recognize: your main site, your API, anything they'd notice if it went down. You can also group monitors into named sections, "Core services" and "Third-party dependencies" as separate groups, for instance, rather than one flat list.
Once the layout looks right, set published to published to make the page live. The page reflects your monitors' real-time state automatically from that point on, there's no manual step where someone has to remember to mark an incident as ongoing, and no manual step where someone forgets to mark it resolved afterward.
Step 4: Control Who Can Embed It
Every status page gets a public URL automatically. If you also want to embed it inside your own site or app via an iframe, rather than only linking out to the standalone page, add your domain to embed_origins first, Downdar only allows a page to be embedded on hostnames you've explicitly listed:
Once that's set, an iframe pointed at the page's public URL will load correctly from your listed domain.
What Customers See During an Incident
Once it's live, the page becomes the answer to "is it just me?" Point support macros, your Twitter/X bio, an in-app banner, wherever customers are likely to look when something feels wrong, at the page instead of leaving them to guess. Some teams link to it directly from a 500 error page too, since that's often the exact moment someone's about to go looking for an explanation.
Plan Limits
The number of status pages available depends on your plan, Downdar returns your current usage and remaining quota whenever you create one, so it's easy to check programmatically if you're managing several pages across projects.
Get Started
The whole setup, creating the page, customizing it, adding monitors, and publishing, genuinely takes about as long as reading this article. Do it before you need it, not during the next incident when you're already busy.