Six Months of GitHub Issues: Is It Time for a Change?

Six Months of GitHub Issues: Is It Time for a Change?

My team has relied on GitHub for years. I started with Subversion a long time ago, later worked with GitLab and Bitbucket, and eventually chose GitHub because it felt like the most user-friendly and flexible platform for storing code, managing versions, reviewing changes, and collaborating as a team.

For a long time, we were happy with that decision. GitHub became such a natural part of our development process that we rarely had to think about the platform itself. It simply worked. For most teams and projects, there was little question about which version-control platform to use—GitHub was the default choice.

During the past six months, however, our experience has started to change. We have faced a growing number of issues—some minor, others serious enough to make us reconsider how dependent our development process should be on a single platform.

I am not writing this simply to complain. My intention is to share what our team has been experiencing and suggest a few practical improvements that could help restore confidence.

Failed subscription upgrades with no practical recovery path

One of the most frustrating situations occurred when we attempted to upgrade a project subscription to a higher plan. The upgrade repeatedly failed because of payment and processing errors.

We changed the payment method and tried again, but the result remained the same. More importantly, there was no clear fallback, rollback, or alternative recovery path that would allow us to complete the upgrade safely using the same account.

In the end, our workaround was to create new accounts and continue working through them. It allowed us to move forward, but it should not have been necessary.

I also opened GitHub Support ticket #4532111. After one week, I was still waiting for a response:

https://support.github.com/ticket/personal/0/4532111

Payment systems are a key part of any commercial product, but they are difficult to manage because they depend on many external factors, including banks, payment providers, expired cards, authorization decisions, delayed webhooks, and users updating their payment details.

That is exactly why payment flows need strong recovery mechanisms. Changing a payment method, retrying a failed upgrade, moving between plans, and recovering from a partially completed transaction are all scenarios that should be carefully tested. Even when the initial operation fails, the customer should always have a clear and safe next step.

For a platform used to manage business-critical development workflows, a billing issue should not leave a team without an actionable recovery path.

Large pull requests are becoming difficult to review on GitHub

Pull-request review is one of GitHub’s most important collaboration features. Recently, however, files containing a large number of changes have become difficult—and sometimes impossible—to review properly through GitHub.com.

As a result, members of our team have to check out the branch and review those changes locally.

There is nothing wrong with reviewing code locally when a developer prefers that workflow. The concern is that it is becoming a required workaround when the web interface cannot display or process changes properly. It also prevents the team from collaborating on the review within a single shared interface.

The size of the team should not make a difference here. Whether a project has two developers or two hundred, reliable code review is one of the main reasons teams choose GitHub.

In the past, we rarely had serious concerns about how GitHub handled this workflow. Now, we increasingly find ourselves working around the platform instead of relying on it.

Copilot failures interrupt active work and remove context

We have also been experiencing recurring GitHub Copilot failures. These interruptions happen approximately three or four times within a 24-hour period, and at least one of them appears to occur regularly at around 10:50 a.m. EDT (GMT−4), which is approximately 5:50 p.m. for our team.

During one of these failures, Copilot returned the following error:

Sorry, your request failed. Please try again.

Copilot Request ID: 672f2881-e8e4-4b00-8dc6-b65059357127
GH Request ID: A257:245FAD:1AE807B:1D20CE2:6A54FEC9

Reason: Request Failed: 400
Invalid input[15].id: thinking_0. Expected an ID that begins with rs.

After approximately 15–45 minutes, Copilot usually starts working again. Unfortunately, the previous context is often gone.

This becomes especially frustrating when Copilot is handling a long-running task. The task stops, the working context disappears, and the usage consumed by the interrupted operation is not restored.

Taking a coffee break while waiting for the service to recover may work occasionally, but it is not a reliable recovery strategy.

A practical temporary improvement could be stronger persistence and rollback logic. Before attempting to build a perfect system capable of uninterrupted operation around the clock, GitHub could ensure that Copilot regularly preserves the task state, conversation context, generated changes, tool results, and the last successfully completed step.

Then, when a backend failure, deployment, capacity issue, or session reset occurs, Copilot could return to the last stable state instead of starting again without context.

Resource limitations may be one of the reasons these failures occur. I cannot confirm that from the outside, but stronger persistence would at least reduce the impact on users while the underlying problem is being investigated.

It would also be helpful if interrupted tasks could be resumed and the usage consumed by unsuccessful operations could be restored. Even a simple message explaining that a session has been recovered from the last checkpoint would create a much better experience.

Privacy-related AI changes should be communicated clearly

There is also a broader concern regarding privacy and the use of AI with private repositories.

When permissions, data-processing rules, AI-training options, or privacy settings change, users should not have to discover those changes accidentally. These decisions can affect private source code, intellectual property, security requirements, and the trust between GitHub and its customers.

When a change is important or time-sensitive, GitHub should communicate it directly through email or a clear in-product notification. Users should be told what has changed, which repositories or organizations may be affected, and where they can review their settings.

I also believe that any new option that could introduce additional privacy, security, or data-usage risks should be disabled by default. Users and organizations should consciously enable such functionality after understanding what it does and how their data may be affected.

For private repositories in particular, the safest and most protective setting should always be the default.

AI should strengthen the platform, not distract from its foundation

I understand why GitHub is investing heavily in AI. Every major technology company is participating in the current AI race, and Copilot can provide real value when it works reliably.

At the same time, AI should not come at the expense of the platform’s foundation. Reliable source-code hosting, effective pull-request reviews, stable subscription management, responsive support, persistent AI sessions, and transparent privacy communication are still essential.

GitHub became successful because teams trusted it with their code and development processes—not simply because it offered an AI assistant.

After the issues we have experienced during the past six months, my team and I now need to consider reducing our dependency on GitHub or duplicating critical parts of our workflow across other tools.

This may eventually mean separating code review, AI assistance, backups, or other important processes so that a problem with one platform cannot interrupt the entire development workflow.

That is not a decision we expected to be discussing.

GitHub team, I hope these issues receive attention. The goal is not to slow down AI innovation, but to ensure that this innovation is built on top of a stable and trustworthy platform.

AI should strengthen GitHub’s original mission—not distract from it.

Innovation attracts users. Reliability keeps them.