March 12, 2026 (1mo ago)
Written by Temps Team
Last updated March 12, 2026 (1mo ago)
Statuspage.io starts at $29/month for a single page. Cachet, the most popular open-source alternative, hasn't seen a commit since 2022. Meanwhile, your users are finding out about downtime from Twitter threads and Reddit complaints — which is the worst possible way to handle incidents.
Here's the thing: a status page isn't a luxury feature. It's basic operational hygiene. According to Atlassian, teams with public status pages see 30-40% fewer support tickets during incidents. That's because users who can check status themselves don't open tickets asking "is it down?"
This guide covers what a good status page looks like, how to build one from scratch, the open-source tools worth considering, and a zero-config option if you'd rather skip the plumbing.
TL;DR: A status page reduces support tickets by 30-40% during outages. You can build one with health check endpoints, a polling aggregator, and a static HTML page — roughly 80 lines of code. Or use an open-source tool like Gatus or Upptime. Temps includes a status page per project with automatic health checks, no extra setup needed.
Teams with public status pages resolve incidents 20% faster on average, according to PagerDuty's State of Digital Operations report. A status page isn't just about transparency — it directly reduces the operational cost of every outage you'll ever have.
When your app goes down, users panic. They can't tell if it's their network, their browser, or your server. So they file tickets. Every single one of those tickets costs you time — reading, triaging, responding with "we're aware of the issue."
A status page short-circuits that entire loop. Users check the page, see the incident banner, and wait. Your support queue stays manageable. Your on-call engineer stays focused on actually fixing the problem instead of answering emails.
If you sell to businesses, you'll hit SLA requirements sooner than you think. SOC 2 audits ask about incident communication procedures. Enterprise procurement teams check whether you have a public status page before signing contracts.
According to Gartner, 78% of enterprise IT buyers consider vendor transparency during outages a key evaluation criterion. A status page is often the simplest way to check that box.
Have you ever received a bug report that was actually just a service outage? It happens constantly. Without a status page, users can't distinguish between "the app is broken for everyone" and "something is wrong on my end."
A visible status indicator saves both sides time. Users self-triage. Your engineering team gets fewer false bug reports. Everyone wins.
A well-designed status page covers five elements. According to Pingdom's downtime survey, 92% of users expect real-time status updates during outages. Meeting that expectation requires more than a green checkmark.
Don't show a single "up" or "down" indicator for your entire app. Break it into components: API, web app, database, authentication, CDN, background jobs. Users need to know which parts are affected.
Three states work well: Operational, Degraded Performance, and Major Outage. Some teams add a fourth — Partial Outage — for situations where only some regions or user segments are impacted.
Every incident needs a timeline. When did it start? What's being done? When was it resolved? Post updates every 20-30 minutes during active incidents, even if the update is "still investigating."
The worst thing you can do is post "we're investigating" and go silent for two hours. Users assume you've forgotten about them. Frequent updates — even without new information — signal that the team is actively working.
Show a rolling 90-day uptime percentage per component. This gives users context. Is this a rare blip on a 99.99% track record, or is it the third outage this month on a service struggling to hit 99.5%?
A simple bar chart with daily uptime works well. Green bars for clean days, yellow for degraded, red for outages. GitHub's status page does this effectively.
Proactive communication matters as much as reactive. Post maintenance windows at least 48 hours in advance. Include the expected duration, which components are affected, and whether users will experience downtime.
A latency graph for the past 24-72 hours shows users whether performance has been degrading. If your API response time crept from 100ms to 800ms over four hours before the outage, that context helps users understand what happened.
[IMAGE: Example status page layout showing component status, uptime bars, and incident timeline — search: "status page dashboard uptime monitoring components"]
A status page system has five parts: health check endpoints, an aggregator, status computation, a public page, and a notification system. According to the Stack Overflow Developer Survey, 62% of professional developers manage some form of infrastructure monitoring. Yet many still cobble together ad-hoc solutions instead of building proper health check infrastructure.
Every service in your stack needs a /health endpoint. This isn't a simple return 200 — a good health check verifies that the service can actually do its job.
For an API server, that means checking database connectivity, cache availability, and external service reachability. For a background worker, it means verifying the job queue is connected and processing. A health endpoint that always returns 200 is worse than no health endpoint — it gives you false confidence.
// Good health check response
{
"status": "healthy",
"checks": {
"database": { "status": "up", "latency_ms": 3 },
"redis": { "status": "up", "latency_ms": 1 },
"storage": { "status": "up", "latency_ms": 12 }
},
"version": "2.4.1",
"uptime_seconds": 847293
}
The aggregator is a service (or cron job) that polls each health endpoint at regular intervals — typically every 30-60 seconds. It records the response status, latency, and any error details.
Keep the polling interval consistent. Irregular checks create noisy data. And always poll from outside your infrastructure — checking health from the same server that runs the service doesn't tell you much about actual user reachability.
Raw health check data needs processing before it becomes useful status information. A single failed check shouldn't flip a component to "Major Outage" — network blips happen. Most systems use a threshold: three consecutive failures trigger a status change.
The logic looks roughly like this: if the last 3 checks all failed, mark as "down." If 1-2 of the last 5 checks failed, mark as "degraded." Otherwise, mark as "operational."
The public-facing status page should be hosted separately from your main application. If your app is down, your status page needs to still be accessible. Many teams host the status page on a separate subdomain (status.yourapp.com) with a different hosting provider or CDN.
Subscribers should be able to opt in for email, webhook, or Slack notifications. When a component status changes, the system fires notifications to all subscribers for that component. Keep it simple — status change events in, notifications out.
Building a minimal status page takes roughly 80 lines of code and an afternoon. The Node.js ecosystem alone has over 2,000 packages related to health checks on npm. But you don't need any of them for a basic setup.
We've found that the simplest status page implementations — a polling script, a JSON file, and a static HTML page — tend to be the most reliable. Every dependency you add is another thing that can break during an outage, which is exactly when you need the status page to work.
Start with a /health route in your application. Here's a Node.js/Express example that checks database and Redis connectivity:
app.get('/health', async (req, res) => {
const checks = {};
// Check database
try {
const start = Date.now();
await db.query('SELECT 1');
checks.database = { status: 'up', latency_ms: Date.now() - start };
} catch (err) {
checks.database = { status: 'down', error: err.message };
}
// Check Redis
try {
const start = Date.now();
await redis.ping();
checks.redis = { status: 'up', latency_ms: Date.now() - start };
} catch (err) {
checks.redis = { status: 'down', error: err.message };
}
const allUp = Object.values(checks).every(c => c.status === 'up');
res.status(allUp ? 200 : 503).json({
status: allUp ? 'healthy' : 'unhealthy',
checks,
timestamp: new Date().toISOString()
});
});
A simple polling script runs on a schedule, checks each endpoint, and writes results to a JSON file or database:
const SERVICES = [
{ name: 'API', url: 'https://api.yourapp.com/health' },
{ name: 'Web App', url: 'https://yourapp.com/health' },
{ name: 'Worker', url: 'https://worker.yourapp.com/health' },
];
async function pollServices() {
const results = [];
for (const service of SERVICES) {
try {
const start = Date.now();
const res = await fetch(service.url, { signal: AbortSignal.timeout(5000) });
results.push({
name: service.name,
status: res.ok ? 'operational' : 'degraded',
latency_ms: Date.now() - start,
checked_at: new Date().toISOString()
});
} catch (err) {
results.push({
name: service.name,
status: 'down',
error: err.message,
checked_at: new Date().toISOString()
});
}
}
// Write to JSON file (or insert into database)
await fs.writeFile('./status.json', JSON.stringify(results, null, 2));
}
// Run every 30 seconds
setInterval(pollServices, 30_000);
pollServices();
The simplest approach is a static HTML file that fetches the JSON data and renders it. Host this on a separate server or CDN — it needs to work even when your main app is down.
<!DOCTYPE html>
<html>
<head>
<title>Status - YourApp</title>
<style>
.status-item { padding: 12px; margin: 8px 0; border-radius: 6px; }
.operational { background: #d4edda; color: #155724; }
.degraded { background: #fff3cd; color: #856404; }
.down { background: #f8d7da; color: #721c24; }
</style>
</head>
<body>
<h1>System Status</h1>
<div id="services"></div>
<script>
fetch('/status.json')
.then(r => r.json())
.then(services => {
const el = document.getElementById('services');
el.innerHTML = services.map(s =>
`<div class="status-item ${s.status}">
<strong>${s.name}</strong>: ${s.status}
${s.latency_ms ? `(${s.latency_ms}ms)` : ''}
</div>`
).join('');
});
</script>
</body>
</html>
That's roughly 80 lines across three files. It won't win any design awards, but it works. Run the aggregator as a systemd service or cron job, deploy the HTML to a CDN, and you've got a functional status page.
[CHART: Architecture diagram — Health endpoints → Aggregator (polling) → Status JSON → Static page + Notification service — source: custom]
The open-source ecosystem offers several mature alternatives to building from scratch. GitHub Topics lists over 300 repositories tagged "status-page". Here are the ones actually worth using.
Upptime runs entirely on GitHub Actions. No server required. It stores uptime data in the repository itself, uses GitHub Issues for incidents, and deploys a static status page via GitHub Pages.
Why would you want this? Zero infrastructure cost. GitHub Actions gives you the compute, GitHub Pages gives you the hosting, and the repository itself becomes your database. The tradeoff is that you're limited by GitHub Actions quotas and can't customize beyond what the templating system offers.
Gatus is a single Go binary configured entirely through YAML. Define your endpoints, set alerting conditions, and run it. It supports HTTP, TCP, DNS, ICMP, and even SSH health checks out of the box.
What sets Gatus apart is its condition language. You can write checks like [STATUS] == 200 && [BODY].status == 'healthy' && [RESPONSE_TIME] < 500. That's more expressive than most monitoring tools at any price point.
Statping-ng is the successor to Statping (which, like Cachet, went unmaintained for a while). It includes a web dashboard, multiple notification integrations (Slack, Discord, email, Telegram), and a REST API.
It's heavier than Gatus — it needs a database (SQLite, PostgreSQL, or MySQL) — but gives you more out of the box. If you want a polished web interface without building one, Statping-ng is the closest to a drop-in Statuspage.io replacement.
Cstate generates a static status page using Hugo. You define incidents and component status in Markdown files, and Hugo builds a fast, CDN-friendly static site. It's the lightest option — no backend, no database, no running service.
The downside: incident updates are manual. You create a Markdown file for each incident, which is fine for small teams but doesn't scale if you want automated status changes based on health checks.
Most teams start with a simple tool like Upptime or Cstate and graduate to something like Gatus once they hit 10+ services. The mistake is starting with a heavy tool before you know what you actually need to monitor. Pick the lightest option that covers your current requirements.
| Tool | Language | Database | Auto-Detection | UI | Setup Time |
|---|---|---|---|---|---|
| Upptime | TypeScript | GitHub repo | Yes (Actions) | Static (Pages) | ~15 min |
| Gatus | Go | SQLite/Postgres | Yes (polling) | Built-in web | ~10 min |
| Statping-ng | Go | SQLite/Postgres/MySQL | Yes (polling) | Full dashboard | ~30 min |
| Cstate | Hugo | None (Markdown) | No (manual) | Static site | ~20 min |
| DIY | Any | Any | Custom | Custom | ~2 hours |
Temps includes a built-in status page for every project — no extra services, no configuration files, no separate hosting. According to Datadog's State of Monitoring report, the average organization uses 7.4 monitoring tools. Temps collapses the status page into your existing deployment platform so you don't add yet another tool to that number.
When you deploy an app to Temps, it automatically begins health-checking your service. No /health endpoint configuration required — Temps checks container liveness and HTTP responsiveness out of the box. If you do expose a /health endpoint, Temps uses it for deeper status granularity.
Checks run every 30 seconds from the control plane. Failed checks trigger status transitions using the three-strike rule: three consecutive failures change the component status. Recovery requires two consecutive successful checks to prevent flapping.
Temps creates incident records automatically when health checks detect a problem. Each incident logs the start time, affected components, status transitions, and resolution time. You can also create manual incidents for planned maintenance or partial outages that automated checks don't catch.
The incident timeline is publicly visible on your project's status page. Users see what happened, when it was detected, and how long it took to resolve.
Every project gets a status page at status.yourdomain.com (or a Temps-provided subdomain if you prefer). The page shows component health, a 90-day uptime chart, active incidents, and scheduled maintenance — all the elements covered earlier in this guide.
Because the status page runs on Temps infrastructure, it stays available even if your application containers are down. That's the key requirement most DIY solutions get wrong — hosting your status page on the same server as your app defeats the purpose.
Every 30-60 seconds is the sweet spot for most applications. More frequent checks (every 5-10 seconds) generate excessive load and noisy data without meaningfully faster detection. The Uptime Institute found that 76% of outages are detected within 2 minutes with 30-second polling intervals. If you need sub-second detection, you're looking at push-based health checks instead of polling.
Yes, always. If your application server goes down and your status page lives on the same server, users see nothing — which is worse than showing a "Major Outage" banner. Host your status page on a separate provider, CDN, or static hosting service. GitHub Pages, Cloudflare Pages, or a separate VPS in a different region all work. The goal is independent failure domains.
Uptime monitoring tells you when something breaks. A status page tells your users. They serve different audiences. Your monitoring tool alerts your on-call engineer at 3am. Your status page prevents 200 support tickets from landing in your inbox while that engineer is fixing the problem. You need both.
A static HTML page that shows component status and updates manually via git commits. That's it. Cstate does exactly this with Hugo. You don't need automated health checks, subscriber notifications, or historical charts on day one. Start with manual updates, add automation when the manual process becomes painful. Most teams hit that point around 5-10 incidents per quarter.
A status page is one of those things that seems optional until your first major outage. Then it becomes the difference between "we handled that well" and "why didn't anyone tell us the app was down?"
You've got three paths. Build it yourself with the code examples above — it's an afternoon of work and you'll understand exactly how it fits together. Pick an open-source tool like Gatus or Upptime if you want something battle-tested without the maintenance burden. Or use a platform that includes status pages alongside your deployment pipeline, so monitoring isn't another tool in your stack.
If you want a status page that comes built into your deployment platform — alongside web analytics, error tracking, and uptime monitoring — Temps handles it with zero extra configuration. Deploy your app, and the status page exists.
curl -fsSL https://temps.sh/install.sh | bash