1
1 Comment

2026 shipping update (thread link inside)

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)?

posted toAvatar for product StatusPage.me
StatusPage.me
  1. 1

    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).