StatusPage.me

First paid customer.

Not overthinking it.

Just a good reminder that:

• Someone had a real enough problem to pay for a solution.

Now the focus is simple:

• Figure out how to make that happen again.

Yesterday, someone ran unauthorized security testing against StatusPage.me: scripted registrations, XSS payloads in form fields, and password reset abuse.

They didn’t get in. But they did trigger two real bugs: a couple of endpoints returned 500s where they should’ve returned 404s.

That was enough to push me into something I’d been postponing: a full OWASP Top 10 pass.

What I fixed (high level):

• 500→404 for missing records + sanitized error responses

• added rate limiting for login + forgot-password

• shortened admin JWT lifetime (30d → 4h)

• removed debug logs that could leak sensitive session/JWT info

• fixed 2FA backup code invalidation after use

• locked down webhook URL validation (SSRF hardening across all channels)

• added missing security headers globally

A new feature fell out of this:

✅ Domain-level registration blocklist (stored in Postgres + manageable via admin UI).

IP blocks are easy to rotate. Domains are stickier.

Takeaways for other founders:

1. "The attack failed" ≠ "no bugs"

2. Ship defense-in-depth, then audit anyway

3. Block abusive domains, not just IPs

4. Log hygiene in prod is a quiet liability

5. Short admin sessions cost almost nothing and reduce blast radius

Incident closed. Codebase better. Back to building. 🧑🏻‍💻

What’s your "minimum security checklist" before you ship a new SaaS feature?

I moved 19 third-party JS/CSS libraries off external CDNs and now serve everything from my own domain at runtime.

This wasn’t because a CDN broke on me. It was mostly three boring reasons that compounded over time:

• Performance: fewer third-party DNS/TLS handshakes and more predictable loads

• Privacy: no surprise third-party requests on a status page

• Fewer runtime dependencies: during incidents, I want as few external calls as possible

Implementation was mostly asset bundling + cache headers/versioned filenames.

Curious: Do you still rely on public CDNs in production, or do you self-host everything?

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

I've decided to give the project a fresh start and show it some love!

I had to put it on hold for the past four years (because my previous job didn't allow any side projects, etc.) and basically let it go.

But guess what? The domain remains on the first page of all major search engines (thanks to hostedstatus.page), which will be a significant boost for traffic.

Stay tuned for more updates soon!