Your README shows a build status badge, a coverage badge, and maybe a license badge. None of them tell users whether the runtime they depend on has unpatched CVEs or is about to lose security support. That gap is what version health badges fill.
This guide covers what version health badges show, every badge type available, copy-paste embed snippets for Markdown, HTML, and reStructuredText, real-world examples for different project types, and how the underlying data pipeline works. By the end, you’ll have live badges in your project showing things no other badge service currently tracks.
What Version Health Badges Show
A version health badge is a live indicator that pulls data from release trackers and vulnerability databases. Instead of showing a static version number, it shows what that version means for your users right now: Is it still supported? Are there known CVEs? How fresh is the latest patch?
ReleaseRun badges combine three signals into a single grade:
- Freshness (35%): How recently the version received a patch release. Stale versions score lower.
- Security (35%): Known CVE count from the NIST National Vulnerability Database. Any critical CVE tanks the score.
- Support status (30%): Whether the version is still within its official support window. EOL versions get an F.
The result is a letter grade (A through F) that tells users everything they need in a glance:
Badge Types Available
Health grades aren’t the only badge type. Depending on what matters most for your project, you can embed any combination:
Health Badge (Overall Grade)
The composite A-F grade. Best for READMEs where you want one badge that says “this version is fine” or “this version needs attention.”
EOL Badge (End-of-Life Countdown)
Shows the exact support window remaining. Particularly useful for version comparison guides and projects that support multiple runtime versions.
Notice how the Node.js 20 badge shows “EOL in X days” — that countdown updates automatically. By the time you’re reading this, the number has changed.
CVE Badge (Vulnerability Count)
Shows the number of known CVEs for a specific version. This is the badge Shields.io can’t give you — nobody else puts vulnerability data in a badge format.
How to Embed Badges
🔔 Never Miss a Breaking Change
Get weekly release intelligence — breaking changes, security patches, and upgrade guides before they break your build.
✅ You're in! Check your inbox for confirmation.
Markdown (GitHub READMEs, GitLab, docs sites)
This is where most badges live. Drop these into your README.md:
# Version Health
[](https://releaserun.com/badges/python/)
[](https://releaserun.com/badges/python/)
[](https://releaserun.com/badges/python/)
HTML (Documentation sites, wikis, dashboards)
<a href="https://releaserun.com/badges/python/">
<img src="https://img.releaserun.com/badge/health/python.svg"
alt="Python release health" height="20">
</a>reStructuredText (Sphinx docs, Python projects)
.. image:: https://img.releaserun.com/badge/health/python.svg
:target: https://releaserun.com/badges/python/
:alt: Python release healthURL Pattern Reference
Every badge follows the same URL structure:
https://img.releaserun.com/badge/{type}/{product}.svg # latest version
https://img.releaserun.com/badge/{type}/{product}/{version}.svg # specific versionTypes: health, eol, cve
Products: python, nodejs, kubernetes, docker-engine, go, ruby, php, java, dotnet, postgresql, nginx, terraform, redis — and 300+ more from endoflife.date.
Real-World Examples
Python library supporting multiple versions
You maintain a library that supports Python 3.10 through 3.14. Add EOL badges so users see which versions are approaching end of life:
## Supported Python Versions
[](https://releaserun.com/badges/python/)
[](https://releaserun.com/badges/python/)
[](https://releaserun.com/badges/python/)
[](https://releaserun.com/badges/python/)
[](https://releaserun.com/badges/python/)
When Python 3.10 hits EOL in October 2026, the badge automatically switches from “supported until 2026-10” to an EOL warning. No PR needed — the badge updates itself.
Kubernetes operator README
You maintain a K8s operator. Show users which Kubernetes versions you test against and whether they’re still in the upstream support window:
## Supported Kubernetes Versions
[](https://releaserun.com/badges/kubernetes/)
[](https://releaserun.com/badges/kubernetes/)
[](https://releaserun.com/badges/kubernetes/)
[](https://releaserun.com/badges/kubernetes/)
Internal dashboard or wiki
Track your production stack’s health at a glance. Embed these in Confluence, Notion, or a Grafana text panel:
<div style="display:flex;gap:8px;flex-wrap:wrap;">
<img src="https://img.releaserun.com/badge/health/nodejs.svg" alt="Node.js health">
<img src="https://img.releaserun.com/badge/health/postgresql.svg" alt="PostgreSQL health">
<img src="https://img.releaserun.com/badge/health/redis.svg" alt="Redis health">
<img src="https://img.releaserun.com/badge/health/nginx.svg" alt="Nginx health">
</div>Node.js microservice with version pinning
Your team pins Node.js versions in Docker images. Add a health badge to your service’s README so anyone reviewing the repo immediately sees whether the pinned version is still safe:
## Runtime
This service runs on Node.js 22 LTS.
[](https://releaserun.com/badges/nodejs/)
[](https://releaserun.com/badges/nodejs/)
When Node.js 22 approaches EOL, the badge updates automatically. That’s one less thing to remember during quarterly planning — the badge reminds everyone who looks at the repo.
Multi-technology project
Most production systems run more than one technology. Show the health of your entire stack in one badge row:
## Stack Health
[](https://releaserun.com/badges/python/)
[](https://releaserun.com/badges/postgresql/)
[](https://releaserun.com/badges/redis/)
[](https://releaserun.com/badges/docker/)
One green row means your stack is current. A yellow or red badge means something needs attention — and you don’t need to open four different release pages to find out which.
Troubleshooting
Badge shows “unknown”: This usually means the product slug doesn’t match the endoflife.date API. Check the badges index page for the exact slug. Common gotcha: Docker is docker-engine, not docker.
Badge not updating in GitHub: GitHub caches external images aggressively (sometimes for hours). Append a cache-busting query parameter if you need fresh data: ?v=2. For most use cases, the delay is fine — version health doesn’t change by the minute.
Badge not rendering in a private repo wiki: Private GitHub wikis don’t fetch external images by default. Use the HTML embed format instead, or host the badge image behind your own proxy.
How the Data Works
Every badge request hits ReleaseRun’s badge service at img.releaserun.com. The service pulls from two upstream sources:
- endoflife.date API: Release dates, EOL dates, LTS status, and latest version for 300+ products. This is the same data source used by major cloud providers for their support lifecycle pages.
- NIST National Vulnerability Database: CVE counts per product and version. Updated every 6 hours.
Badge images are SVGs, edge-cached for 5 minutes. They load in under 50ms and add negligible weight to your page. No JavaScript required — they work anywhere <img> tags work.
How This Compares to Shields.io
Shields.io is the standard for project badges. We use it ourselves. ReleaseRun badges aren’t a replacement — they cover a lane Shields.io doesn’t:
| Feature | Shields.io | ReleaseRun |
|---|---|---|
| Version number display | ✅ | ✅ |
| Custom labels/colours | ✅ | ❌ |
| CVE count per version | ❌ | ✅ |
| EOL countdown | ❌ | ✅ |
| Composite health grade | ❌ | ✅ |
| Support window dates | ❌ | ✅ |
Use Shields.io for build status, coverage, and license. Use ReleaseRun for version health, EOL warnings, and CVE visibility. They sit next to each other in the same badge row.
Frequently Asked Questions
How often do badges update? Upstream data refreshes every 6 hours. Badge SVGs are cached for 5 minutes at the edge. You’ll see CVE count changes within 6 hours of NIST publication.
Do badges work in GitHub READMEs? Yes. GitHub’s Markdown renderer fetches and caches external SVGs. The badges render inline like any other badge image.
What products are supported? Any product tracked by endoflife.date — currently 300+. If it’s in their API, you can generate a badge for it. See all available badges.
Is there a rate limit? No hard rate limit for normal usage. Badges are designed for README rendering and documentation pages. If you’re generating thousands of requests per minute from CI, reach out.
Can I use these commercially? Yes. Badges are free for any use — open source, commercial, internal dashboards, customer-facing docs.
What if a product I need isn’t listed? If the product is tracked by endoflife.date, the badge already works — just use the product’s endoflife.date slug. If it’s not tracked anywhere, submit a PR to endoflife.date and the badge will work automatically once the product is added.
Do badges affect page load speed? Negligibly. Each badge is a single SVG under 2KB, served from an edge cache. They load faster than most analytics scripts. No JavaScript, no layout shift, no render blocking.
Can I use a specific version instead of latest? Yes. Append the version to the URL: /badge/health/python/3.12.svg instead of /badge/health/python.svg. This is useful when your project pins a specific version and you want the badge to reflect that exact version’s health.
What To Do Next
Pick the technology your project depends on most. Add one health badge to your README. That’s it — five minutes, one line of Markdown, and every visitor to your repo now knows whether your runtime is healthy.
If you maintain a library that supports multiple versions, add EOL badges for each. Your users shouldn’t have to check release schedules manually to know if their Python 3.10 is about to lose security patches.
Browse all available badges to see what’s available for your stack, or check the Node.js LTS comparison and Kubernetes EOL guide to see badges used in context on real articles.