DEV Community: Nikola

I Built a Server Agent Because Uptime Checks Tell You What Failed, Not Why

Nikola — Tue, 04 Aug 2026 21:14:20 +0000

A status page has a blind spot.

It can tell you that your API is returning 502s. It can tell you that a TCP port stopped accepting connections. It can tell you when the incident started.

It usually cannot tell you why.

Was the application host out of memory? Was disk I/O saturated? Did load climb for 40 minutes before users noticed? Was the server completely healthy and the real problem somewhere else?

Those answers often live in a separate monitoring product, disconnected from the incident timeline and disconnected from the status page.

That is why I built Servers for StatusPage.me.

It is a small, customer-installed host metrics agent and dashboard. You install it on a machine you operate, and it reports CPU, memory, swap, load, disk, and network metrics back to your account.

The important part is not “now there are more graphs.”

The important part is seeing an outage and the host evidence around it on the same timeline.

External checks answer one question. Host metrics answer another.

Regular uptime monitoring is still the right tool for the outside-in view:

Can users reach the website?
Is the API returning the expected response?
Does DNS resolve correctly?
Is the database port open?
Did a scheduled job run?

But those checks do not run inside your infrastructure.

A healthy HTTP response does not prove that a background worker is about to run out of memory. A timeout does not prove that the app server is overloaded. And an incident can start with a slow disk or growing swap usage long before an endpoint is fully unavailable.

The distinction is simple:

External monitoring tells you what users can see.

Host metrics help explain what the machine was doing when they saw it.

You need both.

What Servers includes

Each registered host gets a dedicated dashboard page with:

CPU user, system, and I/O wait utilization
Memory use
Swap use
Load averages
Disk use and read/write throughput
Network inbound and outbound throughput
A human-readable OS description for account owners
Current values, historical charts, one-hour change, and small trend sparklines

The dashboard has views from one hour to 30 days, subject to your plan’s retention.

There is also a practical detail that matters during a real incident: if the server is linked to a StatusPage.me status page, the incident windows are shaded directly on its charts.

That lets you answer questions like:

Did memory climb before the API went down?
Did the load spike end when the incident was resolved?
Was the host normal while the dependency failed?
Is this a recurring pattern or a one-off event?

That is more useful than opening four dashboards, trying to align timestamps, and guessing.

Threshold alerts without alerting on every spike

Servers also supports threshold rules on plans that include Server Agent alerts.

You can alert on metrics such as CPU, memory, swap, load, disk, disk I/O, and network throughput. More importantly, you choose how long a condition must hold before it fires.

That duration is deliberate.

A brief CPU spike during a deploy should not wake someone up. Sustained resource pressure probably should.

The goal is not to turn every graph into another noisy alert source. It is to catch the conditions that are likely to become an incident before they do.

The agent is open source because it runs on your production machines

Asking someone to install an agent on a production server is a trust request.

“Trust us” is not a sufficient answer.

The Server Agent is open source:

https://github.com/hosted-status-page/hsp-server-agent

You can read the installer, the collector, the protocol, and the privacy documentation before installing anything.

The dashboard generates a one-time installation command for each server:

curl -fsSL https://statuspage.me/install-server-agent.sh | sudo bash -s -- \
  --server-id <server-id> \
  --ingest-key <ingest-key>

You should read a script before piping it into sudo bash. That is true here, and it is true everywhere.

The installer verifies the downloaded binary against a published SHA-256 checksum. It then installs the agent as a dedicated non-login system user, rather than leaving a root process running indefinitely.

The resulting systemd service is deliberately restricted:

No new privileges
No Linux capabilities
Read-only filesystem access except for its own local buffer
Private temporary directory and devices
Restricted system calls
Memory and CPU limits

The agent needs to read system counters. It does not need to be a foothold on your host.

What data it collects

By default, the agent collects one sample every 60 seconds and sends it outbound over HTTPS.

A sample contains operational counters:

CPU percentages
Memory and swap usage
Load averages
Disk capacity and I/O throughput
Network throughput
Uptime
Optional per-filesystem and per-interface breakdowns

It can also report an operating-system description and an optional hostname.

