Build a Status Page From Uptime Data (2026 Tutorial)

The page fired at 2:47am. Primary database, connection timeout. I was three dashboards deep — Datadog for traces, Pingdom for uptime history, our internal wiki for the runbook — when the first customer tweet hit. "Is @yourproduct down? Getting 500s."

By the time I'd confirmed the incident, drafted a tweet, and posted it, six more customers had asked. Our status page? It was Statuspage.io, technically functional, but it required me to manually create an incident, manually update it, and manually resolve it. At 3am, "manually" means "probably won't happen until morning."

That's backward. The uptime check already knew the API was down. The incident timeline already existed in our monitoring stack. Why was I copy-pasting between tools? The whole situation made me unreasonably angry. If you're still running separate tools for each telemetry type, our guide to replacing GA4, Sentry, Pingdom, and LogRocket explains the consolidation approach.

This post walks through building a public status page that actually pulls from your uptime data and incident history — no separate vendor, no manual incident creation, no extra bill. By the end, you'll have a working status page at status.yourcompany.com that auto-updates from your existing monitoring.

What You'll Have at the End

A public status page showing:

Real-time status of each service component (API, dashboard, webhooks, etc.)
Current incidents with live updates
Scheduled maintenance windows
90-day uptime history per component
Subscriber notifications via email or webhook

All populated automatically from the uptime checks and incidents you're already tracking. No third Statuspage bill.

Prerequisites

Before you start:

A JustAnalytics account with uptime monitoring enabled (Pro plan or higher — Free tier doesn't include status pages)
At least one uptime check already configured and collecting data
A custom domain you want to use (like status.yourcompany.com) — optional but recommended
Access to your DNS settings if using a custom domain

If you don't have uptime checks set up yet, the uptime monitoring setup section in our consolidation guide covers that first. Django teams can also check our Django analytics and error tracking middleware tutorial.

Step 1: Enable the Status Page

In your JustAnalytics dashboard, go to Uptime → Status Page and click Create Status Page.

You'll see a form asking for:

Page name: What customers see as the title (e.g., "Acme Corp Status")
Subdomain: The default URL before you add a custom domain (e.g., acme.status.justanalytics.app)
Timezone: For displaying incident timestamps — use your primary customer timezone, not your own

Hit create. You now have a status page at the subdomain you chose. It's empty, which is fine. We'll populate it next.

The whole thing took maybe ninety seconds. I spent longer than that just finding Statuspage.io's pricing page last time I evaluated them.

Step 2: Add Components From Your Uptime Checks

A "component" on a status page is a service customers care about — API, dashboard, mobile app, webhooks. Each component maps to one or more uptime checks.

Go to Components and click Add Component. You'll see a dropdown of your existing uptime checks. Select the relevant one(s) and give the component a customer-friendly name.

Example mapping:

Uptime Check Name	Component Name
`prod-api-us-east-1-health`	API
`dashboard-prod-https`	Dashboard
`webhook-delivery-check`	Webhooks
`mobile-api-v2-health`	Mobile App

Don't expose internal services. Seriously. Your admin panel going down at 3am isn't something customers need to know about — and it makes your status page look busier than it needs to be. Less is more here.

Once you've added components, the status page auto-populates with their current state. Green for operational, yellow for degraded, red for down. This pulls directly from your uptime check results — no manual status updates needed.

The 90-day uptime history per component also populates automatically. Customers can see your actual track record, not a self-reported number.

Step 3: Configure Incident Auto-Creation (Optional but Worth It)

This is the part I actually care about.

By default, you still create incidents manually. But you can enable auto-incident creation so that when an uptime check fails for more than N minutes, an incident appears on the status page automatically.

Go to Settings → Incident Automation and configure:

Failure threshold: How many consecutive failures before creating an incident (I use 3 — one failure could be a network blip)
Auto-resolve: Whether to automatically resolve the incident when the check passes again
Auto-create incidents: Toggle on

With this enabled, the 2:47am scenario changes completely. Database times out, three consecutive checks fail, incident auto-creates on the status page. Customers see it immediately. I get paged, but I'm not racing to update a status page before customers tweet — they can already see what's happening.

One caveat: auto-created incidents have generic titles like "API experiencing issues." You'll want to add updates with more detail once you've diagnosed the problem. But at least the initial "yes, we know it's down" is handled. Honestly, that's 80% of the battle at 3am — acknowledgment.

Step 4: Set Up Subscriber Notifications

Status pages are more useful when customers can subscribe to updates. Otherwise they're just refreshing the page manually.

Go to Subscribers → Settings and enable:

Email subscriptions: Customers enter their email, get notified when incidents start/update/resolve
Webhook subscriptions: For customers who want to pipe updates into Slack or their own monitoring
RSS feed: Old school but some enterprise customers still use it

The subscription widget appears at the bottom of your status page automatically.

For webhook subscribers, we send a JSON payload like:

{
  "event": "incident_created",
  "incident": {
    "id": "inc_4f8a2b",
    "title": "API experiencing elevated error rates",
    "status": "investigating",
    "components": ["API", "Webhooks"],
    "created_at": "2026-06-18T02:47:00Z"
  }
}

Teams using DevOS for deployment can wire this into their AI-powered incident response flow — status page updates, Slack notifications, and runbook triggers all from the same event.

Step 5: Connect Your Custom Domain

The default acme.status.justanalytics.app works, but status.acme.com looks more professional.

Go to Settings → Custom Domain and enter your desired domain (e.g., status.yourcompany.com).

You'll need to add a CNAME record in your DNS:

status.yourcompany.com → status.justanalytics.app

DNS propagation takes anywhere from 5 minutes to 48 hours depending on your provider. In practice, it's usually under an hour. The dashboard shows a "Pending verification" status until the CNAME resolves.

SSL is automatic — we provision a certificate via Let's Encrypt once the domain verifies. No need to manage certs yourself.

Quick note: if you're using Cloudflare, make sure you're not proxying the CNAME (orange cloud off). We need direct DNS resolution to verify ownership and provision the cert. I've seen teams spend hours debugging this when the fix is one checkbox.

Step 6: Create Your First Manual Incident

Auto-created incidents handle the "something is broken" scenario. But you'll also need to create incidents manually for:

Planned maintenance windows
Partial degradation that doesn't trip an uptime check
Third-party issues affecting your service (payment processor down, etc.)

Go to Incidents → Create Incident and fill in:

Title: Keep it customer-friendly. "Database migration in progress" not "Running pg_repack on prod-db-3"
Status: Investigating, Identified, Monitoring, Resolved, or Scheduled (for maintenance)
Affected components: Which services are impacted
Message: What's happening and what customers should expect

For maintenance, you can set a scheduled start and end time. The incident shows up on the status page as "Scheduled Maintenance" with the window displayed. Subscribers get notified at the start and end.

I've found 24-48 hours notice for planned maintenance is the sweet spot. Anything less and customers complain they weren't warned. Anything more and they forget. (I learned this the hard way. Twice.)

Common Errors and How to Fix Them

Custom domain shows "Verification failed"

The CNAME record either isn't set up correctly or hasn't propagated yet. Check with dig status.yourcompany.com CNAME — you should see status.justanalytics.app in the response. If not, double-check your DNS settings. If you're using Cloudflare, make sure the record isn't proxied (orange cloud should be gray).

Uptime check is failing but no incident was created

Check your incident automation settings. The failure threshold might be set higher than the number of consecutive failures, or auto-create might be disabled. Also verify the check is assigned to a component that's on the status page — orphaned checks don't trigger incidents.

Subscribers aren't receiving email notifications

Check the subscriber's email isn't bouncing. We stop sending after 3 bounces to protect deliverability. Also check spam folders — status page emails from new domains sometimes get flagged initially. If you're running JustEmails for transactional email, you can route status notifications through your own domain to avoid this.

Status page shows wrong timezone

Incident timestamps display in the timezone you configured when creating the page. Go to Settings → General to change it. This doesn't retroactively update existing incidents — they keep their original timestamps.

Components show "Unknown" status

The uptime check linked to that component hasn't run yet, or it's been paused. Check that the monitor is active and configured correctly.

Next Steps

You've got a working status page pulling from your actual uptime data. A few things to consider next:

Add your status page link to your error pages. When customers hit a 500, show them "Having trouble? Check our status page" with a link. This alone cut our support tickets by maybe 40% during incidents. Maybe more.

Link from your footer and docs. Make the status page discoverable before customers need it. I'm constantly surprised how many SaaS companies bury their status page — or don't have one at all.

Set up SLA reporting. If you have uptime commitments in customer contracts, the 90-day history on your status page is now your source of truth. We've covered correlating errors with analytics and SLO tracking in depth if you want to formalize this.

Consider component grouping. If you have 15+ microservices, group them logically (Core Platform, Integrations, Mobile) so the status page isn't overwhelming. Customers don't need to know about every internal service — they care about whether "the thing they use" works.

Dedicated status page vendors charge anywhere from $29 to $99+ per month — on top of whatever you're paying for uptime monitoring. That's absurd. You're already paying for uptime checks — the status page should come with them.

Teams running ad campaigns alongside their product can correlate status page incidents with ClickzProtect conversion data — if your site was down during peak ad spend hours, that explains the CPA spike better than blaming the algorithm. For Next.js apps, our Next.js 15 analytics tutorial covers the full integration.

Frequently Asked Questions

Do I really need a public status page?

If you have paying customers and any kind of SLA, yes. Support tickets drop 30-50% during outages when customers can self-serve status information instead of emailing you. It also builds trust — companies that hide their uptime look like they have something to hide. If you're pre-revenue or purely internal tooling, probably skip it. But the moment you have customers expecting availability, a status page pays for itself in reduced support load.

What's the difference between a status page and uptime monitoring?

Uptime monitoring is the internal plumbing — your tools checking endpoints every 30-60 seconds and alerting your team when something fails. A status page is the public-facing surface that shows customers which services are up, any ongoing incidents, and historical uptime. Most vendors sell these as separate products with separate bills. JustAnalytics bundles them — your uptime checks automatically populate the status page, and incidents you create during on-call show up in the timeline.

Can I customize the status page design to match my brand?

Yes. You can set your logo, brand colors, and custom domain (status.yourcompany.com). The layout is intentionally simple — customers want information, not design awards. You can also choose which monitors to expose (maybe your internal admin panel doesn't need to be public) and customize component names (so 'prod-api-us-east-1' shows as 'API' to customers).

How do I handle planned maintenance windows?

Create a scheduled maintenance incident in advance. It shows up on the status page with start and end times, affected components, and your description of what's happening. Subscribers get notified when maintenance starts and ends. The key thing: don't just surprise customers with a maintenance window. Give them 24-48 hours notice via the status page. Your uptime percentage during scheduled maintenance can be excluded from SLA calculations if you configure it that way.

Try JustAnalytics

All-in-one observability in one under-5KB script: cookieless analytics + error tracking + APM + session replay + uptime + structured logs. Replaces GA4 + Sentry + Datadog + Pingdom + LogRocket. Free tier (100K events/mo), Pro $49/month ($39 annual).

Start free → · AI Command Center MCP