Guides / How to build

How to Build a Status Page: Components, Incidents and Uptime Checks

How to build a status page: components, incidents and updates, hosting it so it stays up during an outage, uptime checks, subscriber alerts, hosted options.

Mythex Team · 2026-09-29 · 6 min read

A status page tells your users, in one place, whether your service is working. To build one you need a list of components (website, API, payments, email), a current status for each, incidents with timestamped updates, a history of past incidents, and optionally subscriptions so people hear about problems without checking. The page itself is simple. The important decision is where it runs: a status page must stay up when your app is down, so it should not share hosting, database or deploy pipeline with the thing it reports on.

What a status page is for

When something breaks, users want to know three things: is it just me, are you aware, and when will it be fixed. A status page answers all three without a flood of support tickets. It also builds trust over time, because a visible incident history with honest write-ups shows how you handle problems.

It is not a changelog. New features go on a changelog page; outages and maintenance go here.

What the page needs

Data

Component statuses are usually a short fixed list: Operational, Degraded performance, Partial outage, Major outage, Under maintenance.

Pages

• Public status page: an overall banner ("All systems operational" or the worst current status), each component with its status, any active incident with its updates, upcoming maintenance, and a 90-day history strip if you have check data.
• Incident page: full timeline of updates for one incident, with its own URL so support can link to it.
• History: past incidents by month.
• Subscribe: email sign-up with confirmation and per-component preferences.
• Admin: create an incident, post updates, change component statuses, schedule maintenance.

Permissions

The public sees everything published. Only your team can post. Keep the admin login separate from your main app's login system if you can, so an outage of your auth provider does not lock you out of your own status page.

The key decision: keep it independent

This is where most home-made status pages fail. If your status page:

• runs on the same server or hosting account as your app,
• reads from the same database,
• sits behind the same domain setup or CDN configuration,
• or is deployed by the same pipeline,

then many outages will take it down too, exactly when people need it. Practical steps:

• Separate hosting. A different project or provider from the main app.
• Its own subdomain, like status.example.com, pointed separately in DNS. See how domains and DNS work.
• Its own data. Incidents live in the status page's own storage, not your app database.
• A static fallback. Some teams make the public page static and rebuild it on each update, so there is almost nothing to break.

Manual updates or automated checks

Manual (start here)

Your team posts incidents and changes component statuses by hand from the admin page. This is how many status pages work in practice, because a human judgement ("payments are slow for some card types") is more useful than an automated red dot.

To find out about problems quickly, use an external uptime monitor that checks your app every minute or so and alerts you by email, SMS or chat. Many monitoring services have free tiers.

Automated

Automation means something regularly checks each component and updates its status. That needs code that runs on a schedule, from outside your main app's infrastructure. Two common patterns:

• An external monitor calls your status page through a webhook when a check fails or recovers, and the status page updates the component.
• A scheduled job in the status page's own hosting pings each component and records the result. Check how your hosting handles scheduled tasks before relying on this; our guide on running background jobs explains the options.

Automated changes can flap (up, down, up) on a slow network. Require two or three failed checks before changing a status, and let a human confirm before a major outage is announced.

Writing incident updates

• Post early. "We are investigating reports of failed logins" within minutes beats a perfect message an hour later.
• Say what users notice, not what broke internally.
• Promise the next update time, and keep it.
• Close with a short summary once resolved: what happened, how long, what you are changing.

A first prompt that works

Build a standalone status page for our app Parcelio, to be hosted separately at status.parcelio.com. Components: Website, Tracking API, Notifications, Payments, each with status Operational, Degraded performance, Partial outage, Major outage or Under maintenance. The public page shows an overall banner using the worst current status, each component with its status, any active incidents with timestamped updates newest first, upcoming maintenance, and a list of past incidents by month. Each incident has its own page. Add a password-protected admin page to create incidents (title, impact, affected components), post updates (message and status: Investigating, Identified, Monitoring, Resolved), change component statuses and schedule maintenance. Add a POST /api/check-result endpoint that accepts a component name and up/down from an external monitor, protected by a secret token, and marks a component Degraded only after three consecutive downs. Store everything in this app's own database. Simple, calm design that loads fast on phones.

Build steps

1. Public page and admin with manual incidents. This alone is a working status page.
2. Host it separately and point a subdomain at it.
3. Incident pages and history.
4. Maintenance windows.
5. Subscriptions. Double opt-in email sign-up and notifications on new incidents and updates. Email needs a provider; see how to send emails from your app.
6. Monitor webhook if you want automated status changes.
7. Run a drill. Create a fake incident, post updates, resolve it, check the emails, then delete it.

Common mistakes

• Hosting it with the app. The most common and most serious mistake.
• A page that always says "All systems operational". If it never shows problems, users stop trusting it.
• No timestamps or time zone. Always show times with the zone.
• Relying on your main app's login for the admin page.
• Silence between updates. "No change, still working on it" is a valid update.
• Flapping automated statuses. Require repeated failures before a change.

When a hosted status page service is the better choice

Hosted status page services are built around the independence problem: they run on separate infrastructure, handle subscriber notifications by email and SMS, and often include monitoring and integrations with incident tools. If uptime is part of what customers pay for, or you have contractual obligations to report incidents, a dedicated service is usually worth it. Many have free or low-cost tiers for small teams, so check before building.

Build your own when you want full control of design and wording, when your needs are simple (a handful of components, manual updates), or when a status page is part of a product you are building for others.

Building it with Mythex

On Mythex you can build the status page as its own project, separate from your main app, which gives it separate hosting and its own database. Describe it in chat, check it in the live preview, then publish it and connect a subdomain like status.yourdomain.com (custom domains are on Pro). Keep in mind that published Mythex apps and their databases sleep when idle and wake on the next visit, so the first load after a quiet spell can be slower; a simple, light page helps.

Mythex does not document scheduled jobs, so for automated checks use an external uptime monitor that calls a webhook endpoint in your status page (see the webhooks recipe). Email alerts to subscribers go through your own provider, with the key stored as a project secret (send email recipe).