StatusBeam

StatusBeam is an open-source status page generator modeled on upptime, with a YAML config, badges and a public JSON API. Checks run on Cloudflare Cron Triggers instead of GitHub Actions. Results are stored in D1 and KV, so the page never calls the GitHub API from visitors' browsers.

A single status.config.yml lists what to watch. HTTP checks derive up, degraded or down from the status code and response time. Other check types mirror an Atlassian Statuspage or incident.io page, take Sentry Uptime results through a webhook, or read the model health that the Vercel AI Gateway or OpenRouter publish, without spending tokens. The page follows the Statuspage layout: an overall banner, grouped component rows with status pills, 90-day uptime bars, response-time graphs and an incident timeline that moves through Investigating, Identified, Monitoring and Resolved. It is translated into English, Simplified Chinese, Japanese and Korean, and ships with light and dark themes. Each deployment also serves shields.io-compatible badge endpoints, a JSON status API, and RSS and Atom feeds of the incident history. Slack and generic webhook notifications go out when a status changes. An install is two Workers. The check Worker runs on a cron trigger, every five minutes by default, writes time-series rows to D1 and the current snapshot to KV, and accepts inbound provider webhooks. The status page is an Astro app on Workers that reads the same D1 and KV data behind Workers Cache. The check Worker can purge cached pages by tag the moment a status flips. Notifications can optionally run through Cloudflare Queues for retries. StatusBeam is installed as a package rather than a fork. The create-statusbeam command scaffolds a small project with status.config.yml, two wrangler files and a GitHub Actions deploy workflow, and the app code arrives as versioned dependencies. Upgrading is statusbeam update followed by statusbeam deploy.

Built for: Teams and solo developers who want a self-hosted status page with uptime history on their own Cloudflare account

What you can use it for

• Publish a public status page for a website and its API
• Show vendor status pages next to your own checks
• Add uptime and response-time badges to a README
• Get Slack alerts when a monitored service goes down
• Move off an upptime setup that hits GitHub API rate limits

Deploy

• CLI

  Branch main

  statusbeam setup provisions D1 and KV, asks for a custom domain and cron schedule, writes the IDs into both wrangler files, applies the schema, uploads status.config.yml and deploys both Workers. It is idempotent, so re-running it is safe.

  bunx create-statusbeam my-status
  cd my-status
  bunx wrangler login
  bun install
  bunx statusbeam setup

  Copy
  Docs

A scaffold command and statusbeam setup provision D1 and KV and deploy both Workers. The cache-purge token, a custom domain and Slack webhooks are optional extras.

What it needs to run

• D1 databasesstatusbeam
• KV namespacesSTATUS_KV

Good to know

Under active development: TCP and SSL checks currently fall back to HTTP, and email notifications have not shipped. The CLI flow uses Bun (bunx and bun install). Near-instant updates need CF_API_TOKEN and CF_ZONE_ID secrets for cache purging; without them the page can trail a status change by up to 60 seconds. Private pages need Cloudflare Access on a custom domain, with the workers.dev URL turned off in wrangler.web.jsonc; re-running statusbeam setup turns it back on. Until the first cron run writes a snapshot, the page shows bundled sample data.

Cost on Cloudflare

Where this comes from

• Repositoryhttps://github.com/pleaseai/statusbeam
• App websitehttps://docs.statusbeam.dev
• Demohttps://demo.statusbeam.dev
• App websitehttps://docs.statusbeam.dev/
• Documentationhttps://docs.statusbeam.dev/getting-started/introduction/