How health is computed

Upstar ranks repositories by how fast they gain stars. Health signals add a second, separate question: is the project actively maintained? They help tell a rising, maintained project from short-lived hype. They are factual, computed automatically from public data, and never a guarantee.

Levels

  • Healthy: a health score of 70 or more.
  • Mixed signals: from 40 to 69.
  • Low activity: under 40.
  • Too new to assess: repositories less than 60 days old, or with fewer than 10 commits. Rising repositories are often new; they are not penalised for a short history.
  • Archived: the owner archived the repository on GitHub. It is always flagged, whatever its score.

Components and weights

The score goes from 0 to 100. Each component gives 0 to 1, multiplied by its weight. When a component cannot be measured, it is left out and the other weights are scaled up, so missing data never counts as bad.

  • Activity regularity (30%): the number of the last 13 weeks with at least one commit by a person on the default branch. Commits by automation are left out: accounts ending in [bot] (Dependabot, Renovate…), commits authored or committed by GitHub Actions, sync bots that use ordinary accounts (such as gVisor’s), git identities with no GitHub account whose name or email says bot, robot, automation, copybara or sync, and commits an app wrote through GitHub’s web flow. Commits in 10 weeks or more gives the full value.
  • Maintainers and bus factor (20%): how many people (automation left out, as above) committed among the last 100 commits of the past 90 days (one person 0.4, two 0.7, three or more 1), and how much of the work rests on the most active one (50% or less is fully spread, 100% is none). With fewer than 20 commits in the window this component is scaled down in proportion: a handful of commits says little about who maintains a project.
  • Issue responsiveness (20%): the median time until a maintainer (the owner, an organisation member or a collaborator) first comments on an issue opened by someone else in the last 90 days, from a sample of the latest 50 issues. Comments by bots never count, whatever their role: GitHub Actions, Dependabot, Renovate, stale bots and any account ending in [bot]. Issues still waiting count with their current age; issues closed without a maintainer comment (by their author or a stale bot) are left out. A day or less gives the full value, 30 days or more none. A quarter of this component is the share of those issues that are closed. With fewer than 3 such issues it is unknown.
  • Release cadence (10%): GitHub releases published in the last 12 months (one 0.5, two or three 0.75, four or more 1). Projects that never publish GitHub releases are not judged on this.
  • Project hygiene (20%): a license (35%), continuous integration (35%: GitHub Actions workflows or another CI configuration), a security policy (15%) and, when the project has been scanned, its OpenSSF Scorecard score (15%).

Also shown, not scored

  • Pull requests opened, merged and closed in the last 90 days (latest 50).
  • The OpenSSF Scorecard score with a link to the full report. A project that was never scanned is unknown, not bad.

Limits

  • Signals are collected once a week for repositories ranked in at least one topic, so they can be a few days old. The date of the last check is shown on each repository page.
  • Counts come from samples (the latest 100 commits, 50 issues, 50 pull requests and 50 releases). When a sample is full, the real number may be higher.
  • Branch protection is not visible with public access, so it is not part of the score.
  • Work outside GitHub (other forges, mailing lists, private chats) is invisible here.
  • A healthy project can still have bugs or security issues, and a quiet one can be finished and stable. Read the code and the project’s own documentation before you depend on it.