Forem: AlertSleep

Building a Status Page From Scratch vs Using a Service: A Cost Analysis

AlertSleep — Tue, 14 Apr 2026 12:34:59 +0000

Your users know your app is down before you do.

They see the spinning loader, the 502 error, the silence where data should be. And they have nowhere to go for answers. So they flood your support inbox, post on Twitter, and quietly decide to check out your competitor.

A status page changes that dynamic completely. It's not just a "we're working on it" page — it's a trust instrument. It tells users: we see what you see, we're on it, here's what we know.

But here's the question every engineering team eventually faces: do you build it, or do you buy it?

Let me break down the real costs of both.

What a Status Page Actually Needs to Do

Before comparing options, let's align on minimum viable functionality:

Show current status of each component (API, dashboard, payments, etc.)
Display active incidents with live updates
Historical uptime data (last 30-90 days)
Subscriber notifications (email, SMS) when incidents are created or resolved
Maintenance window announcements
Public URL that stays up even when your app is down

That last point is critical and often overlooked: your status page must be hosted independently from your main infrastructure. A status page that goes down with your app is worse than no status page at all.

Option A: Build It Yourself

What you're actually building

Most teams underestimate the scope. A status page isn't a static HTML file — it's a small application:

Frontend:

Component status grid with color states (operational / degraded / outage)
Incident timeline with markdown support
Uptime history graph (requires storing and querying ping data)
Subscriber signup form

Backend:

API to update component status
Incident management CRUD
Email/SMS notification system (integrate Mailgun, SendGrid, Twilio)
Webhook receiver (if you want auto-updates from your monitoring tool)

Infrastructure:

Hosted separately from your main stack (different cloud region, different provider)
Must stay online during your worst outages

Realistic time estimate

Task	Hours
Basic frontend (React/Vue)	8–16 hrs
Backend API	8–12 hrs
Email notifications	4–6 hrs
SMS notifications	3–5 hrs
Historical uptime graph	6–10 hrs
Separate hosting setup	2–4 hrs
Testing & polish	4–8 hrs
Total	35–61 hrs

At a conservative $75/hr developer rate, that's $2,600 – $4,600 before the first user sees it.

Ongoing costs

~2–4 hours/month maintenance
Hosting: $5–20/month (Fly.io, Railway, Render)
Email service: $0–15/month (SendGrid free tier runs out)
Total recurring: $60–$420/year

The hidden cost nobody accounts for

Your status page will have its first real test during your worst incident. When your database is on fire and every engineer is in a war room call, someone also has to update the status page.

If that status page is your own codebase — with its own deployment pipeline, its own bugs, its own "why isn't the email sending" moments — you've just doubled the cognitive load during the exact moment you can least afford it.

Option B: Use a Service

The main players in 2026

Service	Free Tier	Paid Starts At	Notes
Atlassian Statuspage	No	$29/mo	Industry standard, complex
Better Uptime	Limited	$20/mo	Good UX, integrated monitoring
Instatus	Yes (limited)	$20/mo	Clean, fast
AlertSleep	Yes	Paid plans available	Integrated with uptime monitoring
Cachet (self-hosted)	Free	Hosting costs	Open source, DIY maintenance

What you get immediately

Status page live in 10 minutes
Subscriber management handled
Hosted on separate, reliable infrastructure
Incident management UI (no code required)
Uptime history auto-populated from monitoring checks
Mobile app for on-call updates

The real cost comparison

Scenario	Build	Buy (mid-tier)
Initial setup cost	$2,600–$4,600	$0
Time to launch	1–2 weeks	10 minutes
Monthly recurring	$5–35/mo	$20–29/mo
Year 1 total	$2,900–$5,000	$240–$350
Year 2 total	$60–$420	$240–$350
Break-even	~Year 8	—

The build option theoretically becomes cheaper in year 8. But it doesn't account for the ongoing maintenance, the engineering time spent on features instead of your core product, or the incidents that went poorly because the status page had a bug.

When Building Makes Sense

There are legitimate reasons to build your own:

Build if:

