[BUG] "watchers_count" is the duplicate of "stargazers_count"

Using the following variable to construct an URL:

const API_REQUEST_URL = 'https://api.github.com/repos/' + user + '/' + repo + '/forks?sort=stargazers&per_page=100&page=' + page_number;

I receive a list of objects which, once parsed, seem to contain an error: the amount of stars and forks is fine, but the amount of watchers is a duplicate of the amount of stars.

To reproduce, see my code: https://github.com/useful-forks/useful-forks.github.io/blob/39cd2e62d7152c57a635481f083ea92a85d42c4e/docs/src/queries-logic.js#L219

And you can get a live demo right there (it’s a tool I’ve been making to increase the discoverability of forks in GitHub): https://useful-forks.github.io/?repo=jkunstwald/useful-forks

Where do I officially report this bug?


How comes GitHub doesn’t seem to have an Issue Tracker ?

I need this bug fixed. It’s probably a single LOC which needs to be modified.

Hi there! :wave:

Thanks for reporting this! This is indeed known behavior, and it’s intentional.

This part of the API changed when we moved “watching” to “starring” many years ago and created a new meaning for “watching”. Basically, what used to be known as “Watching” is now “Starring”. Starring is basically a way to bookmark interesting repositories. Watching is now a way to indicate that you want to receive email or web notifications on a Repository.

The update to the API from this change is explained in this blog post:


The upshot is that watchers , watchers_count , and stargazers_count all correspond to the number of users that have starred a repository, while subscribers_count corresponds to the number of watchers .

Although watchers_count is obsolete, we still return both fields because we don’t want to make a breaking change for customers who were using the watchers_count field before the change.

Our team is working on making sure this is explained in the documentation, but I agree, it can be confusing.

I hope this helps!

I see. Thanks for the clarification!

I looked back into the data I receive from the API, and I do not see any subscribers_count field. Is there something I am missing? My understanding is thus that I would have to issue yet another API call to another url (the subscribers_url). (For my application, this is very limiting because requiring 3 API calls per repository (to obtain the stars, watchers, forks, commits behind and ahead) reaches the API limit very quickly: is there another way to increase that limit for a GitHub 3rd party application even more than through using authenticated requests ?)

Also, would using the GraphQL API provide a solution to my problem?

Finally, I’m assuming GitHub API v4 will bring a solution to this problem: has there been any announcements about a potential release date?

I have spotted the same problem and I can confirm that the subscribers_count field does not exist when getting a repo from the /users route, but it does exist when getting from the /repos.

For example here it exists: https://api.github.com/repos/atom/atom
and here it doesn’t: https://api.github.com/users/atom/repos

I want to use the second call but I need to call for every repo to get the watchers :frowning: