[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:

@KubiGR, you are correct that the subscribers_count field is only returned in the detailed representation returned by the “Get a repository” endpoint, but not in the summary representation returned by the “List forks” endpoint.

@payne911 you are correct that the GraphQL API might be a solution here, for example:

 repository(name: "useful-forks", owner: "jkunstwald") {
   forks(first: 100) {
     nodes {
       watchers {


  "data": {
    "repository": {
      "forks": {
        "nodes": [
            "stargazerCount": 19,
            "watchers": {
              "totalCount": 3
        "totalCount": 1

which I think is what you’re looking for?

What I am trying to achieve is obtaining the basic information with a single API call:

  1. Stars
  2. Watchers
  3. Forks

You can take a look at this diagram I made to represent the inner-workings of my project: https://github.com/useful-forks/useful-forks.github.io/blob/1f52464617847c25eed26c84c24e924e1ef910d1/media/query-diagram.png

Each blue box represents an API call. Due to the restrictions in the amount of calls one can make, I want to minimize this. As it is, I would need one extra blue box in this diagram just to obtain the amount of watchers, and that is what I am trying to avoid.

I have never worked with GraphQL so it’s a bit hard for me to know if it would actually solve my problem.

Is it me or the GET Forks endpoint now returns subscribers_count ?

Or at least, it does according to the documentation (but not according to my code): Repositories - GitHub Docs