You're a platform company where the status page is part of your product (think Vercel, Heroku)
You need deep integration with proprietary internal tooling
You have dedicated SRE resources with time to maintain it
You have specific branding/white-label requirements that no service offers
You're already building a monitoring platform yourself

Buy if:

You have fewer than 10 engineers
You need it working before your next launch
Your team is already stretched thin
You've had a public incident and need to restore user trust quickly

The Architecture Decision Nobody Talks About

Whether you build or buy, there's one architectural decision that matters more than everything else:

Your status page data must come from external monitoring, not internal reporting.

If your status page only shows "down" when your own systems detect and report it, you have a problem: your systems might be down in a way that prevents them from self-reporting.

The right architecture:

External monitor (different cloud, different region)
    ↓ detects outage
    ↓ triggers alert
    ↓ auto-creates incident on status page
    ↓ notifies subscribers
    ↓ engineers get paged

Not:

Your app
    ↓ is down
    ↓ engineer notices 20 minutes later
    ↓ manually logs into status page
    ↓ manually creates incident
    ↓ users have been confused for 20 minutes

This is why integrated solutions — where your uptime monitoring and status page share data — tend to work better in practice.

The Recommendation

For most teams: buy, don't build.

Not because building is wrong — building is often the right answer for product problems. But a status page is infrastructure, not product. It should be invisible when things are working and bulletproof when things aren't.

The engineering time you'd spend building a status page is almost certainly better spent on the features that make outages less frequent in the first place.

Start with a free tier, get it live this week, and revisit when you've outgrown it.

What's your current setup? If you're still manually emailing users during incidents, it's worth spending 10 minutes setting up something better. Tools like AlertSleep let you connect uptime monitoring directly to a public status page — so when a check fails, the incident is created automatically.

Drop your status page setup in the comments — curious what the dev.to community is using.

What 99.9% Uptime Actually Means: 8.7 Hours of Downtime Per Year

AlertSleep — Sun, 12 Apr 2026 06:07:48 +0000

You've seen it everywhere. On hosting pages, SaaS pricing tables, cloud provider dashboards:

"99.9% uptime guaranteed"

Sounds impressive. Almost perfect. Like, what's 0.1%?

A lot, actually. Let me show you the math — and more importantly, what it means for your users, your revenue, and your sleep schedule.

The Math Nobody Does

99.9% uptime means your service is unavailable for 0.1% of the time.

Here's what 0.1% looks like across different time windows:

Time Period	Allowed Downtime
Per day	1 minute 26 seconds
Per week	10 minutes 4 seconds
Per month	43 minutes 49 seconds
Per year	8 hours 45 minutes

That last one is the one that should make you pause. 8 hours and 45 minutes of downtime per year — and your SLA is technically fine the whole time.

The Full SLA Cheat Sheet

Most people only know the "three nines" (99.9%). Here's the complete picture:

SLA	Downtime/Year	Downtime/Month	Downtime/Day
99%	3 days 15 hrs	7 hrs 18 min	14 min 24 sec
99.5%	1 day 19 hrs	3 hrs 39 min	7 min 12 sec
99.9%	8 hrs 45 min	43 min 49 sec	1 min 26 sec
99.95%	4 hrs 22 min	21 min 54 sec	43 sec
99.99%	52 min 35 sec	4 min 22 sec	8.6 sec
99.999%	5 min 15 sec	26 sec	0.86 sec

The jump from 99.9% to 99.99% — one extra "9" — reduces your annual downtime budget from 8.7 hours to 52 minutes. That's a 10x difference.

Calculate Your Own Uptime

The formula is simple:

Downtime = Total Time × (1 - Uptime %)

For example, a year has 365.25 × 24 = 8,766 hours.

At 99.9%:

8,766 hours × 0.001 = 8.766 hours ≈ 8 hrs 45 min

Or in JavaScript, if you want to build it yourself:

