GitHub SLA Tracker

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

The degradation affecting Pull Requests has been mitigated. We are monitoring to ensure stability.

We continue to see a small subset of repositories experiencing timeouts and elevated latency in Pull Requests, affecting under 1% of requests.

Error rates remain elevated across multiple pull request endpoints. We are pursuing multiple potential mitigations.

We continue to experience elevated error rates affecting Pull Requests. An earlier fix resolved one component of the issue, but some users may still encounter intermittent timeouts when viewing or interacting with pull requests. Our teams are actively investigating the remaining causes.

We identified an issue causing increased errors when accessing Pull Requests. The mitigation is being applied across our infrastructure and we will continue to provide updates as the mitigation rolls out.

We are seeing recovery in latency and timeouts of requests related to pull requests, even though 500s are still elevated. While we are continuing to investigate, we are applying a mitigation and expect further recovery after it is applied.

We are continuing to investigate increased 500 errors affecting GitHub services. You may experience intermittent failures when using Pull Requests and other features. We are actively working to identify and resolve the underlying cause.

We are investigating increased 500 errors affecting GitHub services. You may experience intermittent failures when using Pull Requests and other features. We are actively working to identify and resolve the underlying cause.

We are seeing a higher than average number of 500s due to timeouts across GitHub services. We have a potential mitigation in flight and are continuing to investigate.

We are investigating reports of degraded performance for Pull Requests

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

The degradation has been mitigated. We are monitoring to ensure stability.

We have applied mitigations to a data store related to billing reports, and are seeing partial recovery to billing report generation. We continue to monitor for full recovery.

We are seeing a high number of 500s due to timeouts across GitHub services. We are redeploying some of our core services and we expect that this allow us to recover.

We're continuing to see high failure rates on billing report generation, and are working on mitigations for a data store related to billing reports.

We're seeing issues related to metered billing reports, intermittently affecting metered usage graphs and reports on the billing page. We have identified an issue with a data store, and are working on mitigations.

We are investigating reports of impacted performance for some GitHub services.

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

The degradation has been mitigated. We are monitoring to ensure stability.

The degradation affecting Actions and Pull Requests has been mitigated. We are monitoring to ensure stability.

We are investigating reports of degraded performance for Actions and Pull Requests

On March 27, 2026, from 02:30 to 04:56 UTC, a misconfiguration in our rate limiting system caused users on Copilot Free, Student, Pro, and Pro+ plans to experience unexpected rate limit errors. The configuration that was incorrectly applied was intended solely for internal staff testing of rate-limiting experiences. Copilot Business and Copilot Enterprise accounts were not affected. During this period, affected users received error messages instructing them to retry after a certain time. Approximately 32% of active Free users, 35% of active Student users, 46% of active Pro users, and 66% of active Pro+ users were affected. After identifying the root cause, we reverted the change and restored the expected rate limits. We are reviewing our deployment and validation processes to help ensure configurations used for internal testing cannot be inadvertently applied to production environments.

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

We are investigating elevated error rates affecting multiple GitHub services including Actions, Issues, Pull Requests, Webhooks, Codespaces, and login functionality. Some users may have experienced errors when accessing these features. Most services are now showing signs of recovery. We'll post another update by 21:00 UTC.

Issues is experiencing degraded performance. We are continuing to investigate.

Pull Requests is experiencing degraded performance. We are continuing to investigate.

Webhooks is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of degraded performance for Actions

On March 24, 2026, between 15:57 UTC and 19:51 UTC, the Microsoft Teams Integration and Teams Copilot Integration services were degraded and unable to deliver GitHub event notifications to Microsoft Teams. On average, the error rate was 37.4% and peaked at 90.1% of requests to the service -- approximately 19% of all integration installs failed to receive GitHub-to-Teams notifications in this time period.<br /><br />This was due to an outage at one of our upstream dependencies, which caused HTTP 500 errors and connection resets for our Teams integration.<br /><br />We coordinated with the relevant service teams, and the issue was resolved at 19:51 UTC when the upstream incident was mitigated.<br /><br />We are working to update observability and runbooks to reduce time to mitigation for issues like this in the future.

We are experiencing degraded availability from Azure Teams APIs, which is impacting notifications from GitHub to Microsoft Teams. We are awaiting resolution from Azure.

We are experiencing degraded availability from Azure APIs, which is impacting notifications from GitHub to Microsoft Teams. We are working with Azure to resolve the issue.

We found an issue impacting notifications from GitHub to Microsoft Teams. We are working on mitigation and will keep users updated on progress towards mitigation.

We are investigating reports of impacted performance for some GitHub services.

On March 22, 2026, between 09:05 UTC and 10:02 UTC, users may have experienced intermittent errors and increased latency when performing Git http read operations. On average, the error rate was 3.84% and peaked at 15.55% of requests to the service. The issue was caused by elevated latency in an internal authentication service within one of our regional clusters. We mitigated the issue by redirecting traffic away from the affected cluster at 09:39 UTC, after which error rates returned to normal. The incident was fully resolved at 10:02 UTC. <br /><br />We are working to scale the authentication service and reduce our time to detection and mitigation of issues like this one in the future.

We are investigating intermittently high latency and errors from Git operations.

We are investigating reports of impacted performance for some GitHub services.

On March 19, 2026, between 01:05 UTC and 02:52 UTC, and again on March 20, 2026, between 00:42 UTC and 01:58 UTC, the Copilot Coding Agent service was degraded and users were unable to start new Copilot Agent sessions or view existing ones. During the first incident, the average error rate was ~53% and<br />peaked at ~93% of requests to the service. During the second incident, the average error rate was ~99%% and peaked at ~100%% of requests with significant retry amplification. Both incidents were caused by the same underlying system authentication issue that prevented the service from connecting to its<br />backing datastore.<br /><br />We mitigated each incident by rotating the affected credentials, which restored connectivity and returned error rates to normal. The mitigation time was 01:24. The second occurrence was due to an incomplete remediation of the first.<br /><br />We are implementing automated monitoring for credential lifecycle events and improving operational processes to reduce our time to detection and mitigation of issues like this one in the future.

We are rolling out our mitigation and are seeing recovery.

We are seeing widespread issues starting and viewing Copilot Agent sessions. We understand the cause and are working on remediation.

We are investigating reports of impacted performance for some GitHub services.

On March 19, 2026 between 16:10 UTC and 00:05 UTC (March 20), Git operations (clone, fetch, push) from the US west coast experienced elevated latency and degraded throughput. Users reported clone speeds dropping from typical speeds to under 1 MiB/s in extreme cases. The root cause was network transport link saturation at our Seattle edge site, where a fiber cut affecting our backbone transport resulted in saturation and packet loss. We had a planned scale-up in progress for the site that was accelerated to resolve the backbone capacity pressure. We also brought online additional edge capacity in a cloud region and redirected some users there. Current scale with the upgraded network capacity is sufficient to prevent reoccurrence, as we upgraded from 800Gbps to 3.2Tbps total capacity on this path. We will continue to monitor network health and respond to any further issues.

We have reached stability with git operations through our changes deployed today.

We are seeing early signs of improvement. We are working on one more small change to further improve traffic routing on the west coast.

We have completed the rollout of our new network path and are monitoring its impact.

We are beginning the rollout of our new network path. During this change, users will continue to see higher latency from the west coast. We will provide another update when the rollout is complete.

We are working to enable a new network path in the west coast to reduce load and will monitor the impact on latency for Git Operations

We are still seeing elevated latency for Git operations in the west coast and are continuing to investigate

We are redirecting traffic back to our Seattle region and customers should see a decrease in latency for Git operations

We are investigating reports of degraded performance for Git Operations

On March 19, 2026, between 01:05 UTC and 02:52 UTC, and again on March 20, 2026, between 00:42 UTC and 01:58 UTC, the Copilot Coding Agent service was degraded and users were unable to start new Copilot Agent sessions or view existing ones. During the first incident, the average error rate was ~53% and<br /> peaked at ~93% of requests to the service. During the second incident, the average error rate was ~99%% and peaked at ~100%% of requests with significant retry amplification. Both incidents were caused by the same underlying system authentication issue that prevented the service from connecting to its<br /> backing datastore.<br /> <br /> We mitigated each incident by rotating the affected credentials, which restored connectivity and returned error rates to normal. The mitigation time was 01:24. The second occurrence was due to an incomplete remediation of the first.<br /> <br /> We are implementing automated monitoring for credential lifecycle events and improving operational processes to reduce our time to detection and mitigation of issues like this one in the future.

Copilot is operating normally.

We are investigating reports that Copilot Coding Agent session logs are not available in the UI.

Copilot is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

On March 19, 2026, between 01:05 UTC and 02:52 UTC, and again on March 20, 2026, between 00:42 UTC and 01:58 UTC, the Copilot Coding Agent service was degraded and users were unable to start new Copilot Agent sessions or view existing ones. During the first incident, the average error rate was ~53% and<br /> peaked at ~93% of requests to the service. During the second incident, the average error rate was ~99%% and peaked at ~100%% of requests with significant retry amplification. Both incidents were caused by the same underlying system authentication issue that prevented the service from connecting to its<br /> backing datastore.<br /> <br /> We mitigated each incident by rotating the affected credentials, which restored connectivity and returned error rates to normal. The mitigation time was 01:24. The second occurrence was due to an incomplete remediation of the first.<br /> <br /> We are implementing automated monitoring for credential lifecycle events and improving operational processes to reduce our time to detection and mitigation of issues like this one in the future.

We have rolled out our mitigation and are seeing recovery for Copilot Coding Agent sessions

We are seeing widespread issues starting and viewing Copilot Agent sessions. We have a hypothesis for the cause and are working on remediation.

We are investigating reports of impacted performance for some GitHub services.

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

We are seeing recovery in git operations for customers on the West Coast of the US.

We continue to investigate the slow performance of Git Operations affecting the US West Coast.

We continue to investigate degraded performance for git operations from the US West Coast.

We are continuing to investigate degraded performance for git operations from the US West Coast.

We are experiencing increased latency when performing git operations, especially large pushes and pulls from customers on the west coast of the US. We are not seeing an increase in failures. We are continuing to investigate.

Git Operations is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

On March 18, 2026, between 18:18 UTC and 19:46 UTC all webhook deliveries experienced elevated latency. During this time, average delivery latency increased from a baseline of approximately 5 seconds to a peak of approximately 160 seconds. This was due to resource constraints in the webhook delivery pipeline, which caused queue backlog growth and increased delivery latency. We mitigated the incident by shifting traffic and adding capacity, after which webhook delivery latency returned to normal. We are working to improve capacity management and detection in the webhook delivery pipeline to help prevent similar issues in the future.

We are seeing recovery and are continuing to monitor the latency for webhook deliveries

We are investigating reports of degraded performance for Webhooks

On 16 March 2026, between 14:16 UTC and 15:18 UTC, Codespaces users encountered a download failure error message when starting newly created or resumed codespaces. At peak, 96% of the created or resumed codespaces were impacted. Active codespaces with a running VSCode environment were not affected. <br /><br />The error was a result of an API deployment issue with our VS Code remote experience dependency and was resolved by rolling back that deployment. We are working with our partners to reduce our incident engagement time, improve early detection before they impact our customers, and ensure safe rollout of similar changes in the future.

Errors starting or resuming Codespaces have resolved.

We are investigating reports of users experiencing errors when starting or connecting to Codespaces. Some users may be unable to access their development environments during this time. We are working to identify the root cause and will implement a fix as soon as possible.

We are investigating reports of impacted performance for some GitHub services.

On March 13, 2026, between 13:35 UTC and 16:02 UTC, a configuration change to an internal authorization service reduced its processing capacity below what was needed during peak traffic. This caused intermittent timeouts when other GitHub services checked user permissions, resulting in four to five waves of errors over roughly two hours and forty minutes. In total, 0.4% of users were denied access to actions they were authorized to perform. <br /><br />The root cause was a resource right-sizing change deployed to the authorization service the previous day. It reduced CPU allocation below what was required at peak, causing the service's network gateway to throttle under load. Because the change was deployed after peak traffic on March 12, the reduced capacity wasn't surfaced until the next day's peak. <br /><br />The incident was mitigated by manually scaling up the authorization service and reverting the configuration change. <br /><br /> <br />To prevent recurrence, we are adding further resource utilization monitors across our entire stack to detect throttling and improving error handling so transient infrastructure timeouts are distinguished from authorization failures, enabling quicker detection of the root issue.

We have deployed mitigations and are actively monitoring for recovery. We'll post another update by 17:00 UTC.

