A field guide to project health scores in 2026
Every project on the GitPop radar has a 0-100 health score and a tier (healthy / slow / at_risk / abandoned). Here is how we compute it, what each tier means, and how to use it in due diligence.
Quick answer. The GitPop health score is a 0-100 measure of how "alive" a project is. The score combines four inputs — recent commits, recent issues, contributor count, and release cadence — into a single number and a tier. The tiers are: healthy (80-100), slow (50-79), at_risk (20-49), abandoned (0-19). Use the health score in due diligence: a project in
at_riskorabandonedwarrants a closer look before adoption.
Why a health score
PopScore measures momentum — how fast a project is growing. Health measures something different: how alive a project is right now. A project can have a high PopScore (growing fast) and a low health score (currently broken). The two dimensions are independent.
A concrete example: a popular JavaScript library gets a security vulnerability reported. The maintainer takes a few weeks off. The PopScore stays high (the project is still famous), but the health score drops (no recent commits, no recent releases, the issue isn't getting fixed). The radar should surface this.
The four inputs
The health score is computed from four inputs, each weighted equally at 25%:
- Recent commits (25%) — the number of commits in the last 30 days. A healthy project has at least 5-10 commits. An at-risk project has 1-2. An abandoned project has zero.
- Recent issues (25%) — the issue close rate over the last 30 days. A healthy project closes ≥ 80% of new issues. An at-risk project closes 30-50%. An abandoned project closes < 10%.
- Contributor count (25%) — the number of distinct authors with at least one commit in the last 30 days. A healthy project has 3+ active contributors. An at-risk project has 1-2. An abandoned project has zero.
- Release cadence (25%) — the days since the last release. A healthy project has released in the last 90 days. An at-risk project has 90-365 days. An abandoned project has 365+ days.
Each input is normalized to 0-100 and combined. The final score is a 0-100 number with the following tier mapping:
| Score | Tier | Meaning |
|---|---|---|
| 80-100 | healthy | Active, sustainable, ready for production |
| 50-79 | slow | Still active but slowing down |
| 20-49 | at_risk | Activity is intermittent; investigate before adopting |
| 0-19 | abandoned | No meaningful activity; likely dead |
The score is computed daily and surfaced on every project page.
What each tier means
healthy (80-100)
The project is in active development. Commits are landing, issues are being addressed, releases are shipping on a regular cadence, and the contributor base is healthy. This is the "adopt without worry" tier.
Examples: vercel/next.js, ollama/ollama, huggingface/transformers, meilisearch/meilisearch.
slow (50-79)
The project is still active but has slowed down. Commits are landing less frequently, the issue close rate has dropped, or the contributor count has shrunk. The project is not in immediate danger, but the trajectory is concerning. Adopt with a plan to migrate if the trend continues.
Examples: many of the older JavaScript frameworks, several long-running Python libraries, and a handful of Rust tools that have stabilized after their initial growth phase.
at_risk (20-49)
The project has intermittent activity. Commits are landing occasionally, the issue close rate is low, and the contributor count has dropped to 1-2. The project is at risk of becoming abandoned. Investigate before adopting — find out why the activity has dropped, and check if there's a fork that's more active.
Examples: projects where the original maintainer has stepped back, projects with a single active contributor, and projects that have been "almost done with a major refactor" for over a year.
abandoned (0-19)
The project has no meaningful activity. No commits in the last 90 days, the issue close rate is < 10%, the contributor count is zero, and the last release was over a year ago. The project is effectively dead. Do not adopt for new work; if you have an existing dependency, plan a migration.
Examples: many older Python 2 libraries, several React Native community libraries, and a long tail of "tutorial repos" that were never meant to be maintained.
How to use the health score
For due diligence
Add the health score to your evaluation framework. The 5-minute framework in How to evaluate a GitHub project has 5 checks; the health score captures 3 of them in a single number (contributors, recent activity, release cadence). A project that scores < 50 on health should not be adopted for production without a closer look.
For tracking dependencies
Set up a periodic health check on your dependencies. The GitPop radar can be used to monitor the health of every project you depend on. A dependency that drops from healthy to slow is a yellow flag; a drop to at_risk is a red flag. Plan your migration before the project becomes abandoned.
For maintainers
If you maintain a project, the health score is a useful internal metric. The score reflects the project's "bus factor" — if a single contributor leaves, the score will drop. Track the score over time and add contributors before the bus factor becomes a problem.
The limits
The health score is not a complete picture. Some healthy-looking projects have technical debt that will bite you later. Some abandoned-looking projects are actually "feature complete" and don't need ongoing maintenance. The score is a starting point, not the final verdict.
For the full due diligence process, see How to evaluate a GitHub project and the production-ready checklist. For the broader methodology, see What is PopScore? and the methodology page.