Status Pages

Create public status pages to communicate service health to your users and stakeholders.

Status pages provide a single place where users, customers, and stakeholders can check whether your systems are operational without contacting support.

Why Status Pages Matter

Status pages serve as a communication bridge between your team and everyone who depends on your services.

Transparency with Customers

When something goes wrong, customers want to know. A status page gives them immediate answers without searching through social media or waiting on hold. This transparency builds confidence that you're aware of issues and actively working on them.

Reduce Support Tickets During Outages

Without a status page, every user who encounters an issue will contact support asking "is it just me?" With a status page, they can self-serve that answer. During major incidents, this can reduce support volume dramatically.

Build Trust

Publishing your uptime publicly demonstrates confidence in your service reliability. When customers see a track record of high availability, they trust that you take reliability seriously. Even when incidents occur, transparent communication builds more trust than silence.

Keep Stakeholders Informed

Status pages aren't just for external customers. Internal teams, partners, and executives can all benefit from a quick way to check service health without pinging the on-call engineer.

Configuration Options

When creating a status page, you can customize it to match your brand and control exactly what information is displayed.

Name and Slug

The name is the internal identifier for your status page, used in the Uptime dashboard to help you manage multiple status pages.

The slug determines the URL path where your status page is accessible. For example, a slug of platform would be available at /status/platform. Choose a slug that's short, memorable, and relevant to the audience.

Title and Description

The title appears at the top of your status page and should clearly identify what the page represents. For example, "Acme Platform Status" or "Developer API Status".

The description provides additional context below the title. Use it to explain what services are covered, link to additional resources, or provide contact information for urgent issues.

Paste the address of your company or product logo in Logo URL to brand the status page. A recognizable logo helps users confirm they're on the official status page and not a phishing attempt.

Public or Private Visibility

Public status pages are accessible to anyone with the URL. No authentication required. This is the default.

A page with Public turned off is not reachable by anyone, your team included: its address answers "Status Page Not Found". Use it to prepare a page before launch, or to take one offline without deleting it.

Overall Status Indicator

When Show Overall Status is on, the status page displays a banner at the top summarising every service on it:

  • All Systems Operational — Every service is operational

  • Partial System Outage — At least one service is down or degraded

  • Major System Outage — More than half of the services are down or degraded

Services that haven't been checked yet don't count toward the banner.

Select Monitors to Display

Choose the monitors that appear on the status page in Monitors to Include. HTTP, DNS, TCP and flow monitors share one list. Each selected monitor shows its name, its current status (Operational, Degraded or Down) and a 90-day uptime bar.

Not every monitor needs to be on your status page. Include only the services relevant to your status page's audience.

Select Cron Jobs to Display

Choose the cron jobs that appear on the status page in Cron Jobs to Include. They're listed under Scheduled Jobs with their current status, schedule and last ping.

This helps users understand whether background processes like data syncs or scheduled reports are running on schedule.

Maintenance Window Integration

A maintenance window with Show on status page enabled appears on every status page that shows a service it covers. A window for all monitors appears on every status page.

The page lists each window that is in progress or upcoming, with its name, its time in UTC and the services it affects, plus an "Add to calendar" link for that one window.

Every status page also publishes a maintenance calendar at /status/<slug>/maintenance.ics. Readers can subscribe from the page with their calendar app or Google Calendar, and their calendar follows along when you move a window, end it early or delete it.

The same calendar is published as JSCalendar JSON at /status/<slug>/maintenance.json, for tools that read JSON rather than iCalendar. Each format's response links to the other with a Link: <…>; rel="alternate" header.

This helps users distinguish between "something is broken" and "something is intentionally being worked on."

Best Practices

Only Show Customer-Facing Services

Your status page audience doesn't need to know about every internal service. Focus on:

  • Services customers directly interact with (website, API, mobile app)

  • Services that affect customer experience (payment processing, authentication)

  • Background services customers depend on (email delivery, notifications)

Skip internal tools, development environments, and infrastructure components that don't directly impact users.

Use Clear, Friendly Names

Customers don't know your internal service names. Translate technical names into user-friendly descriptions:

Internal NameStatus Page Name
api-gateway-prodAPI
auth-service-v2Login & Authentication
stripe-webhook-handlerPayment Processing
sendgrid-relayEmail Delivery

Add a Logo for Branding

A branded status page looks professional and helps users trust that they're viewing official information. Even a simple company logo makes a significant difference.

Keep Public for Transparency

Keep your status page public. The benefits of transparency outweigh the minor risk of competitors seeing your uptime metrics. Most successful companies proudly publish their status pages.

Create Separate Status Pages for Different Audiences

Consider creating multiple status pages for different use cases:

  • Customer status page — Public, shows services end-users interact with

  • Developer status page — Public, shows API endpoints, webhooks, and developer tools

  • Partner status page — Shows services specific partners depend on

This ensures each audience sees relevant information without noise from services they don't use.

Documentation