function calculateDowntime(uptimePercent, periodHours) {
  const downtimeRatio = 1 - (uptimePercent / 100);
  const downtimeHours = periodHours * downtimeRatio;
  const downtimeMinutes = downtimeHours * 60;
  const downtimeSeconds = downtimeMinutes * 60;

  return {
    hours: Math.floor(downtimeHours),
    minutes: Math.floor(downtimeMinutes % 60),
    seconds: Math.floor(downtimeSeconds % 60),
  };
}

// 99.9% uptime over a year (8766 hours)
console.log(calculateDowntime(99.9, 8766));
// → { hours: 8, minutes: 45, seconds: 46 }

If you'd rather skip the math, tools like AlertSleep's uptime calculator let you punch in any percentage and get the breakdown instantly.

"But Our SLA Excludes Planned Maintenance"

This is the clause that quietly turns "99.9%" into "something much lower."

Many SLAs include language like:

"Uptime calculations exclude scheduled maintenance windows, force majeure events, and incidents caused by the customer."

In practice, this means a vendor can take their service down for a 4-hour maintenance window every month and still advertise "99.9% uptime" — because those hours simply don't count.

Always check:

Does the SLA count maintenance windows as downtime?
How much advance notice is required for scheduled maintenance?
What's the compensation if they breach the SLA? (Hint: it's usually service credits, not money)

What Does Downtime Actually Cost?

Here's where it gets real. Abstract percentages become concrete when you map them to your business.

A rough formula used by most reliability engineers:

Cost of Downtime = Lost Revenue/hr + Productivity Cost/hr + Reputation Damage

For an e-commerce site doing $100k/day in revenue:

Revenue per hour = $100,000 / 24 ≈ $4,166/hr

At 99.9% uptime → 8.75 hours of downtime/year
→ Lost revenue: 8.75 × $4,166 ≈ $36,000/year

And that's before counting the customer support tickets, the social media complaints, and the users who never come back.

The "Five Nines" Problem

You'll sometimes see "five nines" (99.999%) thrown around by cloud providers. It sounds incredible — only 5 minutes of downtime per year.

But here's the uncomfortable truth: achieving five nines is mostly about architecture, not monitoring.

Five nines requires:

Multi-region active-active deployments
Zero-downtime deployments (blue/green or canary)
Automatic failover with sub-second detection
Chaos engineering to test failure scenarios

Most startups and even mid-size companies realistically operate at 99.5% to 99.95%. And that's fine — if you know it and plan for it.

The Difference Between Measured and Actual Uptime

Here's a subtle but important distinction.

Your hosting provider might achieve 99.99% uptime at the infrastructure level. But your application might only hit 99.5% because of:

Memory leaks that require weekly restarts
Slow database queries that cause timeouts (HTTP 504 — is that "downtime"?)
Third-party API dependencies that go down
SSL certificate expiry (this kills more sites than you'd think)
Your own deployment going wrong at 2am

Your uptime is only as good as the weakest link in the chain. And the only way to know your real uptime — not your provider's uptime — is to monitor from the outside.

What to Actually Monitor

Most developers start monitoring too late and measure too little. Here's a baseline:

Minimum viable monitoring:

[ ] HTTP status check every 1-5 minutes
[ ] Response time tracking (a 503 that takes 30s is worse than a fast 503)
[ ] SSL certificate expiry alert (set to 30 days before)
[ ] Domain expiration alert (set to 60 days before)

Level up:

[ ] Multi-region checks (your site might be down only in the US East)
[ ] API endpoint monitoring (not just the homepage)
[ ] Port monitoring for non-HTTP services

Alert channels that actually wake you up:

SMS/phone call for critical alerts (email is too easy to miss at 3am)
Slack/Teams for the team
Status page for your users so they know you know

The Real Takeaway

99.9% uptime is not "always online." It's a budget — a budget of how much downtime your users are willing to accept before they find an alternative.

The question isn't "what SLA does my provider offer?" The question is:

What uptime does your business actually need — and how will you know when you're not hitting it?

The first step is measuring. You can't improve what you can't see.

If you're building something people depend on, set up external uptime monitoring today — not after the first outage. Tools like AlertSleep start free and take about 2 minutes to configure.

What SLA does your app target? And are you actually measuring it? Drop it in the comments.