Cloudsteading
Queue #5
Waiting for votes

Statuspage on Cloudflare

Public status pages, incidents, components, subscribers, and notifications on Cloudflare.

replaces Statuspage D1 Email Workers KV Queues Workers
Statuspage logo
would replace
Statuspage · status

Hosted public status pages and incident communication.

How it would work

A URL goes in, an API-ready result comes out. These are the stages the request flows through.

  1. map 01

    Map the rented workflow

    Identify the small-team job that actually needs replacing.

  2. build 02

    Assemble the Cloudflare loadout

    Pick the primitives that cover the core data, compute, auth, and delivery path.

  3. ship 03

    Publish the useful version

    Release a deployable build with limits, setup notes, and maintenance tradeoffs.

Concrete jobs it does

If you're paying Statuspage for any of these, the proposed build would let you stop.

  • → Cover the small-team workflow people actually rent the SaaS for
  • → Expose a simple, deployable API
  • → Persist the right data in D1 and the right artefacts in R2
  • → Stay maintainable by one or two engineers

Config knobs

What you'll be able to tune from day one.

Workflow scope
core team workflow only
Deployment target
Cloudflare Workers + supporting primitives
Access model
simple auth and admin controls
Limits
documented scale and maintenance boundaries
proposed architecture

The Cloudflare loadout, wired together.

Architecture

Public interface
Surfaces 1
browser
first-party clients
↓
App
Workers
entry
request handler
↓
what each tool does
Cloudflare feature
D1 tool 01
D1

Track crawl jobs, pages, status, users, limits, and API keys.
Email Workers tool 02
Email Workers

Use Email Workers for the part of the owned app that needs this platform capability.
KV tool 03
KV

Cache settings, lightweight metadata, and fast lookup tables.
Queues tool 04
Queues

Fan out background jobs so crawls can retry and continue after the first request.
Workers tool 05
Workers

Public API, routing, auth checks, rate limits, and orchestration glue.
will build
  • + The core workflow small teams actually use every week.
  • + A deployable Cloudflare-native version with clear setup steps.
  • + Basic auth, data storage, admin screens, and operational visibility.
  • + A writeup that explains the useful limits and maintenance burden.
will not build
  • - A pixel-perfect clone of the SaaS being replaced.
  • - Enterprise governance, compliance guarantees, or managed support.
  • - Every advanced feature that only large teams need.
  • - A promise that replacing the rented tool is always the right call.
readme

Statuspage on Cloudflare

This candidate asks whether Statuspage can be replaced by a smaller owned workflow on Cloudflare without pretending to cover the whole enterprise product.

What this is

Status pages are mostly static public publishing plus a small incident workflow.

How we would build it

Use D1, Email Workers, KV, Queues, Workers to cover the core workflow without adding rented infrastructure.

The honest limit

Excellent for small public products and internal tools. It will not match every enterprise subscriber workflow, SLA report, or Atlassian integration.