GitHub incident continues to degrade Actions, Issues, Projects and notifications

GitHub confirms ongoing degradation across core services

GitHub is working through an incident that has degraded several of its core developer services, including Actions, Issues, Projects and notifications. According to the company's status page, a first attempt to mitigate the problem did not fully succeed, and more than an hour after engineers began investigating, users were still running into delays and errors.

The incident drew wide attention after surfacing on the Hacker News front page.

How the incident unfolded

GitHub opened its investigation at 12:21 UTC on October 12, 2026, in response to reports of degraded performance across Actions, Issues and Pull Requests. Twelve minutes later the company detailed the symptoms: trouble loading the Actions tab in the interface, problems interacting with the Checks API, failures when queueing new Actions runs, difficulty creating and updating issues, and errors when requesting reviews on pull requests.

Notably, the status update said these problems extended to both the REST and GraphQL APIs, meaning the disruption was not limited to the website — anything built on top of those endpoints, such as bots, CI tooling and internal automation, could also be affected.

At 12:57 UTC GitHub reported that a fix was being rolled out and that engineers were watching for signs of recovery, while warning that web notifications could lag as a side effect of the mitigation. Five minutes after that, at 13:02 UTC, the company declared Pull Requests back to normal.

First fix falls short

The recovery did not hold across the board. In an update posted at 13:38 UTC, GitHub acknowledged that its initial mitigation had fallen short: users could still experience delays and errors with Actions, Issues and Projects, and notifications remained delayed. The company said it was continuing to investigate the underlying cause and to prepare additional mitigations.

As of the most recent entry on the incident page, no resolution had been announced, and the officially affected components remained listed as Issues, Pull Requests and Actions — even though Pull Requests had been reported healthy at 13:02 UTC.

Practical impact for developers

The scope of the disruption maps directly onto daily development workflows. CI pipelines that rely on GitHub Actions may be unable to queue new runs or may hang waiting for the Checks API to respond, which stalls merges that are gated on passing builds. Teams that run their planning in Issues and Projects can lose the ability to create or update tickets mid-sprint. Delayed notifications add a quieter problem: contributors may simply be unaware that a build failed, a review was requested or an incident was underway, because the signals that normally tell them never arrive.

Because the failures reach the REST and GraphQL APIs, third-party integrations could see timeouts or error responses rather than clean degradation, which can make the incident appear as a bug in someone's own tooling before the status page is checked.

Why it matters

GitHub Actions has become the CI/CD backbone for a large share of open-source and commercial projects, while Issues and Projects serve as the coordination layer for many of those same teams. When run queueing and issue updates fail at the API level, the blast radius extends well beyond a slow website: releases slip, merges wait on checks that never report, and automation written against GitHub's APIs breaks in ways its authors did not anticipate.

The incident is also a reminder of how much modern development consolidates onto a single platform. Source hosting, code review, CI, project tracking and notifications are one vendor's reliability away from failing together, and teams with tight release windows or on-call rotations tied to CI results pay for that coupling in lost time.

GitHub has not yet identified a root cause. Its status page remains the authoritative source for updates on additional mitigations and eventual resolution.