The hostname is optional because hostnames often contain a person’s name, internal project name, or other information you may not want to retain. You can send no hostname at all, and you can edit or clear it from the dashboard later.

Authentication is per server. The agent sends a server ID and ingest key in request headers, not in the URL. On the server side, the ingest key is stored as a one-way hash rather than plaintext.

What it explicitly does not collect

This is the more important list.

The agent does not collect:

Process names or process lists
Command lines
Environment variables
File contents
User accounts
Network peers
Raw client IP addresses

That is not just a policy statement. The wire protocol has a fixed schema. The ingest service rejects unknown fields instead of accepting arbitrary JSON and hoping it is harmless.

There is no generic “metadata” bucket where process arguments, secrets, or application data can quietly end up later.

You can inspect exactly what a host would send before configuring anything:

serveragent -metrics
serveragent -dry-run

The first prints the collection policy. The second prints a real sample from the machine.

What happens when StatusPage.me is unreachable?

A monitoring agent that fills the disk during an outage is worse than useless.

If the endpoint is unreachable, the agent keeps collecting metrics and stores unsent samples locally. When connectivity returns, it flushes them oldest-first.

The buffer is bounded: by default, it holds up to 2,880 samples, or roughly 48 hours at the default cadence. At the limit, the oldest samples are discarded.

That tradeoff is intentional.

Losing old telemetry after a prolonged communication outage is better than turning the monitored host into the outage by consuming its disk. Samples are removed from the local buffer only after the server confirms they were stored, and ingestion is idempotent so retries do not create duplicates.

On the server side, raw metrics are stored in time-partitioned tables, then rolled up for longer retention according to the account’s plan.

Deleting a server removes its stored metrics. Uninstalling the agent removes its binary, configuration, service account, and local buffer.

Public infrastructure health, without publishing your infrastructure

Some teams want to show customers more than “all systems operational.”

That is reasonable. But publishing a server name, hostname, IP address, or exact disk capacity is not.

Servers can optionally expose a small Infrastructure section on a public status page when a host is linked to a component and the plan allows it.

What is shown:

The component name
CPU percentage
Memory percentage
Disk percentage

What is never shown:

The server’s name
Hostname
IP address
Operating-system details
Absolute byte counts
Internal capacity

If the host stops reporting, it disappears from the public view instead of showing stale data.

That is the boundary: show a useful operational signal, not an infrastructure inventory.

This is not trying to replace every observability tool

Servers is not a log platform. It is not distributed tracing. It is not a process profiler. It does not pretend to be a full observability suite.

It is intentionally narrow.

The job is to connect the status page, the incident timeline, and the host-level signals that help explain an outage.

If an API fails while memory climbs steadily, that should be obvious. If the host is healthy, that should be obvious too.

The product is available now in StatusPage.me. The source for the agent is here:

https://github.com/hosted-status-page/hsp-server-agent

And the full setup guide is here:

https://statuspage.me/docs/servers/servers-monitoring

I Switched Domains Based on ChatGPT's Advice and Lost All My Google Rankings (4 Month Migration Case Study)

Nikola — Fri, 13 Feb 2026 23:29:21 +0000

In late 2025, I revived a project I'd put on hold for years.

I had two domains:

hostedstatus.page - Ranking #1-3 for "hosted status page" on all search engines
statuspage.me - Sitting unused since 2018

I asked ChatGPT: "Which domain should I use?"

ChatGPT said: "statuspage.me is catchier and more memorable. Switch to it."

I trusted the AI.

I did a proper domain migration:

301 redirects from hostedstatus.page → statuspage.me
Google Search Console domain change notification
Bing Webmaster Tools migration
Yandex domain change

Everything by the book.

Four months later:

Google: Invisible (page 10+)
DuckDuckGo: Page 1, position #3
Bing: Multiple page 1 rankings
ChatGPT: Citing my content

Here's what actually happened when I migrated domains — and why different search engines behave so differently.

The Setup

I've been building StatusPage.me - a status page and monitoring service for indie hackers, SMBs, SaaS companies, etc. The product differentiates through indie-first pricing, an OSS Hero program (free for open source projects), and affordable pricing.

Back in ~2018, I registered both domains:

