How we built a status page service on Cloudflare

I wanted status pages as a native feature in Ampliflare from the start. The constraint was working with Cloudflare’s primitives and keeping it lean. You can’t bolt on a traditional status page service — that model requires central databases and cronjobs that don’t fit. So I had to design something that worked within what Cloudflare actually offers.

The simple approach doesn’t work

One server with a cron loop. Every check gets written to the database. One monitor checking every minute generates about 43k rows a month — fine for one person. Add multiple customers and you’re either paying a lot for database writes or batching things in ways that slow down the status page exactly when you need it: during an actual outage.

What we actually built

One Durable Object per monitor. Each monitor manages itself and schedules its own checks using Cloudflare’s alarm() API. No central polling. Raw results stay in the DO’s own embedded SQLite — they never touch the main database while the check is running. This was the key decision. You get isolation per monitor, everything runs in parallel, and no database lock contention.

Main database writes are rare by design. D1 only gets written when a monitor changes state — up to down, down to up. Once a day we write a rollup: uptime %, average and p95 latency, total downtime. Raw history gets compressed to NDJSON and stored in R2.

Edge caching the public page is load-bearing, not optional. Status pages are read-heavy with rare writes, but traffic spikes hard during incidents. A 30-second cache at the edge means thousands of visitors hit the database once instead of thousands of times. Without it, a high-profile outage could take down the status page announcing it.

Custom domains were the hardest part. Cloudflare for SaaS can auto-provision TLS for customer domains (status.yourcompany.com), but a catch-all Worker route blocks everything else on the same zone. If we put custom hostnames on ampliflare.com, they’d conflict with our own subdomains and staging. The solution: a completely separate zone just for customer domains. There’s nothing else on it, so a catch-all is safe. Customers point a CNAME and the cert provisions automatically.

Stack: Workers, Durable Objects, D1, R2, Hono, Astro, React, Drizzle. No servers to manage.

---

If you want this without building it, it’s shipped as Ampliflare. Add a monitor, attach it to a status page, optionally point your domain at it.