GitHub Says Copilot Code Review Could Not Build a Review for Some Customers but Reported That the Job Had Completed Successfully

GitHub's availability report is published on the company's own blog. The edition for September 2026, dated October 14, 2026, says that in September GitHub "experienced two incidents that resulted in degraded performance across GitHub services." One of them was in Copilot code review, which posts reviews on pull requests. For affected customers, the report says, it "could not build a review, but reported that the job had completed successfully." It is GitHub's own account of its own service. Parts of it follow, not the whole.

The September 28 Incident

The report says the incident "impacted Copilot code review across github.com and GHEC data-residency regions." Affected customers saw Copilot stay in a reviewing state with no review appearing, "with delays ranging from ~30 minutes to a max of 2 hours." Some reviews on github.com went on completing normally, while reviews in data-residency regions did not.

Copilot code review uses a separate service to run reviews, the report says, "and 2 versions of the results are returned": a limited copy "that excludes the review comments" and a full copy "that includes the completed review." Copilot code review posts reviews only from the full copy. A change to the service began sending the full copy only for some customers. For the others, only the limited copy was sent, and the report's list of steps says the change "reached every environment."

So Copilot code review could not build a review. It reported that the job had completed successfully all the same. The missing review results, GitHub says, "were not detected due to lack of monitoring."

The job said it was done, and the review was not there. A status that reports the end of a job, and not whether its result reached the pull request, can stay green through the whole failure.

How GitHub Responded, and What It Says It Is Improving

The incident was detected, the report says, "as some of the reviews remained incomplete for more than 30 minutes, triggering an alert to first responders." In its list of steps, reviews began timing out, an alert went to the Copilot code review team, and GitHub declared an incident. It traced the failures to the change and began reverting it. While the revert "completed its required checks," GitHub posted the incident on its status page. Once the revert reached all the affected regions, it resolved the incident and advised customers "to request affected reviews again."

GitHub says it is adding safeguards "throughout the review and delivery process." These, it says, "will help ensure that completed reviews are delivered successfully, allow failed reviews to recover automatically, and provide earlier notification when issues occur." It is also improving its monitoring and deployment processes "so that problems can be identified and addressed more quickly." What the report does not say is whether a job will still be able to call itself complete when no review reached the pull request.

The September 13 Incident

In the other September incident, the report says, "A background data-cleanup job increased load on a shared database." The job had a safeguard "designed to slow its writes when database replicas fell behind, but the safeguard did not account for incoming load on the primary database server." The job kept running until the primary reached its connections limit. When the primary ran out of available connections, requests that depended on it "could not complete reliably."

"Two other factors increased the impact and delayed recovery," the report says. There was "no quick timeout on these database calls," so request handlers waited on the stalled database instead of failing fast. And "a retry loop around token creation kept resending writes that were already failing, which held the database saturated rather than letting it recover." Automated monitoring detected this incident, the report says, and GitHub reduced internal load and paused the job.

This safeguard was not missing. It watched replica lag, and the load that mattered was building on the primary.

GitHub says it is implementing additional safeguards. These measures, it says, "will better control background processing based on available database capacity, reduce unnecessary retries during failures, and limit the impact of slow database requests."

When a job reports success, what checks that its result reached the person waiting for it?