How to Set Up a Free Public Status Page for Your SaaS

The moment you need a status page and do not have one

It is 2pm on a Tuesday. Your API goes down. Within five minutes, your support inbox has 47 emails all asking the same question: "Is the service down?"

Your team stops working on the fix to answer support tickets. Your social media fills with complaints. Customers who cannot reach your support channels assume the worst and start evaluating competitors. The outage lasts 20 minutes. The support backlog lasts three hours.

Now imagine the same scenario with a status page. Your monitoring detects the outage. The status page updates automatically. Customers visit status.yourdomain.com, see the incident, and know you are aware of it. Your team focuses entirely on fixing the problem. Support tickets drop by 80%. The outage lasts 20 minutes. The cleanup lasts 20 minutes.

That is the difference a status page makes. It is not a nice-to-have. For any SaaS product with paying customers, it is infrastructure.

What a status page actually is

A public status page is a dedicated webpage that shows the real-time operational status of your service. It has three jobs:

1. Show current status — is each component of your service operational, degraded, or down?
2. Communicate during incidents — what happened, what is being done, and when it will be resolved?
3. Show historical reliability — what is your uptime track record over the last 30, 60, or 90 days?

Companies like GitHub, Stripe, and Slack all maintain public status pages. It has become the standard that customers expect from any SaaS product they rely on.

Why your SaaS needs one — even if you are small

It reduces support tickets dramatically

During an outage, the majority of support tickets are not asking for help — they are asking "is it down?" A status page answers that question before the customer ever contacts you. According to Atlassian's incident management handbook, status pages can reduce incident-related support volume by up to 80%.

For a small team where founders handle support, this is the difference between fixing the problem and drowning in "is it down?" messages while the problem gets worse.

It builds trust through transparency

Every service has downtime. The companies that earn trust are the ones that communicate openly about it. A status page says: "We take reliability seriously. We monitor our service. We are transparent when things go wrong."

Hiding outages erodes trust. Customers know when something is not working. If they check your site, see the problem, and then visit your Twitter where you have said nothing — they assume you either do not know or do not care. Neither is good.

Enterprise customers require it

If you sell to businesses — especially mid-market or enterprise — their procurement and security teams will look for a status page. It is part of vendor due diligence. They want to see your uptime history, how you handle incidents, and whether you have monitoring in place.

Not having a status page does not just look unprofessional — it can disqualify you from enterprise deals. Having one, even a simple one, demonstrates operational maturity.

It is better than Twitter for incident communication

Many SaaS companies use Twitter to communicate during outages. The problem: not all your customers follow you on Twitter. Twitter's algorithm may not show your tweet. And mixing incident updates with marketing tweets is messy.

A status page is a dedicated, predictable location your customers can always check. You can link to it from your docs, your app, your error pages, and your email signatures. It becomes the single source of truth during incidents.

What to include on your status page

Individual component status

Do not just show one green or red light for your entire service. Break it into components that your customers care about. For a typical SaaS, this might be:

• API — your core service endpoint
• Dashboard — the web application
• Authentication — login and signup
• Webhooks — outbound event delivery
• Email notifications — transactional emails

This way, if your email notifications are delayed but your API is running fine, customers can see exactly what is affected. It prevents a minor issue from looking like a total outage.

Uptime history bars

Show a visual bar for each component showing uptime over the last 90 days. Each day is a bar segment — green for fully operational, yellow for degraded, red for outage. This gives customers and prospects an instant view of your reliability track record.

Current incident details

During an active incident, show: what is affected, when it started, what you are doing about it, and estimated time to resolution. Update this regularly — even if the update is "we are still investigating." Silence during an outage is worse than admitting you have not found the cause yet.

Incident history

Keep a log of past incidents with start time, end time, what happened, and what you did to fix it. This serves two purposes: it shows customers you are transparent, and it helps your own team learn from past failures.

Subscribe functionality

Let visitors subscribe to status updates via email. When an incident occurs, subscribed users get notified automatically. This is the proactive alternative to customers discovering outages on their own and contacting support.

How to set up a free status page with Uptrue

Uptrue includes public status pages on the free plan. The status page connects directly to your monitors — when a monitor detects a failure, the status page updates automatically. No manual intervention required.

Step 1: Set up your monitors

Before creating the status page, add monitors for each component of your service. For a typical SaaS:

1. HTTP monitor for your API endpoint — checks response code and response time
2. HTTP monitor for your dashboard/web app — checks it loads correctly
3. Keyword monitor for your login page — verifies the login form renders properly
4. SSL monitor for your domain — catches certificate issues before they affect users

Each monitor becomes a component on your status page. Read our uptime monitoring guide if you are new to setting up monitors.

Step 2: Create the status page

1. Go to Status Pages in your Uptrue dashboard
2. Click Create Status Page
3. Name your status page — use your product name
4. Select which monitors to display as components
5. Choose a slug — this becomes uptrue.io/status/your-slug
6. Optionally set a custom domain — status.yourdomain.com

Step 3: Add a CNAME for your custom domain (optional)

If you want to use status.yourdomain.com, add a CNAME record in your DNS that points to the status page URL. This keeps the branding consistent — your customers see your domain, not a third-party service.

Step 4: Link to it everywhere

Your status page only works if customers can find it. Add links to it in:

• Your application footer
• Your documentation
• Your error pages (especially 500 and 503 pages)
• Your support email template
• Your email signatures
• Your onboarding emails

The goal is that when a customer experiences an issue, the status page is the first thing they think to check — not your support inbox.

How to communicate during incidents

Having a status page is step one. Using it well during incidents is what actually builds trust. Here are the rules.

Acknowledge fast

The moment your monitoring detects an issue, acknowledge it on the status page. Even if you do not know the cause yet, post: "We are investigating reports of [issue]. We will update this page as we learn more." Fast acknowledgement tells customers you are on it.

Update regularly

Post an update every 15 to 30 minutes during an active incident, even if nothing has changed. "We are still investigating. No further information at this time." is better than silence. Silence makes customers assume you have abandoned the problem.

Be specific about what is affected

"We are experiencing issues" is useless. "The API is returning 503 errors for approximately 30% of requests. The dashboard and authentication are unaffected." is useful. Specificity reduces panic.

Post a resolution summary

When the incident is resolved, post what happened, what caused it, how it was fixed, and what you are doing to prevent it from happening again. This is the post-mortem summary. It builds enormous trust because it shows accountability and continuous improvement.

The cost of not having a status page

Dedicated status page services like Statuspage (by Atlassian) cost $29 to $399 per month. For early-stage SaaS companies watching every pound, that feels hard to justify.

But the cost of not having one is higher. Every outage without a status page means:

• Dozens of support tickets that distract from fixing the problem
• Customer frustration from lack of communication
• Potential churn from customers who assume you are unreliable
• Lost enterprise deals from prospects who check for operational maturity

Uptrue includes public status pages on the free plan because we believe every SaaS — from day one — should have one. Monitor your service and communicate transparently without spending a penny.

Your customers already expect this

In 2026, a public status page is as expected as HTTPS. Your customers use Slack, GitHub, Stripe, AWS — all of which have status pages. When your service has an issue, they instinctively look for status.yourdomain.com. If it is not there, they assume you are not monitoring your own service.

Set it up once. It takes five minutes. It runs forever. And the first time your service has an outage and your support inbox stays quiet because customers checked the status page instead — you will wonder why you did not do it sooner.

Frequently asked questions