How to Create a Public Status Page for Your Website or API

When your website or API goes down, your users notice. Without a status page, they flood your support inbox asking "is your service down?" — adding to your workload precisely when you're busiest trying to fix the problem.

A public status page gives users a single place to check the live status of your service, see historical uptime data, and follow incident updates. It reduces support volume, builds transparency, and demonstrates professionalism.

This guide explains what a status page should include, how to create one, and how to make it most effective.

What Is a Status Page?

A status page is a publicly accessible webpage — typically at a URL like status.yourdomain.com — that displays the current operational status of your services. It typically shows:

• Current status — whether each service component is operational, degraded, or down
• Uptime history — a visual history of uptime over the past 30-90 days
• Active incidents — description and updates for any current outage or performance issue
• Past incidents — a log of historical incidents with resolution details

Well-known examples include status.github.com and status.slack.com — both of which are visited by millions of users during incidents.

Why Every Service Should Have a Status Page

Reduces Support Load

When users can check your status page themselves, a significant portion won't raise a support ticket. For a service with 10,000 users, a 30-minute outage without a status page might generate 50+ support tickets. With a status page that shows "we're aware and working on it," many users will wait rather than contact support.

Builds Trust Through Transparency

Acknowledging an outage publicly — rather than hoping users don't notice — builds credibility. Users understand that outages happen. What they don't forgive is finding out from Twitter that your service was down while your own status page said "all systems operational."

Manages User Expectations

An active incident post with regular updates ("investigating → identified → fixing → resolved") keeps users informed and reduces uncertainty. Users who know what's happening are more patient than users who have no information.

Professional Signal

A status page at a custom domain signals operational maturity. For SaaS products, it's increasingly expected by enterprise customers who want to know you take reliability seriously.

What to Include on Your Status Page

Service Components

Break your service into the components users care about:

• API — is the API responding?
• Web Application — is the main app accessible?
• Dashboard — is the user dashboard loading?
• Authentication — can users log in?
• Notifications / Emails — are system emails being sent?
• Third-party integrations — are key integrations operational?

Not every internal component needs to be public. Focus on the components users interact with directly.

Uptime History Visualization

A 90-day uptime bar (similar to GitHub Status) gives users a visual sense of your reliability track record. Green bars for days with no incidents, yellow for degraded days, red for significant outages.

Incident Posts

During an outage:

1. Post an incident immediately with status "Investigating"
2. Update with status "Identified" when you know the cause
3. Update with "Monitoring" when the fix is deployed
4. Mark "Resolved" with a brief post-mortem when it's over

The cadence matters. Update your status page at least every 30 minutes during an active incident, even if there's nothing new to report. "Still investigating, no updates" is better than silence.

How to Create a Status Page

Option 1: Use Your Monitoring Tool's Built-in Status Page

The simplest approach. Many monitoring tools — including Domain Monitor — generate a public status page directly from your monitor data. Your uptime checks automatically populate the status page with real-time data and uptime history.

This is the fastest setup and ensures your status page reflects actual monitor data rather than manually updated statuses.

See introducing public status pages for how Domain Monitor handles this.

Option 2: Third-Party Status Page Services

Dedicated status page services like Statuspage.io (now part of Atlassian), Freshstatus, or Instatus offer more customisation options but require separate setup and often have higher costs.

Best for: large teams needing advanced incident management and subscriber notification features.

Option 3: Self-Hosted

Open-source options like Cachet or Upptime (GitHub-hosted) let you self-host a status page. This gives maximum control but requires ongoing maintenance.

Best for: teams with strong DevOps capabilities who want full control.

Custom Domain Setup

A status page at status.yourdomain.com looks more professional than yourmonitor.com/status/yoursite. Most monitoring tools support custom domains via a CNAME record.

To set this up:

1. Add a CNAME record in your DNS: status CNAME yourmonitor-status-page-url
2. Configure the custom domain in your monitoring tool settings
3. Wait for DNS propagation (usually 5-30 minutes)

Importantly: use a different hosting provider for your status page than for your main site. If your main hosting goes down, your status page needs to still be accessible.

Hosting Your Status Page Independently

If your status page lives on the same server as your application, it goes down when your application goes down — which is exactly when users need it most. Best practice:

• Host on a CDN — static status pages served from Cloudflare, Netlify, or similar are extremely reliable
• Use a separate cloud provider — if your app is on AWS, host the status page on Cloudflare or Vercel
• Let your monitoring tool host it — monitoring tools are specifically designed to stay up during customer incidents

Status Page SEO Considerations

Your status page doesn't need to rank for search queries, but you should ensure:

• It's not accidentally indexed as duplicate content
• It has a noindex meta tag if you don't want it in search results
• It doesn't share the same domain/IP as services that might go down

Communicating During an Incident

Good incident communication follows a pattern:

Phase	Status	Message
Discovery	Investigating	"We are investigating reports of degraded performance on the API."
Diagnosis	Identified	"We have identified the cause as a database connection pool exhaustion issue."
Remediation	Fixing	"We have deployed a fix and are monitoring recovery."
Resolution	Resolved	"The issue has been resolved. Root cause was X, fix was Y."

Avoid vague language like "we're experiencing some issues." Be specific about what's affected, what's not affected, and when you expect resolution.

Getting Started

A basic status page powered by your monitoring tool can be set up in minutes. Domain Monitor includes public status pages for all plans, automatically showing real-time data from your uptime monitors.

---

Create a public status page for your service at Domain Monitor.

Related Articles

• "Statuspage Alternatives: Comparing Status Page Tools"
• "How to Write a Post-Incident Report After Website Downtime"
• "Incident Response Plan for Website Downtime: A Template"