Put a live uptime badge in your GitHub README in 90 seconds

Your GitHub README has a build badge, a license badge, maybe a Discord badge. The one badge it usually does not have is the one that tells visitors whether the thing actually works right now — uptime.

The reason is mostly practical. Most uptime tools either give you no badge at all, give you one that looks nothing like the others, or want you to wire up a webhook and a custom CDN to render an SVG. None of that fits the 30 seconds you have between writing a README and shipping the repo.

The Glimly Badge is meant to fit. It is a plain SVG served from an HTTPS URL, with a cache-control that respects GitHub camo, and no JavaScript. One line of Markdown and you are done.

Step 1 — Create a Monitor

In the Glimly dashboard, click New Monitor, paste the URL you want watched (the production endpoint of your service — https://api.acme.com/health is the usual shape), and pick an interval. Free is 5-minute, Pro is 1-minute.

Glimly probes from a real region with a real HTTP client. Two consecutive failures open an Incident — the two-strike rule means a single dropped packet does not page you in the middle of the night.

Step 2 — Create a Badge install

Open the Badges tab, click New install, and pick the Service you want the badge to reflect. You get a token like b1aRgK9c2vQp and a live preview. Pick a size (sm, md, lg) and a theme (auto, light, dark) — the install screen shows what each one looks like in real time.

The badge URL looks like this:

https://glimly.dev/b/b1aRgK9c2vQp.svg

Step 3 — Drop it in your README

GitHub renders Markdown image links by piping them through their image proxy (Camo). The Badge endpoint sets the right cache headers so GitHub fetches a fresh copy roughly every minute on Pro and every five on Free — fast enough that visitors see real state, slow enough that you are not pummeling the proxy.

[![status](https://glimly.dev/b/b1aRgK9c2vQp.svg)](https://glimly.dev)

That is the whole install. Commit, push, and the badge appears on the rendered README. It auto-adapts to GitHub light or dark mode through prefers-color-scheme.

Variations you might actually want

The Badge accepts a small set of query params, set per-install in the dashboard or overridden inline:

• ?size=sm|md|lg — three pixel sizes, all retina-friendly.
• ?theme=auto|light|dark — auto follows prefers-color-scheme where supported.
• ?label=API — a short custom label override for the service name.

For a footer pin on a marketing page, size=md plus theme=auto is the right default. For a README, size=md reads cleanly next to the standard build badges.

Why an SVG and not a JSON endpoint

A JSON endpoint plus shields.io would also work. The reason we ship a native SVG is that GitHub READMEs are not the only place people drop badges — email signatures, marketing pages with strict content security policies, and PDF docs all accept an <img> tag and reject anything that needs JavaScript. The Badge is meant to land wherever a logo would land.

A live status badge in your README sets a small but real expectation with anyone who lands on your repo. It says we know whether this is up, and we are not hiding it. That is a cheap signal of seriousness — and a fair trade for 90 seconds of setup. Try it free.