Short answer
A status page is a web page that shows the current operational state of a service, its components and any ongoing incidents or scheduled maintenance. It gives customers one trustworthy place to check during an outage, which reduces support tickets and builds trust. A good status page lists components users recognize, updates automatically from monitoring, and carries short, timestamped incident updates.
A status page is a dedicated page that communicates whether your service is working, which parts are affected when it is not, and what you are doing about it. It is usually hosted separately from the main application, often at an address like status.example.com, so it stays reachable when the product itself is down.
Why have a status page
- Fewer support tickets. During an outage, users who can see that you know about the problem are less likely to email or open a ticket.
- Trust through transparency. Visible, honest incident history signals that you take reliability seriously.
- One source of truth. Support, sales and engineering all point customers to the same page instead of writing separate replies.
- Proactive notification. Subscribers get incident and maintenance updates by email without having to check.
- Accountability. Published uptime history shows whether you meet the targets you promise.
What to include
| Element | Purpose | Tip |
|---|---|---|
| Overall status banner | Answers "is it down?" in one glance | Use plain words: Operational, Degraded, Outage |
| Components | Shows which parts are affected | Name them as users know them: Website, API, Dashboard, Email delivery |
| Uptime history | Shows track record over recent weeks or months | Per component, based on real monitoring data |
| Active incidents | Timestamped updates during an outage | Update on a predictable cadence |
| Scheduled maintenance | Warns users before planned work | Post well in advance with start time and time zone |
| Incident history | Past incidents and their resolution | Keep it; deleting history erodes trust |
| Subscribe option | Email notifications for updates | Double opt-in and easy unsubscribe |
Automatic vs manual status
The most reliable status pages combine automatic monitoring with human-written updates. Linking components to uptime monitors means the page reflects reality within a minute or two, even if nobody on the team is awake yet. Human updates then add context that a monitor cannot: what users will experience, what is being done, and when the next update will come. A page that only changes when someone remembers to update it tends to show "All systems operational" during real outages, which does more harm than having no page.
Public vs private status pages
- Public pages are open to anyone and suit customer-facing SaaS, ecommerce and APIs.
- Private pages require a password or login and suit internal tools, enterprise customers with dedicated infrastructure, or agencies sharing status with a single client.
Many organizations run both: a public page for the product and a private one for internal systems.
Custom domains
Hosting your status page on your own subdomain, such as status.example.com, looks more professional and is easier for customers to remember. The usual setup is a DNS record that points the subdomain at the status page provider, plus an ownership verification record. Use a subdomain rather than a path on your main site, so the page does not go down with the application, and consider keeping it on separate infrastructure from your main DNS and hosting.
Status pages in Uptime Tracker
Each Uptime Tracker status page is hosted at uptimetracker.live/status/your-slug, with components mapped to monitors, current state, uptime history and plain-text incident updates. The page refreshes every minute. Visitors can subscribe by email with double opt-in and one-click unsubscribe. Starter and Team plans support custom domains (you add a TXT record for ownership and a CNAME; the HTTPS certificate is issued automatically), and Team adds private, password-protected pages. Plans include 1, 3 or 10 status pages. Details are on the status pages feature page.
How to write incident updates
Good incident updates are short, specific, timestamped and say when the next update will come. Follow these rules:
- Post fast. Acknowledge the problem as soon as it is confirmed, even before you know the cause.
- Describe user impact, not internals. "Some customers cannot log in" is better than "auth-svc pod crashlooping".
- Be specific about scope. Which component, which region or plan, which actions fail.
- Commit to the next update. "Next update in 30 minutes" and then keep that promise.
- Avoid speculation and blame. Do not name vendors or guess at causes until confirmed.
- Close the loop. Mark the incident resolved and summarize what happened.
Quick templates
Copy and adapt these four stages. A fuller set, plus a postmortem outline, is in incident communication templates.
Investigating: We are investigating reports that [component] is [symptom] for [scope]. We will post an update within [30 minutes].
Identified: We have identified the cause of [symptom] affecting [component] and are working on a fix. Next update within [30 minutes].
Monitoring: A fix has been applied and [component] is recovering. We are monitoring to confirm full recovery.
Resolved: This incident is resolved. Between [start time] and [end time, time zone], [component] was [impact]. [One sentence on cause and prevention.]
When to post an incident
Post an incident whenever a meaningful share of users is affected or likely to notice, even if the cause is unknown. A practical threshold is any outage or serious slowdown of a customer-facing component lasting more than a few minutes, any data-related issue, and any problem your support team is already receiving tickets about. Minor internal issues that users cannot see do not need a public incident. If in doubt, post: a short "we are investigating" message that turns out to be minor costs little, while silence during an outage users can see costs trust. Decide these thresholds in advance and write them into your runbook, so the person on call does not have to make the judgment alone.
Common status page mistakes
- Hosting the status page on the same server or domain as the product.
- Listing internal service names that customers do not recognize.
- Only updating manually, so the page lags behind reality.
- Going silent for hours during a long incident.
- Removing past incidents to make the history look better.
Frequently asked questions
What is the purpose of a status page?
A status page tells users whether a service is working, which components are affected during a problem, and what the team is doing about it. It reduces support tickets during outages, builds trust through transparency, and lets users subscribe to incident and maintenance updates.
What should a status page include?
An overall status indicator, a list of components users recognize, uptime history, active incidents with timestamped updates, scheduled maintenance, past incident history, and a way to subscribe to updates by email.
Should a status page be on a separate domain?
It should at least be on a separate subdomain, such as status.example.com, and ideally hosted on infrastructure independent of your main application, so it stays online when your product is down.
How often should I update a status page during an incident?
Post the first update as soon as the problem is confirmed, then update at a predictable cadence, commonly every 30 to 60 minutes, even if there is no new information. Always state when the next update will come.
What is the difference between a public and a private status page?
A public status page can be viewed by anyone and suits customer-facing services. A private status page is protected by a password or login and suits internal systems or individual clients. In Uptime Tracker, password-protected private pages are part of the Team plan.
