A status page that's driven by your actual incidents.
When you declare an incident, the status page already says so — because it's the same incident, not a second thing to go and update.
Custom domain, certificates handled, a feed your customers can subscribe to, maintenance windows. The parts you'd expect — plus the part nobody else has.
90-Day Uptime
99.8%Dashboard loading slowly for some customers
InvestigatingWe're seeing elevated load times on the dashboard for some customers and are investigating. We'll confirm here once load times recover.
Posted
Your status page is a view of the incident, not a second job.
Most status-page tools are a separate tool. You run the incident in one place — your inbox, your monitor's alert, a Slack thread — and then, when you remember, you go and update the status page by hand. At 2am, in three Slack threads, that's the step that gets missed. So the page says "all systems operational" while your customers are watching the thing fall over.
StayUpfront doesn't work that way. The status page is the customer-facing rendering of the incident your team is already on. Declare the incident, and the affected components flip to the right status automatically. Post an update on the incident, and it's already on the page. There's nothing to keep in sync, because there's no second surface — it's one incident, shown two ways.
One incident. Every surface updates from it.
You set the severity. Your customers see plain English.
Inside the incident, your team works in the detail — is this critical, major, or minor? Your customers don't need that vocabulary. They need to know whether the thing they rely on is working, kind of working, or down.
So the severity you set maps to a public state automatically — no second place to keep in sync. A critical incident reads as a major outage. A major incident reads as a partial outage — broken for some, not everyone. A minor incident reads as degraded performance. Everything else stays green. Four states a customer can read at a glance: the colour tells them how bad, the label tells them who's affected.
| Incident severity (internal) | Public component status | What the customer sees |
|---|---|---|
| Critical | Major Outage | Major Outage |
| Major | Partial Outage | Partial Outage |
| Minor | Degraded Performance | Degraded Performance |
| Informational | — | Stays operational |
Your URL. Your logo. Certificates you never touch.
Out of the box your status page lives at yourcompany.stayupfront.com. To put it on a domain you own — status.yourcompany.com, or whatever subdomain you pick — you point a CNAME at us and it's yours. Certificates for secure connections are provisioned and renewed automatically; you never touch them. That last part is the bit that scares small teams off doing this themselves, and it's the bit we don't make you think about.
Your logo renders across the page — square or landscape, light and dark variants. And per page, you choose what shows: the 90-day uptime history, the active incidents, the changelog. From your customer's point of view, it's a page on your product, not a page on ours.
Custom domain. status.yourcompany.com or any subdomain you own — point a CNAME at us. Certificates are handled for you.
Your logo, light and dark. Square or landscape variants, rendered to match the viewer's theme.
Per-page display toggles. Show or hide the uptime history, the active incidents, the changelog — per page, depending on what each one is for.
Same page. The one your customers bookmark is on the right.
A feed your customers can follow.
Every status page comes with a feed your customers can subscribe to in any reader — incidents and scheduled maintenance, as you post them. No account needed; it's just a URL they follow.
If a customer signs in to your portal, they get a feed that's personal to them: scoped to the components they actually care about, with their own URL they can regenerate any time, and a toggle for whether product changelog entries come through too. They decide what they want to hear about — you don't maintain a subscriber list by hand.
Email subscriptions are coming in the beta. For now, the feed is the shipped way to follow along.
Status feed
Public feed — anyone can follow
Your personalised feed
What you hear about
Schedule the maintenance once. You stay in control of the rest.
Planned work shouldn't read as an outage. Schedule a maintenance window — the components it affects, when it starts, when it ends — and it shows up on your status page ahead of time, so customers see it coming instead of wondering why something's flickering.
When the window opens, you can let it start on its own — or start it early if the work kicks off ahead of schedule. It completes on its own when the window closes, and you can wrap it up early the moment the work's done. You're not babysitting a timer, and you're not going back at 7am to start it and again at 9 to close it.
Database upgrade
Webhook delivery migration
Tell customers before, not after
Pick a window, name the components, write the message once. It publishes to your status page straight away — visible to customers before the first engineer touches a server.
Run to the work, not the clock
Work starting ahead of schedule? Start the window early. Finished sooner than planned? End it early. The window follows what's actually happening, not a time you guessed at last week.
Close it without the babysitting
The window completes on its own when its scheduled time runs out — and if the work finishes early, you can close it the moment you're done rather than waiting for the clock.
Mute alerts only if you want to
Suppressing alerts during a window is a toggle you control, per window. Leave it off and everything keeps paging as normal. Turn it on and only the components under maintenance go quiet.
Muting only touches what you're working on.
Schedule maintenance on your non-critical API and mute its alerts — fine. If your website goes down in the middle of that window, you still get paged. Suppression is scoped to the components under maintenance, so a planned job on one thing never hides a real outage on another.
That's the difference between sane alerting and accidentally muting everything during an incident.
One status page for everything, or one per product. Your call.
The building block is the component — the part of your product that can be up or down, the thing with the uptime bar. A status page is made of whichever components you choose to show on it.
So you can run one page that covers everything you sell, or a separate page per product — each with its own components, its own custom domain, its own logo, its own feed. Your team works in one internal workspace across all of it; each set of customers sees only the page that's theirs. One data model behind every page. One bill, one team, one context.
Webhook deliveries are failing
InvestigatingWebhook deliveries are failing for some endpoints. We've identified the cause and are rolling out a fix — we'll confirm here once deliveries recover.
Posted
Two products, two status pages, one internal workspace.
What a status page shouldn't make you do.
A few things we decided a status page should never ask of a small team.
It shouldn't be a separate copy-paste at 2am. If updating the status page is its own step, it's the step that gets skipped during the incident that matters. The page should move because the incident did.
It shouldn't need its own owner. Nobody on a small team has "status page" in their job title. It should keep itself current without a person assigned to remember it.
It shouldn't cost more than your support inbox. A page that shows your customers you're on it is table stakes, not a premium add-on. (We don't bill per seat — but that's the pricing page's story.)
The first time something broke on one of my clients' products, the "status update" was a message in a Slack channel and, eventually, a tweet that the people actually affected never saw. A status page isn't bureaucracy — it's the one place a worried customer can go to find out "is it just me, and are you on it?" and get a straight answer without emailing you. I wanted that to be one less thing to remember in the worst moment, so I built it to update itself off the incident you're already running.
— Rob Gough, Founder
Want a status page that updates itself? Get in early.
Private beta in a few weeks. I'm letting people in a small group at a time so I can actually work with each of you — what's working, what isn't, what to ship next. The earliest customers have the most say in what this becomes.
Drop your emailDirect email from Rob when your slot's ready. No drip sequence.