hostedstatus.page - Self-documenting, clear value prop
statuspage.me - Shorter, snappier, competing with statuspage.io

I built the initial version on hostedstatus.page, but the product went on hold due to an employment contract with an IP clause. During those years, hostedstatus.page sat there, accumulating some organic search authority.

In 2025, I left that job and revived the project. I immediately decided to migrate to statuspage.me and asked ChatGPT for confirmation.

The Decision

ChatGPT's reasoning seemed solid:

"statuspage.me is catchier, more memorable, and easier to say. It competes directly with statuspage.io in people's minds. The shorter domain is better for branding."

This felt right. hostedstatus.page was wordy and defensive. statuspage.me was confident and clean.

What I didn't consider: I was asking for branding advice, not SEO advice.

For a bootstrap SaaS dependent on organic traffic, that's a critical distinction.

The Migration (Done Right)

I did everything correctly:

301 redirects from every hostedstatus.page URL → statuspage.me equivalent
Google Search Console "Change of address" tool
Bing Webmaster Tools domain migration notification
Yandex domain change submission
Updated all backlinks I had control over

This is textbook domain migration. Every SEO guide says this is how you do it.

And it worked... sort of.

The Crash (Google)

Google rankings before migration:

"hosted status page": Position #1-3
"status page": Lower first page / page 2
Clean organic traffic from search

Google rankings 4 months after migration:

"hosted status page": Page 10+ (invisible)
"status page": Page 10+ (invisible)
Organic traffic: Significantly reduced

Google Search Console showed:

⚠️ "This site is currently moving to statuspage.me"
✅ Pages being indexed (621 indexed pages)
❌ Link data: "No data" (authority not yet transferred)

The migration was recognized but not processed.

The Plot Twist

After sharing my story on X, my wife suggested I check other search engines.

I had been so focused on Google that I hadn't looked elsewhere.

DuckDuckGo results:

Searching "status page":

Position #3: My blog post "What Is a Status Page? The 2026 Practical Guide"

Searching "statuspage":

Position #3: StatusPage.me homepage
Beating Status.io, Better Stack, StatusGator

Bing results:

Searching "statuspage":

Multiple page 1 listings for statuspage.me
Blog post + homepage both ranking

ChatGPT search:

When people ask ChatGPT about status pages, it cites my blog post as a reference source.

Google results:

Searching "status page":

Invisible. Page 10+.

What I Learned: Different Engines, Different Timelines

Domain migrations don't happen uniformly across search engines.

DuckDuckGo / Bing:

Processed the 301 redirects in 2-4 weeks
Transferred most link equity quickly
Content quality weighted heavily
Freshness and relevance prioritized

Google:

Takes 6-12 months to fully transfer authority
More conservative about domain migrations (anti-manipulation)
Heavier emphasis on domain age and backlink history
Competitive keywords get extra scrutiny

The technical migration was done correctly. The difference is algorithmic philosophy, not execution.

Why Google Is Slower

Google's caution makes sense from their perspective:

Domain migrations can be gamed - Buying aged domains to inherit authority
Competitive keywords = higher scrutiny - "status page" is a commercial keyword
Authority takes time to validate - Google wants proof the new domain deserves the old rankings
Link graph recalculation is expensive - Backlinks need to be revalidated

Bing and DuckDuckGo recovered faster because they weight content quality and freshness more heavily than domain authority history.

The Data Backs This Up

My domain metrics:

Domain Rating: 36/100 (respectable)
Referring Domains: 72
Domain Age: 6 years, 11 months (registered 2018, but unused until late 2025)

The backlinks exist. Google just hasn't credited them yet.

Meanwhile, DuckDuckGo and Bing saw the 301s, validated the content, and moved on.

What Didn't Work: The Directory Submission Grind

I'll be honest about something that wasted time: directory submissions.

After the migration, I submitted statuspage.me to dozens of directories. The metrics looked promising:

Domain Rating climbed from 1 → 36
Referring domains grew from 1 → 72
Backlink count hit 1,668

The result?

Organic traffic: 0 (until Jan 2026, then 1 visit/month)
Google rankings: Still page 10+
Actual conversions: 0

