These repositories cover part of this workflow. Check their scope and hosting requirements before choosing.
By cloudsteading
Public monitor status and incident pages only; customer communication and enterprise features were not compared.
The documented installation requires Workers Paid, from $5 USD per account/month plus usage overages. No zero-cost or fixed total monthly bill is claimed.
This is a proposed build, with a conceptual architecture. Any linked existing projects have their own documented scope and infrastructure.
Browse existing projects and remaining proposals →Public status pages, incidents, components, subscribers, and notifications on Cloudflare.
Hosted public status pages and incident communication.
A URL goes in, an API-ready result comes out. These are the stages the request flows through.
If you're paying Statuspage for any of these, the proposed build would let you stop.
What you'll be able to tune from day one.
Overview inferred from the listed Cloudflare services. Routes and connections have not been verified.
Track crawl jobs, pages, status, users, limits, and API keys.
Use Email Workers for the part of the owned app that needs this platform capability.
Cache settings, lightweight metadata, and fast lookup tables.
Fan out background jobs so crawls can retry and continue after the first request.
Public API, routing, auth checks, rate limits, and orchestration glue.
This candidate asks whether Statuspage can be replaced by a smaller owned workflow on Cloudflare without pretending to cover the whole enterprise product.
Status pages are mostly static public publishing plus a small incident workflow.
Use D1, Email Workers, KV, Queues, Workers to cover the core workflow without adding rented infrastructure.
Excellent for small public products and internal tools. It will not match every enterprise subscriber workflow, SLA report, or Atlassian integration.
Discussion · 0
sign in to comment →