Every project is evaluated across 8 weighted signals pulled from the GitHub GraphQL API. The signals are combined into a single score from 0 to 100, then mapped to a human-readable verdict.
How recently the default branch received a commit. This is the strongest indicator that someone is actively working on the project.
| Recency | Score |
|---|---|
| Within 7 days | 100 |
| Within 30 days | 80 |
| Within 90 days | 60 |
| Within 180 days | 40 |
| Within 1 year | 20 |
| Over 1 year ago | 0 |
Source: defaultBranchRef.target.history
When the most recent release or tag was published. Regular releases indicate a project that ships to users, not just commits to main.
| Recency | Score |
|---|---|
| Within 30 days | 100 |
| Within 90 days | 75 |
| Within 180 days | 50 |
| Within 1 year | 25 |
| Over 1 year ago | 0 |
Source: releases(last: 1)
Median age of recently updated pull requests. Fast PR turnaround means the maintainers are engaged and the contribution workflow is healthy.
| Median PR Age | Score |
|---|---|
| Under 3 days | 100 |
| Under 7 days | 75 |
| Under 30 days | 50 |
| Under 90 days | 25 |
| Over 90 days | 0 |
Source: pullRequests(first: 50, orderBy: UPDATED_AT)
Median age of the last comment on open issues. Low staleness means maintainers are triaging and responding to bug reports and feature requests.
| Median Comment Age | Score |
|---|---|
| Under 7 days | 100 |
| Under 30 days | 75 |
| Under 90 days | 50 |
| Under 180 days | 25 |
| Over 180 days | 0 |
Source: issues(first: 50, states: OPEN, orderBy: UPDATED_AT)
Number of unique authors who committed in the last 90 days. More contributors means the project isn't dependent on a single person's availability.
| Contributors (90d) | Score |
|---|---|
| 10 or more | 100 |
| 5 – 9 | 75 |
| 2 – 4 | 50 |
| 1 | 25 |
| 0 | 0 |
Source: defaultBranchRef.target.history (since: 90d ago)
Percentage of commits from the top contributor. If one person wrote 95% of the code, the project is at risk if they step away.
| Top Contributor % | Score |
|---|---|
| Under 50% | 100 |
| 50% – 70% | 75 |
| 70% – 85% | 50 |
| 85% – 95% | 25 |
| Over 95% | 0 |
Source: Calculated from commit author distribution
GitHub star count as a proxy for community interest. Low weight because stars are a vanity metric — popular ≠ maintained.
| Stars | Score |
|---|---|
| 1,000+ | 100 |
| 500 – 999 | 75 |
| 100 – 499 | 50 |
| 10 – 99 | 25 |
| Under 10 | 0 |
Source: stargazerCount
Multi-factor assessment of CI/CD health. Checks for workflow file presence, recency of last run, run frequency in the last 30 days, and success rate of recent runs.
| Factor | Max Points |
|---|---|
| Workflows present | 30 |
| Last run within 7 days | 30 |
| 30+ runs/month | 20 |
| 90%+ success rate | 20 |
Source: object(expression: ".github/workflows") + REST /actions/runs
The weighted score maps to one of five verdicts:
Results are cached to avoid excessive API calls and to keep responses fast. Cache TTLs depend on your API tier:
| Tier | Fresh TTL | Stale TTL |
|---|---|---|
| Free (no key) | 24 hours | 48 hours |
| Free key | 24 hours | 48 hours |
| Pro key | 1 hour | 2 hours |
| Enterprise key | 15 minutes | 30 minutes |
During the stale window, you'll receive the cached result immediately while a background refresh runs. After the stale window, a fresh fetch is triggered synchronously.