I already posted an update thread on X here: https://x.com/getStatusPage/status/2011183559055126739
Posting the core highlights here too, so this IndieHackers page reflects what’s actually happening.
🚀 What was shipped until then:
Privacy/security wins (privacy-first defaults)
Fully self-hosted runtime assets: moved 19 third-party JS/CSS libs off external CDNs → zero external CDNs at runtime
Multi-language support (🇺🇸/🇫🇷/🇷🇸/🇩🇪/العربية)
Teams feature + billing usage snapshot cards (seats/heartbeats, progress-style)
RSS + Atom feeds on every status page (/rss.xml + /atom.xml) with autodiscovery in the Subscribe modal
Ongoing blog series on status pages vs uptime monitoring, public vs private status pages, and reducing support tickets
What I’m focusing on next:
Making onboarding faster so a useful status page goes live in <5 minutes
More “boring reliability” work: avoiding false downtime during deploys/restarts, better handling of monitor data gaps
‼️ If you run a small SaaS: what’s the one feature that makes you trust a status page product (or makes you bounce immediately)?
Quick extra context: the “no external CDNs at runtime” choice was performance + privacy first, and also reducing runtime dependencies. A status page is most important during incidents, so I want as few external calls as possible.
Next, I’ll share the tradeoffs + implementation details (caching, headers, bundling).