Status Pages

Create branded public status pages that show live service health, incidents, and maintenance — on your own domain.

Status Pages

Status pages let you communicate service health to your customers transparently — live overall state, a per-service breakdown, and a short history of recent incidents and maintenance. Each page is fully brandable and can run on your own domain (e.g. status.example.com).

Design & branding

8 layouts, color schemes, accent color, custom title, and toggles for what to show.

Custom domains

Serve a page on status.example.com with DNS verification and automatic HTTPS.

Status Pages API

Create, update, design, and manage domains programmatically.

::::

What a status page shows

  • Overall state — a single banner: Operational, Degraded, or Maintenance.
  • Services — the customer's monitored websites and service monitors, each with its own state.
  • Uptime statistics — optional per-service uptime percentages.
  • Recent history — optional list of recent incidents and maintenance windows.

How the public state is derived

Uptimeify computes each service's public state from two live signals — it never exposes raw check data:

ConditionPublic state
One or more open incidentsDegraded
Active maintenance window and no open incidentsMaintenance
NeitherOperational

The overall banner reflects the worst state across all services. See Incidents and Maintenance for how those signals are produced.

Create a status page

In the app, go to Dashboard → Status Pages → Create. A page always belongs to exactly one customer — it shows that customer's services.

SettingDescription
CustomerRequired. The customer whose services the page displays.
Public nameThe page title shown to visitors.
SlugUsed for the friendly URL. Auto-generated from the name; lowercase letters, numbers, and hyphens.
DescriptionOptional intro text shown under the title.
Visibilitypublic (anyone can view) or customer_members_only (login + access to the customer required).
PublishedToggle off to hide the page without deleting it.

You can do all of this via the API too.

URLs

Every status page is reachable at:

  • /status/<slug> — friendly URL based on the configured slug.
  • /status/<id> — stable URL based on the page ID (always available, even if the slug changes).

With a custom domain configured and active, the page is also served at the apex of that hostname, e.g. https://status.example.com/.

Visibility & publishing

  • public — the page is reachable by anyone with the link. Best for customer-facing status.
  • customer_members_only — visitors must be logged in and have access to the customer. Best for internal or NDA-bound services.
  • Published is independent of visibility: an unpublished page returns not found regardless of visibility, which is useful while you are still setting it up.

Recent history

The Recent History section is controlled by two independent toggles:

  • Show recent incidents
  • Show recent maintenance

These only affect the history list. Live indicators (such as a service currently being in maintenance) are always shown, independent of these flags. The design settings additionally control the history time window (historyDays).

Troubleshooting

"Status page not found"

  • Confirm the page is Published.
  • If visibility is customer_members_only, you must be logged in and have access to that customer.
  • Double-check the slug — it is normalized to lowercase-with-hyphens on save.

A service shows the wrong state

  • Stuck on Degraded? There is still an open incident for that service — resolve it or wait for automatic recovery (see Incidents).
  • Expected Maintenance but see Operational? Verify the maintenance window is active and the current time is within its start/end (see Maintenance).