We are investigating intermittent performance degradation affecting Actions, Feeds, Issues, Package Registry, Profiles, Registry Metadata, Star, and User Dashboard. Users may experience elevated error rates and slower response times when accessing these services. We have identified a potential cause and are implementing mitigations to restore normal service. We'll post another update by 16:15 UTC.

Packages is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of issues with service(s): Actions, Feeds, Issues, Profiles, Registry Metadata, Star, User Dashboard. We will continue to keep users updated on progress towards mitigation.

We are investigating reports of degraded performance for Actions and Issues

On March 12, 2026, between 01:00 UTC and 18:53 UTC, users saw failures downloading extensions within created or resumed codespaces. Users would see an error when attempting to use an extension within VS Code. Active codespaces with extensions already downloaded were not impacted.<br /><br />The extensions download failures were the result of a change introduced in our extension dependency and was resolved by updating the configuration of how those changes affect requests from Codespaces. We are enhancing observability and alerting of critical issues within regular codespace operations to better detect and mitigate similar issues in the future.

Codespaces IPs are no longer being blocked from Visual Studio Marketplace operations and we are monitoring for full recovery

We're seeing intermittent failures downloading from the extension marketplace from codespaces, caused by IP blocks for some codespaces. We're working to remove those blocks.

We're seeing intermittent failures downloading from the extension marketplace from codespaces and are investigating.

We're seeing partial recovery for the issue affecting extension installation in newly created Codespaces. Some users may still experience degraded functionality where extensions hit errors. The team continues to investigate the root cause while monitoring the recovery.

We have deployed a fix for the issue affecting extension installation in newly created Codespaces. New Codespaces are now being created with working extensions. We'll post another update by 15:30 UTC.

We are continuing to investigate an issue where extensions fail to install in newly created Codespaces. Users can create and access Codespaces, but extensions will not be operational, resulting in a degraded experience. The team is working on a fix. All newly created Codespaces are affected. We'll post another update by 15:00 UTC.

We're investigating an issue where extensions fail to install in newly created Codespaces. Users can still create and access Codespaces, but extensions will not be operational, resulting in a degraded development experience. Our team is actively working to identify and resolve the root cause. We'll post another update by 14:00 UTC.

We are investigating reports of degraded performance for Codespaces

On March 12, 2026 between 02:30 and 06:02 UTC some GitHub Apps were unable to mint server to server tokens, resulting in 401 Unauthorized errors. During the outage window, ~1.3% of requests resulted in 401 errors incorrectly. This manifested in GitHub Actions jobs failing to download tarballs, as well as failing to mint fine-grained tokens. During this period, approximately 5% of Actions jobs were impacted <br /><br />The root cause was a failure with the authentication service’s token cache layer, a newly created secondary cache layer backed by Redis – caused by Kubernetes control plane instability, leading to an inability to read certain tokens which resulted in 401 errors. The mitigation was to fallback reads to the primary cache layer backed by mysql. As permanent mitigations, we have made changes to how we deploy redis to not rely on the Kubernetes control plane and maintain service availability during similar failure modes. We also improved alerting to reduce overall impact time from similar failures. <br />

Actions is operating normally.

We are continuing investigation of reports of degraded performance for Actions and GitHub Apps

We are investigating reports of degraded performance for Actions

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

We've identified the root cause and are working on resolving the underlying issue. Some users may have encountered intermittent failures and errors. We're continuing to see reduced error rates.

We are investigating elevated error rates. Error rates are now decreasing and we're continuing to monitor the situation.

We are investigating reports of impacted performance for some GitHub services.

On March 11, 2026, between 14:25 UTC and 14:34 UTC, the REST API platform was degraded, resulting in increased error rates and request timeouts. REST API 5xx error rates peaked at ~5% during the incident window with two distinct spikes: the first impacting REST services broadly, and the second driven by sustained timeouts on a subset of endpoints. <br /><br />The incident was caused by a performance degradation in our data layer, which resulted in increased query latency across dependent services. Most services recovered quickly after the initial spike, but resource contention caused sustained 5xx errors due to how certain endpoints responded to the degraded state. <br /><br />A fix addressing the behavior that prolonged impact has already been shipped. We are continuing to work to resolve the primary contributing factor of the degradation and to implement safeguards against issues causing cascading impact in the future.

We are investigating elevated timeouts that affected GitHub API requests. The incident began at 14:37 UTC. Some users experienced slower response times and request failures. System metrics have returned to normal levels, and we are now investigating the root cause to prevent recurrence.

We are investigating reports of degraded performance for API Requests

On March 11, 2026, between 13:00 UTC and 15:23 UTC the Copilot Code Review service was degraded and experienced longer than average review times. On average, Copilot Code Review requests took 4 minutes and peaked at just under 8 minutes. This was due to hitting worker capacity limits and CPU throttling. We mitigated the incident by increasing partitions, and we are improving our resource monitoring to identify potential issues sooner.

Copilot Code Review queue processing has returned to normal levels.

We experienced degraded performance with Copilot Code Review starting at 14:01 UTC. Customers experienced extended review times and occasional failures. Some extended processing times may continue briefly. We are monitoring for full recovery. We'll post another update by 16:30 UTC.

We are investigating degraded performance with Copilot Code Review. Customers may experience extended review times or occasional failures. We are seeing signs of improvement as our team works to restore normal service. We'll post another update by 15:30 UTC.

We are investigating reports of impacted performance for some GitHub services.

On March 10, 2026, between 23:00 UTC and 23:40 UTC, the Webhooks service was degraded and ~6% of users experienced intermittent errors when accessing webhook delivery history, retrying webhook deliveries, and listing webhooks via the UI and API. Approximately 0.37% of requests resulted in errors, while at peak 0.5% of requests resulted in errors. This was due to unhealthy infrastructure. We mitigated the incident by redeploying affected services, after which service health returned to normal. We are working to improve detection of unhealthy infrastructure and strengthen service safeguards to reduce time to detect and mitigate similar issues in the future.

On March 9, 2026, between 15:03 and 20:52 UTC, the Webhooks API experienced was degraded, resulted in higher average latency on requests and in certain cases error responses. Approximately 0.6% of total requests exceeded the normal latency threshold of 3s, while 0.4% of requests resulted in 500 errors. At peak, 2.0% experienced latency greater than 3 seconds and 2.8% of requests returned 500 errors.<br /><br />The issue was caused by a noisy actor that led to resource contention on the Webhooks API service. We mitigated the issue initially by increasing CPU resources for the Webhooks API service, and ultimately applied lower rate limiting thresholds to the noisy actor to prevent further impact to other users.<br /><br />We are working to improve monitoring to more quickly ascertain noisy traffic and will continue to improve our rate-limiting mechanisms to help prevent similar issues in the future.

Webhooks is operating normally.

We are experiencing latency on the API and UI endpoints. We are working to resolve the issue.

We are investigating reports of degraded performance for Webhooks

On March 9, 2026, between 01:23 UTC and 03:25 UTC, users attempting to create or resume codespaces in the Australia East region experienced elevated failures, peaking at a 100% failure rate for this region. Codespaces in other regions were not affected.<br /><br />The create and resume failures were caused by degraded network connectivity between our control plane services and the VMs hosting the codespaces. This was resolved by redirecting traffic to an alternate site within the region. While we are addressing the core network infrastructure issue, we have also improved our observability of components in this area to improve detection. This will also enable our existing automated failovers to cover this failure mode. These changes will prevent or significantly reduce the time any similar incident causes user impact.

This incident has been resolved. New Codespace creation requests are now completing successfully.

We are seeing recovery, with the failure rate for new Codespace creation requests dropping from 5% to about 3%.

We are seeing about 5% of new Codespace creation requests failing. We are investigating the root cause and identifying the impacted regions.

We are investigating reports of degraded performance for Codespaces

On March 6, 2026, between 16:16 UTC and 23:28 UTC the Webhooks service was degraded and some users experienced intermittent errors when accessing webhook delivery histories, retrying webhook deliveries, and listing webhooks via the UI and API. On average, the error rate was 0.57% and peaked at approximately 2.73% of requests to the service. This was due to unhealthy infrastructure affecting a portion of webhook API traffic.<br /><br />We mitigated the incident by redeploying affected services, after which service health returned to normal.<br /><br />We are working to improve detection of unhealthy infrastructure and strengthen service safeguards to reduce time to detection and mitigation of issues like this one in the future.

Webhooks is operating normally.

