Cloudflare Build Badge

Overview

Cloudflare Build Badge is an open-source Worker that generates SVG badges showing the build status of any repository deployed with Cloudflare Workers Builds. It’s meant to drop into GitHub READMEs or websites, with no setup required in the target repository.

I built and maintain it alone. The service is live and open for anyone to use, though for now I’m the only regular user — a niche tool from June 2026 that exists because I needed it.

Context

GitHub ships native status badges for GitHub Actions, but not for Cloudflare Workers & Pages checks. Most of my sites run on Cloudflare Workers, so READMEs were missing that simple “last deploy passed or failed” signal.

There wasn’t a large product gap — just the annoyance of not having the same badge pattern I already use everywhere else.

Why

The real trigger wasn’t badges in the abstract. I was building eminence-astro-starter, an Astro starter aimed at Cloudflare Workers deploys, and I didn’t want to ship that template without a credible build badge in the README.

Cloudflare Build Badge exists to unlock that project (and the rest of my Workers repos) with the familiar Shields.io embedding pattern.

Approach

Every badge request does four steps at the edge: hit the Worker, query the GitHub Checks API for the latest Cloudflare Workers & Pages check on the requested branch (or the default), map that status to a Shields.io badge, and return the SVG. The URL is re-evaluated on each request, so the badge stays current without a separate update job.

URL shape is /{username}/{repository}/status.svg, with an optional branch segment. Any Shields.io query parameter (style, logo, colors, cache) is forwarded; status color and message are computed by the Worker.

I also shipped it as a deployable Astro template: copy it, set your domain, add a read-only GITHUB_TOKEN, and run your own instance.

Stack

Astro 7 SSR on Cloudflare Workers: marketing site and badge endpoint on the same edge runtime.
Svelte 5: badge configurator UI.
TypeScript and Tailwind CSS 4: strict typing and site styling.
Cloudflare Workers: runtime and continuous deploy via Workers Builds.
Shields.io and the GitHub Checks API (body-only): badge rendering and status source of truth.

Challenges

The Checks API paginates results; I had to walk that pagination carefully so the badge didn’t latch onto a stale or wrong check.

Relying on Shields.io adds an external failure point, in exchange for styles people already recognize. I took that trade-off deliberately.

When the failure is Shields itself (or another service-side error), I couldn’t call Shields again to render the error state — so those cases fall back to stored SVGs that still return a usable badge image.

Impact

Impact today is personal and small: I can put real Workers build badges on my READMEs. The project is MIT and public; anyone can use the live instance or deploy their own. There’s no adoption metrics yet — and I’m not inventing any.

Lessons

For a thin edge service, “depend on Shields vs. draw every SVG myself” matters more than it looks: style drives familiarity, but you still need a plan B when the external renderer fails.

Next time I’d treat Checks pagination and badge error states as design inputs up front, not late patches.