Directory links are vanity metrics. They raise your DR number, but most directories have little to no authority themselves. Google doesn't value them.

What actually drove results:

Quality blog content on dev.to
DuckDuckGo/Bing ranking my actual helpful content
ChatGPT citing my blog post

The lesson: One well-written, genuinely useful blog post > 50 directory submissions.

Was It A Mistake?

Short answer: No, but with caveats.

What I got right:

statuspage.me is a better brand name
Technical migration was done correctly
Content quality maintained
Long-term positioning improved

What I got wrong:

Underestimated Google's migration timeline
Didn't check other search engines sooner (would've panicked less)
Wasted time on directory submissions
Didn't consider that "better branding" has a 6-12 month SEO tax

The real lesson:

ChatGPT gave me branding advice when I needed SEO + business context advice.

For a bootstrap SaaS dependent on organic traffic, throwing away established rankings has a cost — even when done correctly.

The question I should have asked: "Can I afford 6-12 months of reduced Google traffic?"

AI Search Engines - The Mixed Results:

Perplexity.ai:

When asked about status pages, Perplexity listed statuspage.me alongside Status.io, Atlassian Statuspage, and UptimeRobot, highlighting "Multi-region checks, OSS-friendly."

ChatGPT:

Cites my blog post "What Is a Status Page?" when people search for status page information.

