How to Build a Status Page Without Writing Any Code
To build a status page without code, describe the components you want listed, the states each one can be in, and where incident updates appear. An AI builder generates the page in about a minute and publishes it to an address separate from your product, which matters most when your product is the thing that is down.
A status page is a communication tool wearing a monitoring costume. Most of its value comes from the words you post during an incident, not from the coloured dots. This guide covers building one, updating it under pressure, and the point where a hosted service is the better answer.
What actually belongs on a status page?
Users arrive at a status page in one state of mind: something is broken and they want to know whether it is you or them. Four elements answer that, and everything else delays the answer.
- One overall state at the top. "All systems operational" or "Degraded performance," in words, above every other element. Most visitors read only this line.
- A component list. The parts of your product a user can tell apart: API, web app, dashboard, webhooks, email delivery. Not your internal service names.
- The current incident, with a timestamp. What is affected, what you know, and when you will next post. The next-update time does more to stop support tickets than the description does.
- A history. Past incidents with their resolutions. This is the page that buyers and security reviewers actually read, and an empty history reads as a page nobody maintains.
Resist adding uptime percentages unless you compute them honestly. A hand-written "99.98%" that nobody recalculates is a claim you will be held to during a procurement review.
What should the prompt say?
The builder needs your components, your state vocabulary, and the layout of an incident entry. Be specific about states, because a page with a dozen shades of yellow communicates nothing.
Build a status page for [product name].
Top: one big overall status banner with the current state
and the time of the last update.
Below: a component list: [API, Web app, Dashboard, Webhooks,
Email], each with a state pill: Operational, Degraded,
Partial outage, Major outage, Maintenance. Colour-code them.
Below: "Active incidents": each entry has a title, an
affected-components line, a severity, and a reverse-chronological
list of timestamped updates.
Below: "Incident history", grouped by month, collapsed by default.
Header: link back to [product URL] and a subscribe field.
Style: plain and fast, high contrast, no animation, minimal
assets, readable on a phone with a bad connection.
The last line is the one people skip and should not. A status page is opened precisely when things are going badly, sometimes on a train, sometimes by someone whose network is the actual problem. Every kilobyte you add makes it worse at its job.
Which approach fits your product?
Three routes exist and they are genuinely different products. The table names what each one gives you and what it takes.
| Approach | What you get | What it costs you |
|---|---|---|
| Hand-updated page | Full control of wording, your own domain, no monthly fee | You update it by hand during an incident, which is the worst possible time to be editing a website |
| Page reading from a database | Posting an update becomes adding a row, and a teammate can post without touching the site | Supabase setup and a small admin form, so a sequence of edits rather than one prompt |
| Hosted status service | Automated uptime checks, subscriber notifications, incident templates | A monthly fee and someone else's domain in front of your outage, unless you pay more |
The honest recommendation: if you have paying customers with an SLA, look hard at the third row. Automated detection and subscriber email at scale is the product those companies sell, and rebuilding it is not a good use of an evening. If you are pre-revenue, or your users are internal, the first two rows are entirely reasonable and cost far less.
How do you post an incident update quickly?
Speed matters here more than anywhere else on your site. Two workable patterns, and the difference shows up at 3am.
Editing by description. In Zugo you write the change: "set the API component to Partial outage and add an incident titled Elevated API errors with an update timestamped 14:20 saying we are investigating." That is a 3 credit edit and it takes about a minute. Fine for a product with a handful of incidents a year, painful during a rolling outage where you post every fifteen minutes.
Reading incidents from a table. Connect Supabase, store incidents and updates as rows, and add a small internal form that writes to it. Now posting an update is typing into a form rather than editing a website, and anyone on the team can do it. The setup is covered in the guide to building an AI app with Supabase.
Whichever you use, write the first two updates in advance as templates. Nobody composes clear prose during an incident, and a prepared sentence with the blanks filled in is worth more than an eloquent one written forty minutes late.
Where should the status page be hosted?
This is the one architectural rule that matters, and it is easy to get wrong: a status page must not depend on the thing whose status it reports. If your app and your status page share a server, a database, or a deployment, the page goes dark exactly when it is needed.
A project published on Zugo runs on separate infrastructure from your product, which satisfies the rule by default. If you connect a custom domain, use a subdomain like status.yourproduct.com and be aware that its DNS should not depend on anything your application manages.
Two related notes. Keep the page free of calls into your own API, however tempting live checks look, because a broken API then breaks the page. And put the status link in your product footer and your support autoresponder, since a page nobody can find during an outage is a page nobody reads.
What does it cost, and how do people hear about incidents?
A status page is a single-page build at 6 credits, and each update is a 3 credit edit. The free tier gives 5 starter credits, Pro is $25 per month with 200 credits, and Business is $99 per month. The page is deliberately simple, so Hi-Fi mode is rarely worth the doubled cost here.
Notification is the harder half. A subscribe field on the page can send through Resend, which covers a modest list well. Large subscriber bases with per-component subscriptions and delivery guarantees are what hosted services charge for, and that is a fair thing to pay for once you have thousands of customers.
Every build is booted in a sandbox before it reaches you, and one that fails to render is reported as a failure rather than delivered as working. That lowers the risk of publishing a broken status page mid-incident, though it does not remove it, so open the live URL yourself after any edit made under pressure. The mechanics of that check are described in how verified builds work.
When is a hosted status service the better choice?
Honest limits, because this category has a clear line and pretending otherwise costs someone a bad night.
Automated uptime detection. A built page shows what you tell it to show. It does not probe your endpoints, notice a regional failure, or flip a component to degraded on its own. That is monitoring, and it is a different tool.
Notifications at scale. Thousands of subscribers, per-component preferences, SMS and webhook delivery, and retry logic. Real infrastructure, not a form.
Contractual uptime reporting. If an SLA credit depends on the numbers, they need to come from measured data with an audit trail, not from a page someone edits.
Multi-region and multi-status-of-status complexity. Large platforms end up with dependency maps and per-region components, and that is a product in itself.
What a built page does very well is the small case: a product with a handful of components, an honest owner, and users who deserve a sentence when something breaks. If that is you, the page can be live tonight, on your own domain, with a history that grows into the thing security reviewers ask for. A neighbouring page worth building at the same time is a product changelog, which answers "what changed" while this one answers "what is broken." You can start at zugo.dev.