How to Set Up a Status Page in 5 Minutes

When your service goes down, your customers do one of two things: they check your status page, or they email support. A good status page handles the first group and dramatically reduces the second.

Setting one up does not need to be complicated. Here is everything you need to know.

What a Status Page Actually Needs

Strip away the marketing pages and feature lists, and a useful status page has exactly four things:

Components with current status — a list of your services and whether each one is operational, degraded, or experiencing an outage
An incident timeline — when something breaks, a chronological list of updates showing what happened, what you are doing about it, and when you expect it to be resolved
Historical uptime — a visual record (usually 30 or 90 days) showing your track record, so customers can judge reliability at a glance
Subscriber notifications — a way for customers to get email (or webhook) alerts when something changes, instead of refreshing the page every 30 seconds

If your status page has these four elements, it is doing its job. Everything else is nice-to-have.

Step 1: Choose Your Components

Components are the building blocks of your status page. They represent the services your customers interact with. The most common mistake is listing too many or too few.

Too few means a single "Application" component that is either green or red. This tells customers nothing useful. If your API is fine but email delivery is delayed, they cannot tell.

Too many means listing internal services your customers do not care about. Nobody needs to see "Redis Cluster 3" or "Worker Queue B" on a public status page.

The right approach: list what your customers would ask about in a support ticket. If a customer would write "I cannot log in," you need an Authentication component. If they would write "my emails are not arriving," you need an Email Delivery component.

A typical SaaS status page has 4-8 components:

Web Application
API
Authentication
Dashboard
Email Delivery
Webhooks
Documentation / Knowledge Base

Group related components together if your tool supports it. For example, "Core Platform" might contain Web Application, API, and Authentication.

Step 2: Connect Your Monitors

A status page without monitoring is a manual dashboard that someone has to remember to update at 3 AM. That update will be late, or it will not happen at all.

Connect monitors to each component so that status changes happen automatically:

HTTP monitors for web endpoints and APIs — check that the response returns a 200 status code and the response time is reasonable
TCP monitors for databases, mail servers, and other services that do not speak HTTP
Ping monitors for basic reachability checks

Set your check interval to something sensible. Every 60 seconds is standard for most SaaS products. Every 30 seconds if you have strict SLA commitments.

When a monitor detects a failure, the corresponding component should automatically move to "Major Outage" on your status page. When it recovers, it should move back to "Operational." No human intervention needed for the initial detection.

Step 3: Set Up Incident Communication

Automatic status changes handle detection, but incident communication still needs a human touch. When something breaks, your customers want to know three things:

What is affected — "Our API is returning 500 errors for approximately 30% of requests"
What you are doing about it — "We have identified the issue as a database connection pool exhaustion and are deploying a fix"
When you expect it to be resolved — "We expect full recovery within the next 30 minutes"

A good incident follows a lifecycle:

Investigating — you are aware of the issue and looking into it
Identified — you know the cause and are working on a fix
Monitoring — the fix is deployed and you are watching to confirm it holds
Resolved — the incident is over

Each stage should have a brief, honest update. You do not need to write a novel. Two sentences per update is enough. The key is frequency — an update every 15-30 minutes tells customers you are actively working on it, even if there is no new information.

For more detail on writing good updates, see our guide on how to write a useful incident update.

Step 4: Enable Subscriber Notifications

The entire point of a status page is to reduce "is the site down?" messages. Subscriber notifications close the loop.

When a customer subscribes to your status page, they get an email whenever:

A new incident is created
An incident is updated
An incident is resolved
You schedule maintenance

This means your most engaged customers — the ones who would otherwise flood your support inbox — get proactive updates without lifting a finger.

Make the subscribe option visible on your status page. Do not hide it behind a menu.

Step 5: Customise and Share

Your status page should look like it belongs to your brand:

Use your company name and logo
Pick a clean subdomain like status.yourcompany.com
Keep the design minimal — this is a utility page, not a marketing page

Once it is live, link to it from:

Your application's footer
Your documentation or help centre
Your support team's canned responses ("You can check real-time status at status.yourcompany.com")

Common Mistakes to Avoid

Not updating during incidents — a status page that says "Operational" during an obvious outage destroys trust faster than having no status page at all
Too much technical detail — your customers do not need to know which Kubernetes pod crashed. They need to know if the service works and when it will be fixed
Forgetting scheduled maintenance — use your status page to announce planned downtime in advance. Customers are far more forgiving when they have been warned
Running the status page on the same server — if your server goes down and your status page goes with it, it serves no purpose. Your status page must be hosted independently. We wrote more about this in why your status page cannot run on the same server

Get Started

If you want to skip the setup overhead, Upwarden lets you create a status page with connected monitoring in about two minutes. The free tier includes one monitor and one status page — enough to cover your most critical endpoint and see how it works before expanding.

But regardless of which tool you use, the principles above apply. Choose your components carefully, connect real monitors, communicate honestly during incidents, and let customers subscribe for updates. That is all a status page needs to do.