Gemini (Google's AI):

When I explicitly asked about statuspage.me, Gemini provided detailed analysis, seamingly from an outdated site.

But notably: When asked for general recommendations, Gemini suggested Better Stack, UptimeRobot, and Instatus - not statuspage.me.

The takeaway: AI search engines are discovering statuspage.me (Perplexity, ChatGPT), but Google's own AI (Gemini) still defaults to more established brands. The same pattern as Google Search itself.

What This Means For You

If you're considering a domain migration:

✅ Do migrate if:

You have multiple traffic sources (not just SEO)
The new domain is significantly better for branding
You can afford 6-12 months of reduced Google traffic
You're patient and have runway

❌ Don't migrate if:

Google organic is your primary traffic source
You're pre-launch or early stage
You need immediate results
Current domain is performing well

If you're in the middle of a migration:

Don't panic if Google rankings drop
Check Bing/DuckDuckGo - they recover faster
Monitor Google Search Console for migration status
Keep 301 redirects in place for at least 12 months
Continue publishing quality content
Skip the directory submissions - focus on real content

What I'm Doing Now (4 Months In)

The current state:

DuckDuckGo: Page 1 rankings ✅
Bing: Page 1 rankings ✅
ChatGPT: Content being cited ✅
Google: Slowly climbing back ⏳

Example links:

Active strategies:

Building in public on X (@IT_mafija)
Writing technical content on dev.to (previous posts)
Direct outreach to indie hackers and OSS projects
Long-tail SEO for less competitive keywords
IndexNow integration - Auto-submitting new/modified pages

On the IndexNow implementation:

About a month ago, I added IndexNow to my internal tooling. It detects new blog posts, docs, and page updates, then (with my approval) submits them to Bing, DuckDuckGo, and Yandex.

Google doesn't support IndexNow - they rely on crawling and sitemaps.

This gives Bing/DuckDuckGo a structural advantage: I can tell them immediately when content changes, rather than waiting for their next crawl.

It's a small thing, but it compounds. Fresh content gets indexed in hours instead of days.

Practical Takeaways

For domain migrations:

Google takes 6-12 months - this is normal, even with perfect execution
Bing/DuckDuckGo process migrations 10-20x faster
Different search engines = different algorithmic priorities
Check ALL search engines, not just Google
IndexNow helps Bing/DDG (but Google doesn't support it)

For bootstrap founders:

"Better branding" has a real SEO cost
Directory submissions are vanity metrics
One quality blog post > 50 directory links
Content that gets cited by ChatGPT = new distribution channel
DuckDuckGo/Bing traffic is real (especially from tech-savvy users)

For anyone asking AI for advice:

Specify your constraints (bootstrap, SEO-dependent, timeline)
Ask for business context, not just branding advice
AI doesn't understand your specific situation
Get multiple perspectives before big decisions

The Uncomfortable Truth

Most domain migration guides focus on technical execution.

They assume all search engines behave the same way.

They don't.

Google's 6-12 month timeline is real, documented, and unavoidable - even when you do everything right.

If you're dependent on Google traffic and can't afford that gap, the "better domain" might not be worth it.

But if you can weather the storm, the long-term brand positioning might justify the short-term pain.

I'm 4 months in. Ask me again in 12 months.

Building StatusPage.me - status pages + monitoring for indie hackers.

The domain migration journey continues. Follow along: @IT_mafija | statuspage.me

Removing Third-Party Dependencies Made My Status Page Faster (Here’s How)

Nikola — Wed, 11 Feb 2026 09:53:43 +0000

When I wrote about why a status page shouldn’t depend on third-party CDNs, the immediate response was predictable:

“Sure, but CDNs are faster.”

That assumption is so common it rarely gets tested. So I tested it.

I removed all third-party runtime dependencies from my status pages.

Nothing broke.

Performance improved — materially.

Not because of a trick, but because I removed architectural friction.

Fewer requests
Smaller payloads
More predictable render behavior
Lower TTFB

To make this concrete:

Europe TTFB dropped from ~3s to ~181ms
America dropped to ~530ms
Asia Pacific dropped to ~861ms
JavaScript bundle shrank from ~1MB to ~45KB

Europe benefited the most because it’s closest to the primary infrastructure. Other regions are still bounded by geography.

What changed wasn’t physics.
It was server-side inefficiency.

The architectural bottlenecks are gone.

What Didn't Change

Geography still matters.

Layered caching removes server-side bottlenecks.
It does not remove physical distance.

The goal wasn't to beat latency physics.
It was to remove unnecessary self-inflicted delays.

This isn’t an anti-CDN rant. CDNs are incredibly useful for many workloads. But a status page is not “many workloads.” It’s a very specific type of system with very specific goals.

What Comes Next

Layered caching removed most self-inflicted latency.

What remains is mostly geography.

The next step is introducing read-only replicas in additional regions to reduce cross-region database round-trip time.

Caching removes unnecessary work.
Regional replicas reduce distance.

They solve different problems.

Layered caching made the system efficient.
Replicas will make it geographically closer.

They’re complementary, not interchangeable.

How I Actually Sped It Up

There wasn’t one magic change. I removed a chain of small delays.

The biggest wins came from:

Letting Caddy handle more of the boring HTTP work (compression + headers)
Layered caching (browser → Redis → in-process → filesystem)
Shrinking what the browser downloads and executes

The result wasn’t just better synthetic metrics. It felt faster.

Before these changes, the cache hit rate was effectively 0% and the performance grade reflected that. After introducing layered caching and proper HTTP policies, repeated requests became dramatically cheaper.

a screenshot of https://status.statuspage.me test results

1. Caddy Tuning: Compression + Explicit Cache Policy

Caddy is great out of the box. But status pages are perfect for aggressive HTTP fundamentals.

example.com {
    encode zstd gzip

    # HTML: short-lived or revalidated
    @html path / /status* /incidents* /history*
    header @html Cache-Control "public, max-age=0, s-maxage=30, must-revalidate"

    # Fingerprinted assets: cache "forever"
    @assets path /assets/* /static/*
    header @assets Cache-Control "public, max-age=31536000, immutable"

    file_server
}

Most of my pages behave like “mostly static + occasional updates.”

So HTML is short-lived. Assets are immutable.

That alone reduced repeat downloads to near-zero.

2. Static Files: Make Repeat Visits Cheap

If fonts, icons, JS bundles, and CSS aren’t cached hard, you pay the same cost on every visit.

@fonts path /fonts/* /assets/fonts/*
header @fonts Cache-Control "public, max-age=31536000, immutable"

@images path /img/* /assets/img/*
header @images Cache-Control "public, max-age=604800"

Static delivery is the cheapest request your server can handle.
Ideally it never reaches the app at all.

After fixing headers, repeat-view performance improved dramatically.

3. Redis: Cache Expensive Shared Computations

Redis wasn’t about caching everything.

It was about preventing repeated fan-out queries:

Region summaries
Uptime aggregates
Incident rollups

key := "status:public:v1:region_summary"
if v, ok := redis.Get(ctx, key); ok {
    return v
}

data := computeRegionSummaryFromDB(ctx)

// TTL + jitter to prevent stampedes
ttl := 30*time.Second + time.Duration(rand.Intn(10))*time.Second
redis.Set(ctx, key, data, ttl)

return data

Redis acted as a shock absorber between traffic spikes and the database.

Short TTLs. Shared expensive work cached. Fresh enough, stable enough.

4. In-Process Cache: Stop Hitting Redis for Ultra-Hot Keys

Once Redis is in place, the next bottleneck can be Redis itself.

For ultra-hot keys, a tiny in-memory cache helps.

if v, ok := memCache.Get(key); ok {
    return v
}

v := redisOrDB()
memCache.Set(key, v, 2*time.Second)
return v

It’s a small change, but shaving a few milliseconds off thousands of requests per minute adds up.

5. Filesystem Cache: Serve Pre-Rendered Output

For the hottest pages, I cached rendered artifacts on disk.

Conceptually:

Render final HTML
Write to disk with version/timestamp key
Serve directly when fresh
Regenerate in background when stale

Sometimes “read file and return it” beats “query + render + serialize.”

6. HTTP Revalidation: Cheap Refreshes (304 > 200)

Even when HTML can’t be cached long-term, refreshes can still be cheap.

Short-lived HTML + ETag / Last-Modified means many refreshes become:

304 Not Modified

That’s huge during incidents when users refresh constantly.

7. Asset Minification + Smaller Hydration Surface

I treated asset size like a performance budget.
The JavaScript bundle alone went from ~1MB to ~45KB after removing unnecessary hydration and minifying aggressively.

Minified JS/CSS (Terser)
Removed unused CSS
Compressed with zstd/gzip
Cached fingerprinted assets as immutable

And most importantly:

I reduced client-side hydration.

Status pages are content-first.
They don’t need SPA-level JavaScript.

If the page works without JavaScript, it’s already fast.
Then you add JS only where needed.

The Layered Caching Model

What I ended up with:

Browser cache for immutable assets
Short-lived HTML + revalidation
Redis for shared expensive reads
In-process cache for ultra-hot keys
Optional filesystem cache for rendered artifacts

Each layer reduces work for the layer beneath it.

That’s why the gains stack instead of overlapping.

The Takeaway

For many systems, third-party CDNs absolutely make sense.

For incident communication paths, control often beats theoretical edge distribution.

Removing third-party runtime dependencies did not hurt performance.

It removed hidden latency.
It reduced the failure surface.
It improved repeat-visit behavior.

For status pages, predictability beats theoretical edge performance.

If a status page exists for when things break, it should be built like things will break.

Why a Status Page Should Not Depend on Third-Party CDNs

Nikola — Sun, 08 Feb 2026 12:52:07 +0000

Update: I ended up self-hosting all assets. Nothing broke. Performance improved. ~~Follow-up coming.~~ Follow-up:

https://dev.to/dragstor/removing-third-party-dependencies-made-my-status-page-faster-heres-how-4a17

A status page exists for exactly one reason:

to be reachable when everything else is broken.

And yet, a surprising number of status pages depend on the same third-party infrastructure that often causes the outage in the first place.

This isn’t a theoretical problem. It’s an architectural contradiction.

TL;DR (for busy engineers and founders)

Status pages are critical infrastructure, not marketing assets
Third-party CDNs (including major ones) do have global outages
When a CDN fails, status pages that depend on it often fail silently
A 200 OK page that doesn’t render correctly destroys trust
Fewer dependencies > better incident communication
Boring, self-hosted, dependency-light status pages outperform pretty ones during real outages

If your status page can go down during an incident, it’s not doing its job.

Let’s talk about why relying on third-party CDNs for status pages is a bad idea, what breaks in practice, and which tradeoffs are usually swept under the rug.

Real Recent Outages (2025–2026)

CDNs and edge providers occasionally fail, often in dramatic fashion:

Cloudflare global outage - November 18, 2025

A faulty configuration change caused widespread HTTP 5xx errors across Cloudflare’s network, impacting services such as ChatGPT, X (Twitter), Spotify, and others.

https://www.forbes.com/sites/kateoflahertyuk/2025/12/05/cloudflare-down-new-outage-takes-internet-down-again/
Cloudflare outage - December 5, 2025

Less than three weeks later, another Cloudflare incident affected roughly 28% of all HTTP traffic served by its network due to internal system failures.

https://blog.cloudflare.com/5-december-2025-outage/
Secondary impact on monitoring and reporting tools

During these outages, even third-party outage trackers struggled because they relied on the same CDN infrastructure.

https://deployflow.co/blog/cloudflare-outage-explained/

These weren’t cyberattacks. They were internal misconfigurations and cascading failures that propagated globally because of shared infrastructure.

AWS CloudFront outage - February 10, 2026 Amazon CloudFront suffered a global incident affecting DNS resolution and propagation of configuration changes. Some distributions returned NXDOMAIN, and any changes to CloudFront configs or even creation of new distributions were delayed for hours. Cache invalidations still worked, but that didn’t help teams trying to ship fixes during the outage.

https://thenightly.com.au/society/technology/aws-outage-update-amazon-web-services-cloudfront-experience-global-outage-operation-issue-c-21597705

In short: if your app or status page depended on CloudFront, you might have been up, but unable to change or recover anything when it mattered most.

The Core Paradox

When users visit your status page, something has already gone wrong.

Their app doesn’t load.

Their API calls fail.

Their team chat is on fire.

Now add this to the mix:

Your main app is down
Your CDN is degraded or unreachable
Your status page is… also unreachable

You’ve created a single point of communication failure.

At that moment, the status page isn’t merely useless.

It actively increases frustration, support tickets, and distrust.

“But CDNs Are Highly Available”

Usually.

Until they aren’t.

CDNs can fail in inconvenient ways:

DNS resolution issues
Regional routing failures
TLS or certificate problems
Cached error pages that refuse to expire
Partial outages that affect “only some users”

And when CDNs fail, they often fail globally, loudly, and at exactly the wrong time.

A status page should not share blast radius with:

Your main application
Your analytics stack
Your marketing site
Someone else’s JavaScript experiment

The Silent Failure Mode Nobody Talks About

Here’s the one that causes the most damage.

Your status page responds with 200 OK, but:

External CSS doesn’t load
Fonts time out
JavaScript never arrives

What users see:

Unstyled text
Blank screens
Infinite loading indicators

What support teams hear:

“It works for me.”

What users think:

“They’re hiding something.”

Trust dies quietly here.

Incident Communication Is a Critical Path

During an incident, your status page becomes critical infrastructure.

It is not:

A marketing surface
A design showcase
A frontend playground

Its job is brutally simple:

Load fast
Load reliably
Say something truthful

Every external dependency increases the chance that it fails at the exact moment you need it most.

“Self-Hosting Everything Is Overkill”

It isn’t. It’s an intentional constraint.

Self-hosting forces discipline:

Smaller payloads
Fewer scripts
Fewer fonts
Fewer clever ideas

A status page does not need:

Five font weights
Client-side hydration
A/B testing
Analytics beacons firing during outages

It needs to render. Period.

The Tradeoffs (Because Yes, They Exist)

Avoiding third-party CDNs means:

You handle asset delivery yourself
You lose some edge caching convenience
You think about cache headers and invalidation
You accept “good enough” over perfect Lighthouse scores

Ask the real question:

Do you want your status page optimized for benchmarks, or for reality?

A Simple Rule of Thumb

If a dependency can fail as part of the same incident you’re communicating about, it should not be required for your status page to load.

That includes:

CDNs serving your status page assets
External analytics
Third-party fonts
Tag managers
Anything that blocks rendering while phoning home

Your product may depend on shared infrastructure.
Your status page should not.

Assume the outage affects more than just your app. Design accordingly.

The Uncomfortable Truth

Most status pages are designed for calm days, not bad days.

They look great in screenshots.

They demo well.

They fail quietly when they matter most.

A status page should be boring, resilient, and slightly paranoid.

That’s not a flaw.

That’s the point.

I’m building StatusPage.me around this exact constraint: incident comms that don’t collapse when edge networks do.