We have deployed a fix and are observing a full recovery. The affected endpoint was the webhook deliveries API (https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#list-deliveries-for-a-repository-webhook) and its organization and integration variants. We will continue monitoring to confirm stability.

We are preparing a new mitigation for the issue affecting the webhook deliveries API (https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#list-deliveries-for-a-repository-webhook) and its organization and integration variants. Overall impact remains low, with under 1% of requests failing for a subset of customers.

The previous mitigation did not resolve the issue. We are investigating further. The affected endpoint is the webhook deliveries API (https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#list-deliveries-for-a-repository-webhook) and its organization and integration variants. Overall impact remains low, with under 1% of requests failing for a subset of customers.

We have deployed a fix for the issue causing some users to experience intermittent failures when accessing the Webhooks API and configuration pages. We are monitoring to confirm full recovery.

We continue working on mitigations to restore service.

We continue working on mitigations to restore service.

We continue working on mitigations to restore service.

We continue working on mitigations to restore full service.

Our engineers have identified the root cause and are actively implementing mitigations to restore full service.

This problem is impacting less than 1% of UI and webhook API calls.

We are investigating an issue affecting a subset of customers experiencing errors when viewing webhook delivery histories and retrying webhook deliveries. UI and webhook API is impacted. Engineers have identified the cause and are actively working on mitigation.

We are investigating reports of degraded performance for Webhooks

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

We are close to full recovery. Actions and dependent services should be functioning normally now.

Actions is experiencing degraded performance. We are continuing to investigate.

Actions and dependent services, including Pages, are recovering.

We applied a mitigation and we should see a recovery soon.

Actions is experiencing degraded availability. We are continuing to investigate.

We are investigating reports of degraded performance for Actions

On Mar 5, 2026, between 16:24 UTC and 19:30 UTC, Actions was degraded. During this time, 95% of workflow runs failed to start within 5 minutes with an average delay of 30 minutes and 10% workflow runs failed with an infrastructure error. This was due to Redis infrastructure updates that were being rolled out to production to improve our resiliency. These changes introduced a set of incorrect configuration change into our Redis load balancer causing internal traffic to be routed to an incorrect host leading to two incidents. <br /><br />We mitigated this incident by correcting the misconfigured load balancer. Actions jobs were running successfully starting at 17:24 UTC. The remaining time until we closed the incident was burning through the queue of jobs. <br /><br />We immediately rolled back the updates that were a contributing factor and have frozen all changes in this area until we have completed follow-up work from this. We are working to improve our automation to ensure incorrect configuration changes are not able to propagate through our infrastructure. We are also working on improved alerting to catch misconfigured load balancers before it becomes an incident. Additionally, we are updating the Redis client configuration in Actions to improve resiliency to brief cache interruptions.

Webhooks is operating normally.

Actions is operating normally.

Actions is now fully recovered.

The queue of requested Actions jobs continues to make progress. Job delays are now approximately 6 minutes and continuing to decrease.

We are back to queueing Actions workflow runs at nominal rates and we are monitoring the clearing of queued runs during the incident.

We have applied mitigations for connection failures across backend resources and we are observing a recovery in queueing Actions workflow runs.

We are observing delays in queuing Actions workflow runs. We’re still investigating the causes of these delays.

Webhooks is experiencing degraded availability. We are continuing to investigate.

Actions is experiencing degraded availability. We are continuing to investigate.

We are investigating reports of degraded performance for Actions

On March 5, 2026, between 12:53 UTC and 13:35 UTC, the Copilot mission control service was degraded. This resulted in empty responses returned for users' agent session lists across GitHub web surfaces. Impacted users were unable to see their lists of current and previous agent sessions in GitHub web surfaces. This was caused by an incorrect database query that falsely excluded records that have an absent field.<br /><br />We mitigated the incident by rolling back the database query change. There were no data alterations nor deletions during the incident.<br /><br />To prevent similar issues in the future, we're improving our monitoring depth to more easily detect degradation before changes are fully rolled out.

Copilot coding agent mission control is fully restored. Tasks are now listed as expected.

Users were temporarily unable to see tasks listed in mission control surfaces. The ability to submit new tasks, view existing tasks via direct link, or manage tasks was unaffected throughout. A revert is currently being deployed and we are seeing recovery.

We are investigating reports of impacted performance for some GitHub services.

On March 5th, 2026, between approximately 00:26 and 00:44 UTC, the Copilot service experienced a degradation of the GPT 3.5 Codex model due to an issue with our upstream provider. Users encountered elevated error rates when using GPT 3.5 Codex, impacting approximately 30% of requests. No other models were impacted.<br /><br />The issue was resolved by a mitigation put in place by our provider.

The issues with our upstream model provider have been resolved, and gpt-5.3-codex is once again available in Copilot Chat and across IDE integrations. We will continue monitoring to ensure stability, but mitigation is complete.

We are experiencing degraded availability for the gpt-5.3-codex model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br />

We are investigating reports of degraded performance for Copilot

On March 3, 2026, between 19:44 UTC and 21:05 UTC, some GitHub Copilot users reported that the Claude Opus 4.6 Fast model was no longer available in their IDE model selection. After investigation, we confirmed that this was caused by enterprise administrators adjusting their organization's model policies, which correctly removed the model for users in those organizations. No users outside the affected organizations lost access.<br /><br />We confirmed that the Copilot settings were functioning as designed, and all expected users retained access to the model. The incident was resolved once we verified that the change was intentional and no platform regression had occurred.

We believe that all expected users still have access to Claude Opus 4.6. We confirm that no users have lost access.

We are investigating reports of degraded performance for Copilot

On March 3, 2026, between 18:46 UTC and 20:09 UTC, GitHub experienced a period of degraded availability impacting GitHub.com, the GitHub API, GitHub Actions, Git operations, GitHub Copilot, and other dependent services. At the peak of the incident, GitHub.com request failures reached approximately 40%. During the same period, approximately 43% of GitHub API requests failed. Git operations over HTTP had an error rate of approximately 6%, while SSH was not impacted. GitHub Copilot requests had an error rate of approximately 21%. GitHub Actions experienced less than 1% impact. <br /><br />This incident shared the same underlying cause as an incident in early February where we saw a large volume of writes to the user settings caching mechanism. While deploying a change to reduce the burden of these writes, a bug caused every user’s cache to expire, get recalculated, and get rewritten. The increased load caused replication delays that cascaded down to all affected services. We mitigated this issue by immediately rolling back the faulty deployment. <br /><br />We understand these incidents disrupted the workflows of developers. While we have made substantial, long-term investments in how GitHub is built and operated to improve resilience, we acknowledge we have more work to do. Getting there requires deep architectural work that is already underway, as well as urgent, targeted improvements. We are taking the following immediate steps: <br /><br />- We have added a killswitch and improved monitoring to the caching mechanism to ensure we are notified before there is user impact and can respond swiftly. <br />- We are moving the cache mechanism to a dedicated host, ensuring that any future issues will solely affect services that rely on it.

We're seeing recovery across all services. We're continuing to monitor for full recovery.

Actions is operating normally.

Git Operations is operating normally.

Git Operations is experiencing degraded availability. We are continuing to investigate.

We are seeing recovery across multiple services. Impact is mostly isolated to git operations at this point, we continue to investigate

Copilot is operating normally.

Pull Requests is operating normally.

Pull Requests is experiencing degraded performance. We are continuing to investigate.

Issues is operating normally.

Webhooks is operating normally.

Codespaces is operating normally.

Webhooks is experiencing degraded performance. We are continuing to investigate.

Issues is experiencing degraded performance. We are continuing to investigate.

We've identified the issue and have applied a mitigation. We're seeing recovery of services. We continue to montitor for full recovery.

API Requests is operating normally.

API Requests is experiencing degraded performance. We are continuing to investigate.

Codespaces is experiencing degraded performance. We are continuing to investigate.

Pull Requests is experiencing degraded availability. We are continuing to investigate.

Webhooks is experiencing degraded availability. We are continuing to investigate.

We're seeing some service degradation across GitHub services. We're currently investigating impact.

Webhooks is experiencing degraded performance. We are continuing to investigate.

Pull Requests is experiencing degraded performance. We are continuing to investigate.

API Requests is experiencing degraded availability. We are continuing to investigate.

We are investigating reports of degraded availability for Actions, Copilot and Issues

Between March 2, 21:42 UTC and March 3, 05:54 UTC project board updates, including adding new issues, PRs, and draft items to boards, were delayed from 30 minutes to over 2 hours, as a large backlog of messages accumulated in the Projects data denormalization pipeline.<br /><br />The incident was caused by an anomalously large event that required longer processing time than expected. Processing this message exceeded the Kafka consumer heartbeat timeout, triggering repeated consumer group rebalances. As a result, the consumer group was unable to make forward progress, creating head-of-line blocking that delayed processing of subsequent project board updates.<br /><br />We mitigated the issue by deploying a targeted fix that safely bypassed the offending message and allowed normal message consumption to resume. Consumer group stability recovered at 04:10 UTC, after which the backlog began draining. All queued messages were fully processed by 05:53 UTC, returning project board updates to normal processing latency.<br /><br />We have identified several follow-up improvements to reduce the likelihood and impact of similar incidents in the future, including improved monitoring and alerting, as well as introducing limits for unusually large project events.

This incident has been resolved. Project board updates are now processing in near-real-time.

The backlog of delayed updates is expected to fully clear within approximately 1 hour, after which project board updates will return to near-real-time.

The fix has been deployed and processing speeds have returned to normal. There is a backlog of delayed updates that will continue to be worked through — we're estimating how long that will take and will provide an update in the next 60 minutes.

The fix is still building and is expected to deploy within 60 minutes. The current delay for GitHub Projects updates has increased to up to 5 hours.

We're deploying a fix targeting the increased delay in GitHub Projects updates. The rollout should complete within 60 minutes. If successful, the current delay of up to 4 hours should begin to decrease.

The delay for project board updates has increased to up to 3 hours. We've identified a potential cause and are working on remediation.

Project board updates — including adding issues, pull requests, and changing fields such as "Status" — are currently delayed by 1–2 hours. Normal behavior is near-real-time. We're actively investigating the root cause.

The impact extends beyond adding issues to project boards. Adding pull requests and updating fields such as "Status" may also be affected. We're continuing to investigate the root cause.

Newly added issues are taking 30–60 minutes to appear on project boards, compared to the normal near-real-time behavior. We're investigating the root cause and possible mitigations.

Newly added issues can take up to 30 minutes to appear on project boards. We're investigating the cause of this delay.

Issues is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

On March 2nd, 2026, between 7:10 UTC and 22:04 UTC the pull requests service was degraded. Users navigating between tabs on the pull requests dashboard were met with 404 errors or blank pages.<br /><br />This was due to a configuration change deployed on February 27th at 11:03 PM UTC. We mitigated the incident by reverting the change.<br /><br />We’re working to improve monitoring for the page to automatically detect and alert us to routing failures.

The issue on https://github.com/pulls is now fully resolved. All tabs are working again.

We're deploying a fix for pull request filtering. Full rollout across all regions is expected within 60 minutes.

We are experiencing issues with the Pull Requests dashboard that prevent users from filtering their pull requests. We have identified a mitigation and are deploying a fix. We'll post another update by 21:00 UTC.

We are seeing a degraded experience when attempting to filter the /pulls dashboard. We are working on a mitigation.

We are investigating reports of degraded performance for Pull Requests

On February 27, 2026, between 22:53 UTC and 23:46 UTC, the Copilot coding agent service experienced elevated errors and degraded functionality for agent sessions. Approximately 87% of attempts to start or interact with agent sessions encountered errors during this period.<br /><br />This was due to an expired authentication credential for an internal service component, which prevented Copilot agent session operations from completing successfully.<br /><br />We mitigated the incident by rotating the expired credential and deploying the updated configuration to production. Services began recovering within minutes of the fix being deployed.<br /><br />We are working to improve automated credential rotation coverage across all Copilot service components, add proactive alerting for credentials approaching expiration, and validate configuration consistency to reduce our time to detection and mitigation of issues like this one in the future.

We have identified the cause of the elevated errors and are rolling out a fix to production. We are observing initial recovery in Copilot agent sessions.

We are investigating networking issues with some requests to our models.

We are investigating a spike in errors in Copilot agent sessions

We are investigating reports of degraded performance for Copilot

Starting February 26, 2026 at 22:10 UTC through February 27, 05:50 UTC, the repository browsing UI was degraded and users were unable to load pages for files and directories with non-ASCII characters (including Japanese, Chinese, and other non-Latin scripts). On average, the error rate was 0.014% and peaked at 0.06% of requests to the service. Affected users saw 404 errors when navigating to repository directories and files with non-ASCII names. This was due to a code change that altered how file and directory names were processed, which caused incorrectly formatted data to be stored in an application cache.<br /><br />We mitigated the incident by deploying a fix that invalidated the affected cache entries and progressively rolling it out across all production environments.<br /><br />We are working to improve our pre-production testing to cover non-ASCII character handling, establish better cache invalidation mechanisms, and enhance our monitoring to detect this type of failure mode earlier, to reduce our time to detection and mitigation of issues like this one in the future.

We have cleared all caches and everything is operating normally.

We have mitigated the issue but are working on invalidating caches in order to fix the issue for all impacted repos.

We have performed a mitigation but some repositories may still see issues. We are working on a full mitigation.

We are looking into recent code changes to mitigate the error loading some code view pages.

We are investigating reports of impacted performance for some GitHub services.

Between February 26, 2026 UTC and February 27, 2026 UTC, customers hitting the webhooks delivery API may have experienced higher latency or failed requests. During the impact window, 0.82% of requests took longer than 3s and 0.004% resulted in a 500 error response.<br /><br />Our monitors caught the impact on the individual backing data source, and we were able to attribute the degradation to a noisy neighbor effect due requests to a specific webhook generating excessive load on the API. The incident was mitigated once traffic from the specific hook decreased.<br /><br />We have since added a rate limiter for this webhooks API to prevent similar spikes in usage impacting others and will further refine the rate limits for other webhook API routes to help prevent similar occurrences in the future.

Webhooks is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

On February 26, 2026, between 09:27 UTC and 10:36 UTC, the GitHub Copilot service was degraded and users experienced errors when using Copilot features including Copilot Chat, Copilot Coding Agent and Copilot Code Review. During this time, 5-15% of affected requests to the service returned errors.<br /><br />The incident was resolved by infrastructure rebalancing.<br /><br />We are improving observability to detect capacity imbalances earlier and enhancing our infrastructure to better handle traffic spikes.

Copilot is operating normally.

We are investigating reports of degraded performance for Copilot

On February 25, 2026, between 15:05 UTC and 16:34 UTC, the Copilot coding agent service was degraded, resulting in errors for 5% of all requests and impacting users starting or interacting with agent sessions. <br /><br />This was due to an internal service dependency running out of allocated resources (memory and CPU). We mitigated the incident by adjusting the resource allocation for the affected service, which restored normal operations for the coding agent service.<br /><br />We are working to implement proactive monitoring for resource exhaustion across our services, review and update resource allocations, and improve our alerting capabilities to reduce our time to detection and mitigation of similar issues in the future.

We are investigating reports of degraded performance for Copilot

On February 23, 2026, between 21:01 UTC and 21:30 UTC the Search service experienced degraded performance, resulting in an average of 3.5% of search requests for Issues and Pull Requests being rejected. During this period, updates to Issues and Pull Requests may not have been immediately reflected in search results. <br /><br />During a routine migration, we observed a spike in internal traffic due to a configuration change in our search index. We were alerted to the increase in traffic as well as the increase in error rates and rolled back to the previous stable index. <br /><br />We are working to enable more controlled traffic shifting when promoting a new index to allow us to detect potential limitations earlier and ensure these operations succeed in a more controlled manner.

Some customers are seeing timeout errors when searching for issues or pull requests. Team is currently investigating a fix.

We are investigating reports of degraded performance for Issues and Pull Requests

Between 2026-02-23 19:10 and 2026-02-24 00:46 UTC, all lexical code search queries in GitHub.com and the code search API were significantly slowed, and during this incident, between 5 and 10% of search queries timed out. This was caused by a single customer who had created a network of hundreds of orchestrated accounts which searched with a uniquely expensive search query. This search query concentrated load on a single hot shard within the search index, slowing down all queries. After we identified the source of the load and stopped the traffic, latency returned to normal.<br /><br />To avoid this situation occurring again in the future, we are making a number of improvements to our systems, including: improved rate limiting that accounts for highly skewed load on hot shards, improved system resilience for when a small number of shards time out, improved tooling to recognize abusive actors, and capabilities that will allow us to shed load on a single shard in emergencies.

We have identified a cause for the latency and timeouts and have implemented a fix. We are observing initial recovery now.

Customers using code search continue to see increased latency and timeout errors. We are working to mitigate issues on the affected shard.

Elevated latency and timeouts for code search is isolated to a single shard experiencing elevated CPU. We are taking steps to isolate and mitigate the affected shard.

Elevated latency and timeouts for code search is isolated to a single shard experiencing elevated CPU. We are continuing to investigate the cause and steps to mitigate.

We are continuing to investigate elevated latency and timeouts for code search.

We are investigating reports of impacted performance for some GitHub services.

On February 23, 2026, between 15:00 UTC and 17:00 UTC, GitHub Actions experienced degraded performance. During the time, 1.8% of Actions workflow runs experienced delayed starts with an average delay of 15 minutes. The issue was caused by a connection rebalancing event in our internal load balancing layer, which temporarily created uneven traffic distribution across sites and led to request throttling. <br /><br />To prevent recurrence, we are tuning connection rebalancing behavior to spread client reconnections more gradually during load balancer reloads. We are also evaluating improvements to site-level traffic affinity to eliminate the uneven distribution at its source. We have overprovisioned critical paths to prevent any impact if a similar event occurs before those workstreams finish. Finally, we are enhancing our monitoring to detect capacity imbalances proactively.

We are investigating reports of degraded performance for Actions

On February 23, 2026, between 14:45 UTC and 16:19 UTC, the Copilot service was degraded for Claude Haiku 4.5 model. On average, 6% of the requests to this model failed due to an issue with an upstream provider. During this period, automated model degradation notifications directed affected users to alternative models. No other models were impacted. The upstream provider identified and resolved the issue on their end. <br />We are working to improve automatic model failover mechanisms to reduce our time to mitigation of issues like this one in the future.

Copilot is operating normally.

The issues with our upstream model provider have been resolved, and Haiku 4.5 is once again available in Copilot Chat and across IDE integrations.<br /><br />We will continue monitoring to ensure stability, but mitigation is complete.

Our provider has recovered and we are not seeing errors but we are awaiting a signal from them that the issue will not regress before we go green.

We are experiencing degraded availability for the Haiku 4.5 model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br /><br />Other models are available and working as expected.

We are investigating reports of degraded performance for Copilot

On February 20, 2026, between 17:45 UTC and 20:41 UTC, 4.2% of workflows running on GitHub Larger Hosted Runners were delayed by an average of 18 minutes. Standard, Mac, and Self-Hosted Runners were not impacted. <br /><br />The delays were caused by communication failures between backend services for one deployment of larger runners. Those failures prevented expected automated scaling and provisioning of larger hosted runner capacity within that deployment. This was mitigated when the affected infrastructure was recycled, larger runner pools in the affected deployment successfully scaled up, and queued jobs processed. <br /><br />We are working to improve the time to detect and diagnose this class of failures and improve the performance of recovery mechanisms for this degraded network state. In addition, we have architectural changes underway that will enable other deployments to pick up work in similar situations, so there is no customer impact due to deployment-specific infrastructure issues like this.

The team continues to investigate issues with some larger runner jobs being queued for a long time. We are though seeing improvement in the queue times. We will continue providing updates on the progress towards mitigation.

We are investigating reports of degraded performance for Larger Hosted Runners

We are investigating reports of impacted performance for some GitHub services.

On February 20, 2026, between 07:30 UTC and 11:21 UTC, the Copilot service experienced a degradation of the GPT 5.1 Codex model. During this time period, users encountered a 4.5% error rate when using this model. No other models were impacted.<br />The issue was resolved by a mitigation put in place by the external model provider. GitHub is working with the external model provider to further improve the resiliency of the service to prevent similar incidents in the future.

The issues with our upstream model provider have been resolved, and GPT 5.1 Codex is once again available in Copilot Chat and across IDE integrations [VSCode, Visual Studio, JetBrains].<br />We will continue monitoring to ensure stability, but mitigation is complete.

We are still experiencing degraded availability for the GPT 5.1 Codex model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br />

We are experiencing degraded availability for the GPT 5.1 Codex model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br />Other models are available and working as expected.

We are investigating reports of degraded performance for Copilot

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

We have seen significant recovery in merge queue we are continuing to monitor for any other degraded services.

We are investigating reports of issues with merge queue. We will continue to keep users updated on progress towards mitigation.

Pull Requests is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

On February 17, 2026, between 17:07 UTC and 19:06 UTC, some customers experienced intermittent authentication failures affecting GitHub Actions, parts of Git operations, and other authentication-dependent requests. On average, the Actions error rate was approximately 0.6% of affected API requests. Git operations ssh read error rate was approximately 0.29%, while ssh write and http operations were not impacted. During the incident, a subset of requests failed due to token verification lookups intermittently failing, leading to 401 errors and degraded reliability for impacted workflows.<br /><br />The issue was caused by elevated replication lag in the token verification database cluster. In the days leading up to the incident, the token store’s write volume grew enough to exceed the cluster’s available capacity. Under peak load, older replica hosts were unable to keep up, replica lag increased, and some token lookups became inconsistent, resulting in intermittent authentication failures.<br /><br />We mitigated the incident by adjusting the database replica topology to route reads away from lagging replicas and by adding/bringing additional replica capacity online. Service health improved progressively after the change, with GitHub Actions recovering by ~19:00 UTC and the incident resolved at 19:06 UTC.<br /><br />We are working to prevent recurrence by improving the resilience and scalability of our underlying token verification data stores to better handle continued growth.

We are continuing to monitor the mitigation and continuing to see signs of recovery.

We have rolled out a mitigation and are seeing signs of recovery and are continuing to monitor.

We have identified a low rate of authentication failures affecting GitHub App server to server tokens, GitHub Actions authentication tokens, and git operations. Some customers may experience intermittent API request failures when using these tokens. We believe we've identified the cause and are working to mitigate impact.

We are investigating reports of degraded performance for Actions and Git Operations

On February 13, 2026, between 21:46 UTC and 22:58 UTC (72 minutes), the GitHub file upload service was degraded and users uploading from a web browser on GitHub.com were unable to upload files to repositories, create release assets, or upload manifest files. During the incident, successful upload completions dropped by ~85% from baseline levels. This was due to a code change that inadvertently modified browser request behavior and violated CORS (Cross-Origin Resource Sharing) policy requirements, causing upload requests to be blocked before reaching the upload service.<br /><br />We mitigated the incident by reverting the code change that introduced the issue.<br /><br />We are working to improve automated testing for browser-side request changes and to add monitoring/automated safeguards for upload flows to reduce our time to detection and mitigation of similar issues in the future.

We are investigating reports of impacted performance for some GitHub services.

Between February 11th 21:30 UTC and February 12th 15:40 UTC, users in Western Europe experienced degraded quality for all Next Edit Suggestions requests. Additionally, on February 12th, between 18:40 UTC and 20:30 UTC, users in Australia and South America experienced degraded quality and increased latency of up to 500ms for all Next Edit Suggestions requests. The root cause was a newly introduced regression in an upstream service dependency.<br /> <br />The incident was mitigated by failing over Next Edit Suggestions traffic to unaffected regions, which caused the increased latency. Once the regression was identified and rolled back, we restored the impacted capacity. We have improved our quality analysis tooling and are working on more robust quality impact alerting to accelerate detection of these issues in the future.

Next Edit Suggestions availability is recovering. We are continuing to monitor until fully restored.

We are experiencing degraded availability in Australia and Brazil for Copilot completions and suggestions. We are working to resolve the issue<br />

We are experiencing degraded availability in Australia for Copilot completions and suggestions. We are working to resolve the issue<br />

We are investigating reports of impacted performance for some GitHub services.

Between February 11th 21:30 UTC and February 12th 15:40 UTC, users in Western Europe experienced degraded quality for all Next Edit Suggestions requests. Additionally, on February 12th, between 18:40 UTC and 20:30 UTC, users in Australia and South America experienced degraded quality and increased latency of up to 500ms for all Next Edit Suggestions requests. The root cause was a newly introduced regression in an upstream service dependency.<br /><br />The incident was mitigated by failing over Next Edit Suggestions traffic to unaffected regions, which caused the increased latency. Once the regression was identified and rolled back, we restored the impacted capacity. We have improved our quality analysis tooling and are working on more robust quality impact alerting to accelerate detection of these issues in the future.

We are experiencing degraded availability in Western Europe for Copilot completions and suggestions. We are working to resolve the issue.<br />

We are experiencing degraded availability in some regions for Copilot completions and suggestions. We are working to resolve the issue.

We are investigating reports of impacted performance for some GitHub services.

From Feb 12, 2026 09:16:00 UTC to Feb 12, 2026 11:01 UTC, users attempting to download repository archives (tar.gz/zip) that include Git LFS objects received errors. Standard repository archives without LFS objects were not affected. On average, the archive download error rate was 0.0042% and peaked at 0.0339% of requests to the service. This was caused by deploying a corrupt configuration bundle, resulting in missing data used for network interface connections by the service.<br /><br />We mitigated the incident by applying the correct configuration to each site. We have added checks for corruption in this deployment, and will add auto-rollback detection for this service to prevent issues like this in the future.

We have resolved the issue and are seeing full recovery.

We are investigating an issue with downloading repository archives that include Git LFS objects.

We are investigating reports of impacted performance for some GitHub services.

On February 12, 2026, between 00:51 UTC and 09:35 UTC, users attempting to create or resume Codespaces experienced elevated failure rates across Europe, Asia and Australia, peaking at a 90% failure rate.<br /><br />The disconnects were triggered by a bad configuration rollout in a core networking dependency, which led to internal resource provisioning failures. We are working to improve our alerting thresholds to catch issues before they impact customers and strengthening rollout safeguards to prevent similar incidents.

Recovery looks consistent with Codespaces creating and resuming successfully across all regions. <br /><br />Thank you for your patience.

Codespaces is experiencing degraded performance. We are continuing to investigate.

We are seeing widespread recovery across all our regions. <br /><br />We will continue to monitor progress and will resolve the incident when we are confident on durable recovery.

We have identified the issue causing Codespace create/resume actions to fail and are applying a fix. This is estimated to take ~2 hours to complete but impact will begin to reduce sooner than that.<br /><br />We will continue to monitor recovery progress and will report back when more information is available.

We now understand the source of the VM create/resume failures and are working with our partners to mitigate the impact.

We are seeing an increase in Codespaces creation and resuming failures across multiple regions, primarily in EMEA. Our team are analysing the situation and are working to mitigate this impact.<br /><br />While we are working, customers are advised to create Codespaces in US East and US West regions via the "New with options..." button when creating a Codespace.<br /><br />More updates as we have them.

We are investigating reports of degraded availability for Codespaces

On February 11 between 16:37 UTC and 00:59 UTC the following day, 4.7% of workflows running on GitHub Larger Hosted Runners were delayed by an average of 37 minutes. Standard Hosted and self-hosted runners were not impacted. <br /><br />This incident was caused by capacity degradation in Central US for Larger Hosted Runners. Workloads not pinned to that region were picked up by other regions, but were delayed as those regions became saturated. Workloads configured with private networking in that region were delayed until compute capacity in that region recovered. The issue was mitigated by rebalancing capacity across internal and external workloads and general increases in capacity in affected regions to speed recovery. <br /><br />In addition to working with our compute partners on the core capacity degradation, we are working to ensure other regions are better able to absorb load with less delay to customer workloads. For pinned workflows using private networking, we are shipping support soon for customers to failover if private networking is configured in a paired region.

Actions is experiencing capacity constraints with larger hosted runners, leading to high wait times. Standard hosted labels and self-hosted runners are not impacted.<br /> <br />The issue is mitigated and we are monitoring recovery.

We're continuing to work toward mitigation with our capacity provider, and adding capacity.

Actions is experiencing capacity constraints with larger hosted runners, leading to high wait times. Standard hosted labels and self-hosted runners are not impacted.<br /><br />We're working with the capacity provider to mitigate the impact.

We are investigating reports of impacted performance for some GitHub services.

On February 11, 2026, between 13:51 UTC and 17:03 UTC, the GraphQL API experienced degraded performance due to elevated resource utilization. This resulted in incoming client requests waiting longer than normal, timing out in certain cases. During the impact window, approximately 0.65% of GraphQL requests experienced these issues, peaking at 1.06%. <br /><br />The increased load was due to an increase in query patterns that drove higher than expected resource utilization of the GraphQL API. We mitigated the incident by scaling out resource capacity and limiting the capacity available to these query patterns. <br /><br />We're improving our telemetry to identify slow usage growth and changes in GraphQL workloads. We’ve also added capacity safeguards to prevent similar incidents in the future.

We've observed recovery for the GraphQL service latency.

We're continuing to remediate the service degradation and scaling out to further mitigate the potential for latency impact.

We've identified a dependency of GraphQL that is in a degraded state and are working on remediating the issue.

We're investigating increased latency for GraphQL traffic.

We are investigating reports of degraded performance for API Requests

On February 11, 2025, between 14:30 UTC and 15:30 UTC, the Copilot service experienced degraded availability for requests to Claude Haiku 4.5. During this time, on average 10% of requests failed with 23% of sessions impacted. The issue was caused by an upstream problem from multiple external model providers that affected our ability to serve requests. <br /><br />The incident was mitigated once one of the providers resolved the issue and we rerouted capacity fully to that provider. We have improved our telemetry to improve incident observability and implemented an automated retry mechanism for requests to this model to mitigate similar future upstream incidents.

Copilot is operating normally.

The issues with our upstream model provider have been resolved, and Claude Haiku 4.5 is once again available in Copilot Chat and across IDE integrations.<br /><br />We will continue monitoring to ensure stability, but mitigation is complete.

We are experiencing degraded availability for the Claude Haiku 4.5 model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br />Other models are available and working as expected.

We are investigating reports of degraded performance for Copilot

On February 10th, 2026, between 14:35 UTC and 15:58 UTC web experiences on GitHub.com were degraded including Pull Requests and Authentication, resulting in intermittent 5xx errors and timeouts. The error rate on web traffic peaked at approximately 2%. This was due to increased load on a critical database, which caused significant memory pressure resulting in intermittent errors. <br /><br />We mitigated the incident by applying a configuration change to the database to increase available memory on the host. <br /><br />We are working to identify changes in load patterns and are reviewing the configuration of our databases to ensure there is sufficient capacity to meet growth. Additionally, we are improving monitoring and self-healing functionalities for database memory issues to reduce our time to detect and mitigation.

Pull Requests is operating normally.

We have deployed a mitigation for the issue and are observing what we believe is the start of recovery. We will continue to monitor.

We believe we have found the cause of the problem and are working on mitigation.

We continue investigating intermittent timeouts on some pages.

Pull Requests is experiencing degraded performance. We are continuing to investigate.

We are seeing intermittent timeouts on some pages and are investigating.

We are investigating reports of impacted performance for some GitHub services.

On February 9, 2026, GitHub experienced two related periods of degraded availability affecting GitHub.com, the GitHub API, GitHub Actions, Git operations, GitHub Copilot, and other services. The first period occurred between 16:12 UTC and 17:39 UTC, and the second between 18:53 UTC and 20:09 UTC. In total, users experienced approximately 2 hours and 43 minutes of degraded service across the two incidents. During both incidents, users encountered errors loading pages on GitHub.com, failures when pushing or pulling code over HTTPS, failures starting or completing GitHub Actions workflow runs, and errors using GitHub Copilot. Additional services including GitHub Issues, pull requests, webhooks, Dependabot, GitHub Pages, and GitHub Codespaces experienced intermittent errors. SSH-based Git operations were not affected during either incident. Our investigation determined that both incidents shared the same underlying cause: a configuration change to a user settings caching mechanism caused a large volume of cache rewrites to occur simultaneously. During the first incident, asynchronous rewrites overwhelmed a shared infrastructure component responsible for coordinating background work, triggering cascading failures. Increased load caused the service responsible for proxying Git operations over HTTPS to exhaust available connections, preventing it from accepting new requests. We mitigated this incident by disabling async cache rewrites and restarting the affected Git proxy service across multiple datacenters. An additional source of updates to the same cache circumvented our initial mitigations and caused the second incident. This generated a high volume of synchronous writes, causing replication delays that cascaded in a similar pattern and again exhausted the Git proxy’s connection capacity, degrading availability across multiple services. We mitigated by disabling the source of the cache rewrites and again restarting Git proxy. We know these incidents disrupted the workflows of millions of developers. While we have made substantial, long-term investments in how GitHub is built and operated to improve resilience, GitHub's availability is not yet meeting our expectations. Getting there requires deep architectural work that is already underway, as well as urgent, targeted improvements. We are taking the following immediate steps: 1. We have already optimized the caching mechanism to avoid write amplification and added self-throttling during bulk updates. 2. We are adding safeguards to ensure the caching mechanism responds more quickly to rollbacks and strengthening how changes to these caching systems are planned, validated, and rolled out with additional checks. 3. We are fixing the underlying cause of connection exhaustion in our Git HTTPS proxy layer so the proxy can recover from this failure mode automatically without requiring manual restarts. GitHub is critical infrastructure for your work, your teams, and your businesses. We're focusing on these mitigations and long-term infrastructure work so GitHub is available, at scale, when and where you need it.

Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests and Webhooks are operating normally.

We are seeing all services have returned to normal processing.

A number of services have recovered, but we are continuing to investigate issues with Dependabot, Actions, and a number of other services.<br /><br />We will continue to investigate and monitor for full recovery.

Codespaces is experiencing degraded performance. We are continuing to investigate.

We have applied mitigations and are seeing signs of recovery.<br /><br />We will continue to monitor for full recovery.

Packages is experiencing degraded performance. We are continuing to investigate.

Pull Requests is experiencing degraded performance. We are continuing to investigate.

We are seeing impact to several systems including Actions, Copilot, Issues, and Git.<br /><br />Customers may see slow and failed requests, and Actions jobs being delayed.<br /><br />We are investigating.

Webhooks is experiencing degraded performance. We are continuing to investigate.

Pages is experiencing degraded performance. We are continuing to investigate.

Actions is experiencing degraded availability. We are continuing to investigate.

We are investigating reports of degraded performance for Actions, Git Operations and Issues

GitHub experienced degraded Copilot policy propagation from enterprise to organizations between February 3 at 21:00 UTC through February 10 at 16:00 UTC. During this period, policy changes could take up to 24 hours to apply. We mitigated the issue on February 10 at 16:00 UTC after rolling back a regression that caused the delays. The propagation queue fully caught up on the delayed items by February 11 at 10:35 UTC, and policy changes now propagate normally.<br /><br />During this incident, whenever an enterprise updated a Copilot policy (including model policies), there were significant delays before those policy changes reached their child organizations and assigned users. The delay was caused by a large backlog in the background job queue responsible for propagating Copilot policy updates.<br /><br />Our investigation determined the incident was caused by a code change shipped on February 3 that increased the number of background jobs enqueued per policy update, in order to accommodate upcoming feature work. When new Copilot models launched on February 5th and 7th, triggering policy updates across many enterprises, the higher job volume overwhelmed the shared background worker queue, resulting in prolonged propagation delays. No policy updates were lost; they were queued and processed once the backlog cleared.<br /><br />We understand these delays disrupted policy management for customers using Copilot at scale and have taken the following immediate steps:<br /><br />1. Restored the optimized propagation path and put tests in place to avoid a regression.<br />2. Ensured upcoming features are compatible with this design. <br />3. Added alerting on queue depth to detect propagation backlogs immediately.<br /><br />GitHub is critical infrastructure for your work, your teams, and your businesses. We are focused on these mitigations and continued improvements so Copilot policy changes propagate reliably and quickly.<br />

Copilot is operating normally.

We're continuing to address an issue where Copilot policy updates are not propagating correctly for a subset of enterprise users. This may prevent newly enabled models from appearing when users try to access them.<br /> <br />This issue is understand and we are working to get the mitigation applied. Next update in one hour.

We're continuing to investigate an issue where Copilot policy updates are not propagating correctly for a subset of enterprise users.<br /><br />This may prevent newly enabled models from appearing when users try to access them.<br /><br />Next update in two hours.

We're continuing to investigate an issue where Copilot policy updates are not propagating correctly for a subset of enterprise users.<br /><br />This may prevent newly enabled models from appearing when users try to access them.<br /><br />Next update in two hours.

We're continuing to investigate an issue where Copilot policy updates are not propagating correctly for a subset of enterprise users.<br /><br />This may prevent newly enabled models from appearing when users try to access them.<br /><br />Next update in two hours.

We're continuing to investigate an issue where Copilot policy updates are not propagating correctly for a subset of enterprise users.<br /><br />This may prevent newly enabled models from appearing when users try to access them.

We're continuing to investigate a an issue where Copilot policy updates are not propagating correctly for all customers.<br /><br />This may prevent newly enabled models from appearing when users try to access them.

We’ve identified an issue where Copilot policy updates are not propagating correctly for some customers. This may prevent newly enabled models from appearing when users try to access them.<br /><br />The team is actively investigating the cause and working on a resolution. We will provide updates as they become available.

We are investigating reports of degraded performance for Copilot

On February 9, 2026, GitHub experienced two related periods of degraded availability affecting GitHub.com, the GitHub API, GitHub Actions, Git operations, GitHub Copilot, and other services. The first period occurred between 16:12 UTC and 17:39 UTC, and the second between 18:53 UTC and 20:09 UTC. In total, users experienced approximately 2 hours and 43 minutes of degraded service across the two incidents. During both incidents, users encountered errors loading pages on GitHub.com, failures when pushing or pulling code over HTTPS, failures starting or completing GitHub Actions workflow runs, and errors using GitHub Copilot. Additional services including GitHub Issues, pull requests, webhooks, Dependabot, GitHub Pages, and GitHub Codespaces experienced intermittent errors. SSH-based Git operations were not affected during either incident. Our investigation determined that both incidents shared the same underlying cause: a configuration change to a user settings caching mechanism caused a large volume of cache rewrites to occur simultaneously. During the first incident, asynchronous rewrites overwhelmed a shared infrastructure component responsible for coordinating background work, triggering cascading failures. Increased load caused the service responsible for proxying Git operations over HTTPS to exhaust available connections, preventing it from accepting new requests. We mitigated this incident by disabling async cache rewrites and restarting the affected Git proxy service across multiple datacenters. An additional source of updates to the same cache circumvented our initial mitigations and caused the second incident. This generated a high volume of synchronous writes, causing replication delays that cascaded in a similar pattern and again exhausted the Git proxy’s connection capacity, degrading availability across multiple services. We mitigated by disabling the source of the cache rewrites and again restarting Git proxy. We know these incidents disrupted the workflows of millions of developers. While we have made substantial, long-term investments in how GitHub is built and operated to improve resilience, GitHub's availability is not yet meeting our expectations. Getting there requires deep architectural work that is already underway, as well as urgent, targeted improvements. We are taking the following immediate steps: 1. We have already optimized the caching mechanism to avoid write amplification and added self-throttling during bulk updates. 2. We are adding safeguards to ensure the caching mechanism responds more quickly to rollbacks and strengthening how changes to these caching systems are planned, validated, and rolled out with additional checks. 3. We are fixing the underlying cause of connection exhaustion in our Git HTTPS proxy layer so the proxy can recover from this failure mode automatically without requiring manual restarts. GitHub is critical infrastructure for your work, your teams, and your businesses. We're focusing on these mitigations and long-term infrastructure work so GitHub is available, at scale, when and where you need it.

Pull Requests is operating normally.

Webhooks is operating normally.

Actions is operating normally.

We are seeing recovery across all products and are continuing to monitor service health.

Pages is operating normally.

Git Operations is operating normally.

Issues is operating normally.

Pages is experiencing degraded performance. We are continuing to investigate.

We have identified the cause of high error rates and taken steps to mitigate. We see early signs of recovery but are continuing to monitor impact.

Issues is experiencing degraded performance. We are continuing to investigate.

Webhooks is experiencing degraded performance. We are continuing to investigate.

Git Operations is experiencing degraded performance. We are continuing to investigate.

Actions is experiencing degraded performance. We are continuing to investigate.

We are seeing intermittent errors on many pages and API requests and are investigating.

Issues is experiencing degraded availability. We are continuing to investigate.

We are investigating reports of degraded performance for Pull Requests

On February 9th notifications service started showing degradation around 13:50 UTC, resulting in an increase in notification delivery delays. Our team started investigating. <br /><br />Around 14:30 UTC the service started to recover as the team continued investigating the incident. Around 15:20 UTC degradation resurfaced, with increasing delays in notification deliveries and small error rate (below 1%) on UI and API endpoints related to notifications. <br /><br />At 16:30 UTC, we mitigated the incident by reducing contention through throttling workloads and performing a database failover. The median delay for notification deliveries was 80 minutes at this point and queues started emptying. Around 19:30 UTC the backlog of notifications was processed, bringing the service back to normal and declaring the incident closed.<br /><br />The incident was caused by the notifications database showing degradation under intense load. Most notifications-related asynchronous workloads, including notifications deliveries, were stopped to try to reduce the pressure on the database. To ensure system stability, a database failover was executed. Following the failover, we applied a configuration change to improve the performance. The service started recovering after these changes.<br /><br />We are reviewing the configuration of our databases to understand the performance drop and prevent similar issues from happening in the future. We are also investing in monitoring to detect and mitigate this class of incidents faster.

We continue observing recovery of the notifications. Notification delivery delays have been resolved.

We are continuing to recover from notification delivery delays. Notifications are currently being delivered with an average delay of approximately 15 minutes. We are working through the remaining backlog.

We are continuing to recover from notification delivery delays. Notifications are currently being delivered with an average delay of approximately 30 minutes. We are working through the remaining backlog.

We are seeing recovery in notification delivery. Notifications are currently being delivered with an average delay of approximately 1 hour as we work through the backlog. We continue to monitor the situation closely.

We continue to investigate delays in notification delivery with average delivery latency now nearing 1 hour 20 minutes. We are just now starting to see some signs of recovery.

We are investigating notification delivery delays with the current delay being around 50 minutes. We are working on mitigation.

We are investigating reports of impacted performance for some GitHub services.

On February 9th, 2026, between 09:16 UTC and 15:12 UTC GitHub Actions customers experienced run start delays. Approximately 0.6% of runs across 1.8% of repos were affected, with an average delay of 19 minutes for those delayed runs.<br /><br />The incident occurred when increased load exposed a bottleneck in our event publishing system, causing one compute node to fall behind on processing Actions Jobs. We mitigated by rebalancing traffic and increasing timeouts for event processing. We have since isolated performance critical events to a new, dedicated publisher to prevent contention between events and added safeguards to better tolerate processing timeouts.

Actions is operating normally.

Actions run delays have returned to normal levels.

We identified a bottleneck in our processing pipeline and have applied mitigations. We will continue to monitor for full recovery.

We continue to investigate an issue causing Actions run start delays, impacting approximately 4% of users.

We are investigating an issue with Actions run start delays, impacting approximately 4% of users.

We are investigating reports of degraded performance for Actions

On February 9, 2026, between ~06:00 UTC and ~12:12 UTC, Copilot Coding Agent and related Copilot API endpoints experienced degraded availability. The primary impact was to agent-based workflows (requests to /agents/swe/*, including custom agent configuration checks), where 154k users saw failed requests and error responses in their editor/agent experience. Impact was concentrated among users and integrations actively using Copilot Coding Agent with VS Code. <br /><br />The degradation was caused by an unexpected surge in traffic to the related API endpoints that exceeded an internal secondary rate limit. That resulted in upstream request denials which were surfaced to users as elevated 500 errors.<br /><br />We mitigated the incident by deploying a change that increased the applicable rate limit for this traffic, which allowed requests to complete successfully and returned the service to normal operation.<br /><br />After the mitigation, we deployed guardrails with applicable caching to avoid a repeat of similar incidents. We also temporarily increased infrastructure capacity to better handle backlog recovery from the rate limiting. We're are improving monitoring around growing agentic API endpoints.

We are continuing to investigate the degraded availability for Copilot Coding Agent.

We are investigating degraded availability for Copilot Coding Agent. We will continue to keep users updated on progress towards mitigation.

We are investigating reports of impacted performance for some GitHub services.

On February 9, 2026, between 07:05 UTC and 11:26 UTC, GitHub experienced intermittent degradation across Issues, Pull Requests, Webhooks, Actions, and Git operations. Approximately every 30 minutes, users encountered brief periods of elevated errors and timeouts lasting roughly 15 seconds each. During the incident window, approximately 1–2% of requests were impacted across these services, with Git operations experiencing up to 7% error rates during individual spikes. GitHub Actions saw up to 2% of workflow runs delayed by a median of approximately 7 minutes due to backups created during these periods. <br /><br />This was due to multiple resource-intensive workloads running simultaneously, which caused intermittent processing delays on the data storage layer. We mitigated the incident by scaling storage to a larger compute capacity, which resolved the processing delays. <br /><br />We are working to improve detection of resource-intensive queries, identify changes in load patterns, and enhance our monitoring to reduce our time to detection and mitigation of issues like this one in the future.

Actions is operating normally.

Issues is operating normally.

Webhooks is operating normally.

Pull Requests is operating normally.

We have identified a faulty infrastructure component and have failed over to a healthy instance. We are continuing to monitor the system for recovery.

Git Operations is operating normally.

We are continuing to investigate intermittent elevated timeouts across the service.

Git Operations is experiencing degraded performance. We are continuing to investigate.

We are continuing to investigate intermittent elevated timeouts across the service.

We are continuing to investigate intermittent elevated timeouts across the service. Current impact is estimated around 1% or less of requests.

Actions is experiencing degraded performance. We are continuing to investigate.

We are continuing to investigate intermittent elevated timeouts.

We are investigating intermittent latency and errors with Webhooks API, Webhooks UI, and PRs. We will continue to keep users updated on progress towards mitigation.

Issues is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of degraded performance for Pull Requests and Webhooks

On February 6, 2026, between 17:49 UTC and 18:36 UTC, the GitHub Mobile service was degraded, and some users were unable to create pull request review comments on deleted lines (and in some cases, comments on deleted files). This impacted users on the newer comment-positioning flow available in version 1.244.0 of the mobile apps. Telemetry indicated that the failures increased as the Android rollout progressed. This was due to a defect in the new comment-positioning workflow that could result in the server rejecting comment creation for certain deleted-line positions.<br /><br />We mitigated the incident by halting the Android rollout and implementing interim client-side fallback behavior while a platform fix is in progress. The client-side fallback is scheduled to be published early this week. We are working to (1) add clearer client-side error handling (avoid infinite spinners), (2) improve monitoring/alerting for these failures, and (3) adopt stable diff identifiers for diff-based operations to reduce the likelihood of recurrence.

Some GitHub Mobile app users may be unable to add review comments on deleted lines in pull requests. We're working on a fix and expect to release it early next week.

Pull Requests is operating normally.

We're currently investigating an issue affecting the Mobile app that can prevent review comments from being posted on certain pull requests when commenting on deleted lines.

We are investigating reports of degraded performance for Pull Requests

On February 10, 2026, between 10:28 and 11:54 UTC, Visual Studio Code users experienced a degraded experience on GitHub Copilot when using the Claude Opus 4.6 model. During this time, approximately 50% of users encountered agent turn failures due to the model being unable to serve the volume of incoming requests.<br /><br />Rate limits set too low for actual demand caused the issue. While the initial deployment showed no concerns, a surge in traffic from Europe on the following day caused VSCode to begin hitting rate limit errors. Additionally, a degradation message intended to notify users of high usage failed to trigger due to a misconfiguration. We mitigated the incident by adjusting rate limits for the model.<br /><br />We improved our rate limiting to prevent future models from experiencing similar issues. We are also improving our capacity planning processes to reduce the risk of similar incidents in the future, and enhancing our detection and mitigation capabilities to reduce impact to customers.

Copilot is operating normally.

We have increased capacity and are seeing recovery.

Opus 4.6 is currently experiencing high demand and we are working on adding capacity.

We are investigating reports of degraded performance for Copilot

On February 3, 2026, between 14:00 UTC and 17:40 UTC, customers experienced delays in Webhook delivery for push events and delayed GitHub Actions workflow runs. During this window, Webhook deliveries for push events were delayed by up to 40 minutes, with an average delay of 10 minutes. GitHub Actions workflows triggered by push events experienced similar job start delays. Additionally, between 15:25 UTC and 16:05 UTC, all GitHub Actions workflow runs experienced status update delays of up to 11 minutes, with a median delay of 6 minutes.<br /><br />The issue stemmed from connection churn in our eventing service, which caused CPU saturation and delays for reads and writes, with subsequent downstream delivery delays for Actions and Webhooks. We have added observability tooling and metrics to accelerate detection, and are correcting stream processing client configuration to prevent recurrence.

Our telemetry shows improvement on latency in job status updates. We will continue monitoring until full recovery.

We've applied a mitigation to improve system throughput and are monitoring for reduced latency for job status updates.

We are investigating reports of degraded performance for Actions

On February 3, 2026, between 09:35 UTC and 10:15 UTC, GitHub Copilot experienced elevated error rates, with an average of 4% of requests failing.<br /><br />This was caused by a capacity imbalance that led to resource exhaustion on backend services. The incident was resolved by infrastructure rebalancing, and we subsequently deployed additional capacity.<br /><br />We are improving observability to detect capacity imbalances earlier and enhancing our infrastructure to better handle traffic spikes.

We are now seeing recovery.

We are investigating elevated 500s across Copilot services.

We are investigating reports of degraded performance for Copilot

On February 2, 2026, GitHub Codespaces were unavailable between 18:55 and 22:20 UTC and degraded until the service fully recovered at February 3, 2026 00:15 UTC. During this time, Codespaces creation and resume operations failed in all regions. <br /><br />This outage was caused by a backend storage access policy change in our underlying compute provider that blocked access to critical VM metadata, causing all VM create, delete, reimage, and other operations to fail. More information is available at https://azure.status.microsoft/en-us/status/history/?trackingId=FNJ8-VQZ. This was mitigated by rolling back the policy change, which started at 22:15 UTC. As VMs came back online, our runners worked through the backlog of requests that hadn’t timed out. <br /><br />We are working with our compute provider to improve our incident response and engagement time, improve early detection before they impact our customers, and ensure safe rollout should similar changes occur in the future. We recognize this was a significant outage to our users that rely on GitHub’s workloads and apologize for the impact this had.

Codespaces is operating normally.

Codespaces is experiencing degraded performance. We are continuing to investigate.

Codespaces is seeing steady recovery

Users may see errors creating or resuming codespaces. We are investigating and will provide further updates as we have them.

We are investigating reports of degraded availability for Codespaces

On February 2, 2026, between 18:35 UTC and 22:15 UTC, GitHub Actions hosted runners were unavailable, with service degraded until full recovery at 23:10 UTC for standard runners and at February 3, 2026 00:30 UTC for larger runners. During this time, Actions jobs queued and timed out while waiting to acquire a hosted runner. Other GitHub features that leverage this compute infrastructure were similarly impacted, including Copilot Coding Agent, Copilot Code Review, CodeQL, Dependabot, GitHub Enterprise Importer, and Pages. All regions and runner types were impacted. Self-hosted runners on other providers were not impacted. <br /><br />This outage was caused by a backend storage access policy change in our underlying compute provider that blocked access to critical VM metadata, causing all VM create, delete, reimage, and other operations to fail. More information is available at https://azure.status.microsoft/en-us/status/history/?trackingId=FNJ8-VQZ. This was mitigated by rolling back the policy change, which started at 22:15 UTC. As VMs came back online, our runners worked through the backlog of requests that hadn’t timed out. <br /><br />We are working with our compute provider to improve our incident response and engagement time, improve early detection before they impact our customers, and ensure safe rollout should similar changes occur in the future. We recognize this was a significant outage to our users that rely on GitHub’s workloads and apologize for the impact this had.

Actions is operating normally.

Based on our telemetry, most customers should see full recovery from failing GitHub Actions jobs on hosted runners.<br />We are monitoring closely to confirm complete recovery.<br />Other GitHub features that rely on GitHub Actions (for example, Copilot Coding Agent and Dependabot) should also see recovery.

Actions is experiencing degraded performance. We are continuing to investigate.

Copilot is operating normally.

Pages is operating normally.

Our upstream provider has applied a mitigation to address queuing and job failures on hosted runners.<br />Telemetry shows improvement, and we are monitoring closely for full recovery.

We continue to investigate failures impacting GitHub Actions hosted-runner jobs.<br />We're waiting on our upstream provider to apply the identified mitigations, and we're preparing to resume job processing as safely as possible.

Copilot is experiencing degraded performance. We are continuing to investigate.

We continue to investigate failures impacting GitHub Actions hosted-runner jobs.<br />We have identified the root cause and are working with our upstream provider to mitigate.<br />This is also impacting GitHub features that rely on GitHub Actions (for example, Copilot Coding Agent and Dependabot).

The team continues to investigate issues causing GitHub Actions jobs on hosted runners to remain queued for extended periods, with a percentage of jobs failing. We will continue to provide updates as we make progress toward mitigation.<br />

Pages is experiencing degraded performance. We are continuing to investigate.

The team continues to investigate issues causing GitHub Actions jobs on hosted runners to remain queued for extended periods, with a percentage of jobs failing. We will continue to provide updates as we make progress toward mitigation.

Actions is experiencing degraded availability. We are continuing to investigate.

GitHub Actions hosted runners are experiencing high wait times across all labels. Self-hosted runners are not impacted.

We are investigating reports of degraded performance for Actions

From Jan 31, 2026 00:30 UTC to Feb 2, 2026 18:00 UTC Dependabot service was degraded and failed to create 10% of Automated Pull Requests. This was due to a cluster failover that connected to a read-only database.<br /><br />We mitigated the incident by pausing Dependabot queues until traffic was properly routed to healthy clusters. We’re working on identifying and rerunning all failed jobs during this time.<br /><br />We’re adding new monitors and alerts to reduce our time to detection and prevent this in the future.

Dependabot is currently experiencing an issue that may cause scheduled update jobs to fail when creating pull requests.<br /><br />Our team has identified the problem and deployed a fix. We’re seeing signs of recovery and expect full resolution within the next few hours.

We are investigating reports of impacted performance for some GitHub services.

From Feb 2, 2026 17:13 UTC to Feb 2, 2026 17:36 UTC we experienced failures on ~0.02% of Git operations. While deploying an internal service, a misconfiguration caused a small subset of traffic to route to a service that was not ready. During the incident we observed the degradation and statused publicly.<br /><br />To mitigate the issue, traffic was redirected to healthy instances and we resumed normal operation.<br /><br />We are improving our monitoring and deployment processes in this area to avoid future routing issues.

We’ve observed a low rate (~0.01%) of 5xx errors for HTTP-based fetches and clones. We’re currently routing traffic away from the affected location and are seeing recovery.

Git Operations is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

Between 2026-01-30 19:06 UTC and 2026-01-30 20:04 UTC, Copilot Coding Agent experienced sessions getting stuck, with a mismatch between the UI-reported session status and the underlying Actions and job execution state. Impacted users could observe Actions finish successfully but the session UI continuing to show in-progress state, or sessions remaining in queued state.<br /><br />The issue was caused by a feature flag that resulted in events being published to a new Kafka topic. Publishing failures led to buffer/queue overflows in the shared event publishing client, preventing other critical events from being emitted. We mitigated the incident by disabling the feature flag and redeploying production pods, which resumed normal event delivery. We are working to improve safeguards and detection around event publishing failures to reduce time to mitigation for similar issues in the future.

Customers may experience misreported Copilot Coding Agent tasks in the GitHub UI. Although the underlying actions are completing as requested, surfaces like Agent Sessions on the GitHub website, or Agent Hub in VS Code, will show that an agent is still working on a task, even if that work has completed. <br /><br />We are working to understand the root cause and mitigate these discrepancies.

We are investigating reports of degraded performance for Actions

On Jan 28, 2026, between 14:56 UTC and 15:44 UTC, GitHub Actions experienced degraded performance. During this time, workflows experienced an average delay of 49 seconds, and 4.7% of workflow runs failed to start within 5 minutes. The root cause was an atypical load pattern that overwhelmed system capacity and caused resource contention.<br /><br />Recovery began once additional resources came online at 15:25 UTC, with full recovery at 15:44 UTC. We are implementing safeguards to prevent this failure mode and enhancing our monitoring to detect and address similar patterns more quickly in the future.

Actions workflow run starts are delayed. We are actively investigating to find a mitigation.

We are investigating reports of degraded performance for Actions

On Jan 26, 2026, from approximately 14:03 UTC to 23:42 UTC, GitHub Actions experienced job failures on some Windows standard hosted runners. This was caused by a configuration difference in a new Windows runner type that caused the expected D: drive to be missing. About 2.5% of all Windows standard runners jobs were impacted. Re-run of failed workflows had a high chance of succeeding given the limited rollout of the change.<br /><br />The job failures were mitigated by rolling back the affected configuration and removing the provisioned runners that had this configuration. To reduce the chance of recurrence, we are expanding runner telemetry and improving validation of runner configuration changes. We are also evaluating options to accelerate the mitigation time of any similar future events.

At 23:45 UTC we applied a mitigation to take remaining impacted capacity offline and are seeing improvement. We will update again once we've confirmed the issue is resolved.

Our investigation into GitHub Actions 4 Core Windows runner failures in public repositories is ongoing.<br /><br />If you have a failing GitHub Actions run, please retry it and it is likely to succeed.

We're continuing to investigate failures in GitHub Actions 4 Core Windows runners in public repositories. <br /><br />If you have a failing GitHub Actions run, please retry it and it is likely to succeed.

Rollback has been completed, but we are still seeing failures on about 11% of GitHub Actions runs on 4 Core Windows runners in public repositories.<br /><br />If your workflow fails to start, try re-running and it is likely to work a second time.

Mitigation for failing GitHub Actions jobs on 4-Core Windows runners is still being mitigated. You should start to see more runs succeeding.<br />If you do see failing runs, please retry and they might succeed.

We've applied a mitigation to unblock running Actions. A regression occurred for Windows runners in public repositories which caused Actions workflows to fail. A mitigation is in place and customers should expect to see resolution soon.<br /><br />If you have a failing Actions workflow on a Windows runner, please retry and it is likely to work.

We are investigating reports of impacted performance for some GitHub services.

Between January 24, 2026,19:56 UTC and January 25, 2026, 2:50 UTC repository creation and clone were degraded. On average, the error rate was 25% and peaked at 55% of requests for repository creation. This was due to increased latency on the repositories database impacting a read-after-write problem during repo creation. We mitigated the incident by stopping an operation that was generating load on the database to increase throughput. <br /><br />We have identified the repository creation problem and are working to address the issue and improve our observability to reduce our time to detection and mitigation of issues like this one in the future.<br />

The issue has been resolved. We will continue to monitor to ensure stability.

Repo creation failure rate increased above 50%. We have mitigated the problem and are monitoring for recovery.

We are investigating reports of impacted performance for some GitHub services.

On January 22, 2026, our authentication service experienced an issue between 14:00 UTC and 14:50 UTC, resulting in downstream disruptions for users.<br /><br />From 14:00 UTC to 14:23 UTC, authenticated API requests experienced higher-than-normal error rates, with an average of 16.9% and occasional peaks up to 22.2% resulting in HTTP 401 responses for authenticated API requests. <br /><br />From 14:00 UTC to 14:50 UTC, git operations over HTTP were impacted, with error rates averaging 3.8% and peaking at 10.8%. As a result, some users may have been unable to run git commands as expected.<br /><br />This was due to the authentication service reaching the maximum allowed number of database connections. We mitigated the incident by increasing the maximum number of database connections in the authentication service.<br /><br />We are adding additional monitoring around database connection pool usage and improving our traffic projection to reduce our time to detection and mitigation of issues like this one in the future.<br />

We have identified an issue in one of our services and have mitigated it. Services have recovered and we have a mitigation but we are working on a longer term solution.

Issues is operating normally.

Issues is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

On January 21, between 17:50 and 20:53 UTC, around 350 enterprises and organizations experienced slower load times or timeouts when viewing Copilot policy pages. The issue was traced to performance degradation under load due to an issue in upstream database caching capability within our billing infrastructure, which increased query latency to retrieve billing and policy information from approximately 300ms to up to 1.5s.<br /><br />To restore service, we disabled the affected caching feature, which immediately returned performance to normal. We then addressed the issue in the caching capability and re-enabled our use of the database cache and observed continued recovery.<br /><br />Moving forward, we’re tightening our procedures for deploying performance optimizations, adding test coverage, and improving cross-service visibility and alerting so we can detect upstream degradations earlier and reduce impact to customers.

We are rolling out a fix to reduce latency and timeouts on policy pages and are continuing to monitor impact.

We are continuing to investigate latency and timeout issues affecting Copilot policy pages.

We are investigating timeouts for customers visiting the Copilot policy pages for organizations and enterprises.

We are investigating reports of impacted performance for some GitHub services.

On Jan 21st, 2025, between 11:15 UTC and 13:00 UTC the Copilot service was degraded for Grok Code Fast 1 model. On average, more than 90% of the requests to this model failed due to an issue with an upstream provider. No other models were impacted.<br /><br />The issue was resolved after the upstream provider fixed the problem that caused the disruption. GitHub will continue to enhance our monitoring and alerting systems to reduce the time it takes to detect and mitigate similar issues in the future.

We are experiencing degraded availability for the Grok Code Fast 1 model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br /><br />Other models are available and working as expected.

We are investigating reports of degraded performance for Copilot

On January 20, 2026, between 19:08 UTC and 20:18 UTC, manually dispatched GitHub Actions workflows saw delayed job starts. GitHub products built on Actions such as Dependabot, Pages builds, and Copilot coding agent experienced similar delays. All jobs successfully completed despite the delays. At peak impact, approximately 23% of workflow runs were affected, with an average delay of 11 minutes.<br /><br />This was caused by a load pattern shift in Actions scheduled jobs that saturated a shared backend resource. We mitigated the incident by temporarily throttling traffic and scaling up resources to account for the change in load pattern. To prevent recurrence, we have scaled resources appropriately and implemented optimizations to prevent this load pattern in the future.

We are investigating delays in manually dispatched Actions workflows as well as other GitHub products which run on Actions. We have identified a fix and are working on mitigating the delays.

We are investigating reports of degraded performance for Actions

On January 20, 2026, between 14:39 UTC and 16:03 UTC, actions-runner-controller users experienced a 1% failure rate for API requests managing GitHub Actions runner scale sets. This caused delays in runner creation, resulting in delayed job starts for workflows targeting those runners. The root cause was a service to service circuit breaker that incorrectly tripped for all users when a single user hit rate limits for runner registration. The issue was mitigated by bypassing the circuit breaker, and users saw immediate and full service recovery following the fix.<br /><br />We have updated our circuit breakers to exclude individual customer rate limits from their triggering logic and are continuing work to improve detection and mitigation times.

GitHub Actions customers that use actions-runner-controller are experiencing errors from our APIs that informs auto-scaling. We are investigating the issue and working on mitigating the impact.

We are investigating reports of degraded performance for Actions

Between 2026-01-16 16:17 and 2026-01-17 02:54 UTC, some Copilot Business users were unable to access and use certain Copilot features and models. This was due to a bug with how we determine if a user has access to a feature, inadvertently marking features and models as inaccessible for users whose enterprise(s) had not configured the policy.<br /><br />We mitigated the incident by reverting the problematic deployment. We are improving our internal monitoring and mitigation processes to reduce the risk and extended downtime of similar incidents in the future.<br />

The fix has been deployed and the issue resolved. We will continue to monitor any incoming reports.

The deployment of the fix is still ongoing. We are now targeting 3:00 AM UTC for full resolution.

The deployment is still in progress. We are still targeting 2:00 AM UTC for full resolution.

Deployment of the fix is in progress. We are still targetting 2:00 AM UTC for full resolution.

Some enterprise Copilot CLI users may encounter an "You are not authorized to use this Copilot feature" error. We have identified the root cause and are currently deploying a fix. Expected resolution: within 2 hours.

We received multiple reports of 403s when attempting to use the Copilot CLI. We have identified the root cause and are rolling out a fix for affected customers.

We are investigating reports of impacted performance for some GitHub services.

On January 15, 2026, between 16:40 UTC and 18:20 UTC, we observed increased latency and timeouts across Issues, Pull Requests, Notifications, Actions, Repositories, API, Account Login and Alive. An average 1.8% of combined web and API requests saw failure, peaking briefly at 10% early on. The majority of impact was observed for unauthenticated users, but authenticated users were impacted as well.<br /><br />This was caused by an infrastructure update to some of our data stores. Upgrading this infrastructure to a new major version resulted in unexpected resource contention, leading to distributed impact in the form of slow queries and increased timeouts across services that depend on these datasets. We mitigated this by rolling back to the previous stable version.<br /><br />We are working to improve our validation process for these types of upgrades to catch issues that only occur under high load before full release, improve detection time, and reduce mitigation times in the future.

Pull Requests is operating normally.

Issues and Pull Requests are experiencing degraded performance. We are continuing to investigate.

We are seeing recovery across all services, but will continue to monitor before resolving.

API Requests is operating normally.

We are seeing some signs of recovery, particularly for authenticated users. Unauthenticated users may continue to see impact across multiple services. Mitigation efforts continue.

API Requests is experiencing degraded performance. We are continuing to investigate.

Actions is operating normally.

A number of services are currently degraded, especially issues, pull requests, and the API. Investigation and mitigation is underway.

Actions is experiencing degraded availability. We are continuing to investigate.

API Requests is experiencing degraded availability. We are continuing to investigate.

We are investigating reports of degraded availability for API Requests, Actions, Issues and Pull Requests

On January 15th, between 14:18 UTC and 15:26 UTC, customers experienced delays in status updates for workflow runs and checks. Status updates were delayed by up to 20 minutes, with a median delay of 11 minutes.<br /><br />The issue stemmed from an infrastructure upgrade to our database cluster. The new version introduced resource contention under production load, causing slow query times. We mitigated this by rolling back to the previous stable version. We are working to strengthen our upgrade validation process to catch issues that only manifest under high load. We are also adding new monitors to reduce detection time for similar issues in the future.

We are continuing to monitor as the system recovers and expect full recovery within the next 20-30 minutes. Impacted users will see that job status appears queued, though the job itself is actually running.

We are seeing signs of recovery and are continuing to monitor as we process the backlog of events.

We are investigating reports of degraded performance for Actions

On January 14, 2026, between 19:34 UTC and 21:36 UTC, the Webhooks service experienced a degradation that delayed delivery of some webhooks. During this window, a subset of webhook deliveries that encountered proxy tunnel errors on their initial delivery attempt were delayed by more than two minutes. The root cause was a recent code change that added additional retry attempts for this specific error condition, which increased delivery times for affected webhooks. Previously, webhook deliveries encountering this error would not have been delivered.<br /><br />The incident was mitigated by rolling back the change, restoring normal webhook delivery. <br /><br />As a corrective action, we will update our monitoring to measure the webhook delivery latency critical path, ensuring that incidents are accurately scoped to this workflow.

Some webhook deliveries are delayed, but we don’t expect meaningful user impact. The delays are currently scoped only to deliveries that, until recently, would have failed more quickly. We will update status if conditions change.

We are investigating reports of degraded performance for Webhooks

From January 14, 2026, at 18:15 UTC until January 15, 2026, at 11:30 UTC, GitHub Copilot users were unable to select the GPT-5 model for chat features in VS Code, JetBrains IDEs, and other IDE integrations. Users running GPT-5 in Auto mode experienced errors. Other models were not impacted. We mitigated this incident by deploying a fix that corrected a misconfiguration in available models, rendering the GPT-5 model available again. We are improving our testing processes to reduce the risk of similar incidents in the future, and refining our model availability alerting to improve detection time. We did not status before we completed the fix, and the incident is currently resolved. We are sorry for the delayed post on githubstatus.com.

On January 14th, 2026, between approximately 10:20 and 11:25 UTC, the Copilot service experienced a degradation of the Claude Opus 4.5 model due to an issue with our upstream provider. During this time period, users encountered a 4.5% error rate when using Claude Opus 4.5. No other models were impacted.<br />The issue was resolved by a mitigation put in place by our provider. GitHub is working with our provider to further improve the resiliency of the service to prevent similar incidents in the future.

We are continuing to investigate issues with Claude Opus 4.5 and are working to restore performance across our model providers.

We are experiencing issues with our Claude Opus 4.5 providers and are investigating remediation.

We are investigating reports of impacted performance for some GitHub services.

This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

We are continuing to investigate issues with the GPT-5.1 model. We are also seeing an increase in failures for Copilot Code Reviews.

We are continuing to investigate issues with the GPT-5.1 model with our model provider. Uses of other models are not impacted.

Copilot is experiencing degraded performance when using the GPT-5.1 model. We are investigating the issue.

We are investigating reports of degraded performance for Copilot

Between 2026-01-13 22:20 and 2026-01-14 00:18 UTC, GitHub Code Search experienced an increase in latency and request timeouts. This was caused by some network transit links between GitHub and Azure Express Route experiencing a small error rate that contributed to applications requests failing, increasing application latency and timeouts. The incident resulted in less than 1% of requests to fail due to timeouts.<br /><br />We mitigated the incident by disabling the links in question. Monitoring each unique network path across providers would have allowed us to mitigate this earlier. We are running root cause analysis with network providers to help us reduce time-to-discover and time-to-mitigate.

We are continuing to investigate increased latency with code search service.

We are investigating reports of increased latency with code search. We will continue to keep users updated on progress towards mitigation.

We are investigating reports of impacted performance for some GitHub services.

On January 13th, 2026, between 09:25 UTC and 10:11 UTC, GitHub Copilot experienced unavailability. During this window, error rates averaged 18% and peaked at 100% of service requests, leading to an outage of chat features across Copilot Chat, VS Code, JetBrains IDEs, and other Copilot-dependent products. <br /><br />This incident was triggered by a configuration error during a model update. We mitigated the incident by rolling back this change. However, a second recovery phase lasted until 10:46 UTC, due to unexpected latency with the GPT 4.1 model. To prevent recurrence, we are investing in new monitors and more robust testing environments to reduce further misconfigurations, and to improve our time to detection and mitigation of future issues.

Copilot is operating normally.

We are seeing recovery in the GPT-4.1 model. We continue to monitor for full recovery.

We are seeing continued recovery across Copilot services but continue to see issues with the GPT-4.1 model that we are investigating.

We are seeing continued recovery across Copilot services but continue to see issues with the GPT-4.1 model that we are investigating.

We have identified what we believe to be a configuration issue that may explain the issue. We have rolled back this change and are starting to see signs of recovery.

We are investigating an issue that is causing failures in all Copilot requests.

Copilot is experiencing degraded availability. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

From January 9 13:11 UTC to January 12 10:17 UTC, new Linux Custom Images generated for Larger Hosted Runners were broken and not able to run jobs. Customers who did not generate new Custom Images during this period were not impacted. This issue was caused by a change to improve reliability of the image creation process. Due to a bug, the change triggered an unrelated protection mechanism which determines if setup has already been attempted on the VM and caused the VM to be marked unhealthy. Only Linux images which were generated while the change was enabled were impacted. The issue was mitigated by rolling back the change.<br /><br />We are improving our testing around Custom Image generation as part of our GA readiness process for the public preview feature.. This includes expanding our canary suite to detect this and similar interactions as part of a controlled rollout in staging prior to any customer impact.

Actions jobs that use custom Linux images are failing to start. We've identified the underlying issue and are working on mitigation.

Actions is experiencing degraded performance. We are continuing to investigate.

We are investigating reports of impacted performance for some GitHub services.

From January 5, 2026, 00:00 UTC to January 10, 2026, 02:30 UTC, customers using the AI Controls public preview feature experienced delays in viewing Copilot agent session data. Newly created sessions took progressively longer to appear, initially hours, then eventually exceeding 24 hours. Since the page displays only the most recent 24 hours of activity, once processing delays exceeded this threshold, no recent data was visible. Session data remained available in audit logs throughout the incident.<br /><br />Inefficient database queries in the data processing pipeline caused significant processing latency, creating a multi-day backlog. As the backlog grew, the delay between when sessions occurred and when they appeared on the page increased, eventually exceeding the 24-hour display window.<br /><br />The issue was resolved on January 10, 2026, 02:30 UTC, after query optimizations and a database index were deployed. We are implementing enhanced monitoring and automated testing to detect inefficient queries before deployment to prevent recurrence.

Our queue has cleared. The last 24 hours of agent session history should now be visible on the AI Controls UI. No data was lost due to this incident.

We estimate the backlogged queue will take 3 hours to process. We will post another update once it is completed, or if anything changes with the recovery process.

We have deployed an additional fix and are beginning to see recovery to the queue preventing AI Sessions from showing in the AI Controls UI. We are working on an estimate for when the queue will be fully processed, and will post another update once we have that information.

We are seeing delays processing the AI Session event queue, which is causing sessions to not be displayed on the AI Controls UI. We have deployed a fix to improve the queue processing and are monitoring for effectiveness. We continue to investigate other mitigation paths.

We continue to investigate the problem with Copilot agent sessions not rendering in AI Controls.

We continue to investigate the problem with Copilot agent sessions not rendering in ai controls.

We continue to investigate the problem with Copilot agent sessions not rendering in ai controls.

We continue to investigate the problem with Copilot agent sessions not rendering in ai controls.

We continue to investigate the problem with Copilot agent sessions not rendering in ai controls.

We continue to investigate the problem with Copilot agent sessions not rendering in ai controls.

Agent Session activity is still observable in audit logs, and this only impacts the AI Controls UI.

We are investigating an incident affecting missing Agent Session data on the AI Settings page on Agent Control Plane.

We are investigating reports of impacted performance for some GitHub services.

On January 8th, 2025, between approximately 00:00 and 1:30 UTC, the Copilot service experienced a degradation of the Grok Code Fast 1 model due to an issue with our upstream provider. Users encountered elevated error rates when using Grok Code Fast 1. Approximately 4.5% of requests failed across all users during this time. No other models were impacted.<br /><br />The issue was resolved by a mitigation put in place by our provider.

The issues with our upstream model provider have been resolved, and Grok Code Fast 1 is once again available in Copilot Chat and across IDE integrations.<br /><br />We will continue monitoring to ensure stability, but mitigation is complete.

We are experiencing degraded availability for the Grok Code Fast 1 model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br /><br />Other models are available and working as expected.

We are investigating reports of degraded performance for Copilot

On January 7th, 2026, between 17:16 and 19:33 UTC Copilot Pro and Copilot Business users were unable to use certain premium models, including Claude Opus 4.5 and GPT-5.2. This was due to a misconfiguration with Copilot models, inadvertently marking these premium models as inaccessible for users with Copilot Pro and Copilot Business licenses.<br /><br />We mitigated the incident by reverting the erroneous config change. We are improving our testing processes to reduce the risk of similar incidents in the future, and refining our model availability alerting to improve detection time.

We have implemented a mitigation and confirmed that Copilot Pro and Business accounts now have access to the previously missing models. We will continue monitoring to ensure complete resolution.

We continue to investigate. We'll post another update by 19:50 UTC.

Correction - Copilot Pro and Business users are impacted. Copilot Pro+ and Enterprise users are not impacted.

We continue to investigate this problem and have confirmed only Copilot Business users are impacted. We'll post another update by 19:30 UTC.

We are currently investigating reports of some Copilot Pro premium models including Opus and GPT 5.2 being unavailable in Copilot products. We'll post another update by 19:08 UTC.

We have received reports that some expected models are missing from VSCode and other products using Copilot. We are investigating the cause of this to restore access.

We are investigating reports of degraded performance for Copilot

On January 6, 2026 between 12:55 UTC and 17:04 UTC, the ability to download Actions artifacts from GitHub’s web interface was degraded. During this time, all attempts to download artifacts from the web interface failed. Artifact downloads via the REST API and GitHub CLI were unaffected.<br /><br />This was due to a client-side change that was deployed to optimize performance when navigating between pages in a repository. We mitigated the incident by reverting the change. <br /><br />We are working to improve testing of related changes and to add monitoring coverage for artifact downloads through the web interface to reduce our time to detection and prevent similar incidents from occurring in the future.

We are investigating issues downloading artifacts from Actions workflows. All customers are affected when attempting to download through the web interface. We're actively working on a fix and will post another update by 17:15 UTC.

We are investigating reports of degraded performance for Actions

On January 6th, 2026, between approximately 8:41 and 10:07 UTC, the Copilot service experienced a degradation of the GPT-5.1-Codex-Max model due to an issue with our upstream provider. During this time, up to 14.17% of requests to GPT-5.1-Codex-Max failed. No other models were impacted.<br /><br />The issue was resolved by a mitigation put in place by our provider. GitHub is working with our provider to further improve the resiliency of the service to prevent similar incidents in the future.

The issues with our upstream model provider have been resolved, and GPT-5.1-Codex-Max is once again available.<br />We will continue monitoring to ensure stability.

We are experiencing degraded availability for the GPT-5.1-Codex-Max model in Copilot Chat, VS Code and other Copilot products. This is due to an issue with an upstream model provider. We are working with them to resolve the issue.<br /><br />Other models are available and working as expected.

We are investigating reports of degraded performance for Copilot

On December 31, 2025, between 04:00 UTC and 22:31 UTC, all users visiting https://github.com/features/copilot were unable to load the page and were instead redirected to an error page. The issue was caused by an unexpected content change that resulted in page rendering errors. We mitigated the incident by reverting the change, which restored normal page behavior. To reduce the likelihood and duration of similar issues in the future, we are improving monitoring and alerting for increased error rates on this page and similar pages, and strengthening validation and safeguards around content updates to prevent unexpected changes from causing user-facing errors.

Our Copilot feature page (https://github.com/features/copilot) is returning 500s. We are currently investigating. This does not impact the core GitHub application.

We are investigating reports of impacted performance for some GitHub services.