50% bonus credits + 2x signup credits View Offer
10 min read

How do I set up a status page for my SaaS?

Create a professional, branded status page for your SaaS product that updates automatically.

A public status page builds trust with your users. When something goes wrong, they can check your status page instead of flooding your support inbox - and when everything is running, the uptime history gives them confidence in your reliability. This guide walks through creating a production-ready status page for a SaaS product.

Step 1: Identify What to Monitor

Before creating the status page, decide which services to surface publicly. A good rule of thumb:

Show publicly:

  • User-facing API (the endpoint your customers actually call)
  • Web application / dashboard
  • Authentication service
  • Any integrations customers depend on (e.g., webhooks, email delivery)

Keep internal:

  • Database servers (customers don’t interact with these directly)
  • Internal admin tools
  • CI/CD pipelines
  • Infrastructure components (load balancers, caches)

Showing too many components creates noise. Start with 3–6 components that map to things your customers would notice if they stopped working.

Step 2: Create Monitors for Each Service

For each service you plan to show publicly, create a monitor in UpCanary. Go to New Monitor and configure:

API endpoint

  • Type: HTTP / HTTPS
  • URL: https://api.yourapp.com/health
  • Method: GET
  • Assert: status 200, body contains ok
  • Interval: 1 minute
  • Regions: all

Web application

  • Type: HTTP / HTTPS
  • URL: https://app.yourapp.com
  • Method: GET
  • Assert: status 200
  • Interval: 5 minutes
  • Regions: all

Database connectivity (test via an app-layer health route, not direct DB access)

  • Type: HTTP / HTTPS
  • URL: https://api.yourapp.com/health/db
  • Assert: status 200, body contains connected
  • Interval: 2 minutes

Give each monitor a clear internal name - you will map these to user-facing component names on the status page.

Step 3: Create the Status Page

  1. Click Status Pages in the sidebar, then New Status Page.
  2. Set the name - for example, “Acme Status” or “YourProduct Status”.
  3. Set visibility to Public.
  4. Choose a slug - this becomes part of your status page URL. Use something short and recognizable like acme or yourproduct.

Step 4: Add Components and Groups

Components are the items that appear on your status page. Each component is backed by one of your monitors.

Add individual components:

  1. Under Components, click Add Component.
  2. Select the monitor from the dropdown.
  3. Give it a user-friendly display name - for example, “API” instead of “api-prod-health-check”.
  4. Click Add.

Organize with groups:

Groups let you cluster related components under a shared heading. This is useful when you have more than 4–5 components.

Example grouping:

  • Core Services: API, Web App, Authentication
  • Integrations: Email Delivery, Webhooks, Payment Processing

To create a group, click Add Group, name it, then drag components into it.

Step 5: Customize the Theme

Under the Customize tab on your status page:

  • Set your brand color - used for the status banner and component accents
  • Upload a logo to replace the UpCanary logo
  • Adjust the page title and description shown to visitors

Keep the design simple. Visitors come to your status page when something is wrong - clarity matters more than aesthetics.

Step 6: Publish and Share

Click Publish. Your status page is now live at its unique URL.

Share it with your users:

  • Add a “System Status” link to your website footer
  • Include the URL in your onboarding emails
  • Pin it in your customer Slack or Discord
  • Link it from your app’s help menu or error pages
  • Add it to your support documentation

When a monitor detects downtime, the affected component automatically shows “Degraded” or “Down” on the status page - no manual action required.

Tips

  • Do not show components that are almost never down. A status page full of green badges for rarely-tested internal services adds no value and dilutes trust when something actually fails.
  • Use real names your customers will recognize. “API” and “Dashboard” are clearer than “prod-api-us-east-1-lb” and “webapp-k8s-cluster”.
  • Test the failure flow before launch. Temporarily pause a monitor and verify the status page reflects the change before you share the URL with customers.
  • Consider a private page for internal ops. Create a second, private status page that includes all of your infrastructure components - databases, queues, caches - so your team has full visibility without exposing internal details to the public.