Subscribe to UpdatesSubscribe
Get email notifications whenever GitHub creates, updates or resolves an incident.
Get text message notifications whenever GitHub creates or resolves an incident.
Get incident updates and maintenance status messages in Slack.
Subscribe via Slack
By subscribing you acknowledge our Privacy Policy. In addition, you agree to the Atlassian Cloud Terms of Service and acknowledge Atlassian's Privacy Policy.
Get webhook notifications whenever GitHub creates an incident, updates an incident, resolves an incident or changes a component status.
Visit our support site.
All Systems Operational
About This Site
Check GitHub Enterprise Cloud status by region:
- Australia: au.githubstatus.com
- EU: eu.githubstatus.com
- Japan: jp.githubstatus.com
- US: us.githubstatus.com
Uptime over the past 90 days. View historical uptime.
Git Operations
Operational
90 days ago
99.78
% uptime
Today
Webhooks
Operational
90 days ago
99.66
% uptime
Today
Visit www.githubstatus.com for more information
Operational
API Requests
Operational
90 days ago
99.95
% uptime
Today
Issues
Operational
90 days ago
99.77
% uptime
Today
Pull Requests
Operational
90 days ago
99.58
% uptime
Today
Actions
Operational
90 days ago
99.59
% uptime
Today
Packages
Operational
90 days ago
99.97
% uptime
Today
Pages
Operational
90 days ago
99.95
% uptime
Today
Copilot
Operational
90 days ago
99.73
% uptime
Today
Codespaces
Operational
90 days ago
99.67
% uptime
Today
Copilot AI Model Providers
Operational
90 days ago
100.0
% uptime
Today
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
No data exists for this day.
had a major outage.
had a partial outage.
Related
No incidents or maintenance related to this downtime.
Past Incidents
May 6, 2026
No incidents reported today.
May 5, 2026
Resolved -
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.
May 5, 18:35 UTC
May 5, 18:35 UTC
Update -
We've completed our mitigation to prevent further impact. At this time the incident is considered resolved.
May 5, 18:35 UTC
May 5, 18:35 UTC
Monitoring -
The degradation affecting Git Operations has been mitigated. We are monitoring to ensure stability.
May 5, 18:25 UTC
May 5, 18:25 UTC
Update -
We're continuing to work on preventing further impact from the earlier issue. No SSH-based impact is expected at this time. We'll post new updates if impact recurs or once our mitigation is in place.
May 5, 17:26 UTC
May 5, 17:26 UTC
Investigating -
Git Operations is experiencing degraded performance. We are continuing to investigate.
May 5, 17:23 UTC
May 5, 17:23 UTC
Monitoring -
Between approximately 14:00 and 16:10 UTC, customers using SSH-based Git operations may have experienced elevated latency and failures. HTTP-based operations were not impacted. We've identified a suspected root cause and are working to implement a mitigation to prevent further impact.
May 5, 16:54 UTC
May 5, 16:54 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
May 5, 16:49 UTC
May 5, 16:49 UTC
Resolved -
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.
May 5, 17:26 UTC
May 5, 17:26 UTC
Update -
Actions is experiencing degraded performance. We are continuing to investigate.
May 5, 17:11 UTC
May 5, 17:11 UTC
Update -
Standard hosted runners have now reached full recovery. Hosted Runners with Private Networking in the East US region remain degraded as we continue working with our compute provider to restore capacity. Hosted Runners with private networking can fail over to a different Region to mitigate the issue.
May 5, 17:11 UTC
May 5, 17:11 UTC
Update -
We've seen signs of recovery for Standard Hosted Runners and are continuing to monitor for full recovery. Hosted Runners with Private Networking in the East US region remain affected as we continue working with our compute provider to restore capacity.
May 5, 16:33 UTC
May 5, 16:33 UTC
Update -
We've applied a mitigation for long queue times and failures on Standard Hosted Runners and are monitoring for full recovery. Hosted Runners with Private Networking in the East US region remain affected as we continue working with our compute provider to restore capacity.
May 5, 15:54 UTC
May 5, 15:54 UTC
Update -
We are working with our compute provider to alleviate elevated queue times and failures for Actions Jobs running on Hosted Runners in the East US region affecting 10% of runs. Hosted Runners with private networking can fail over to a different Region to mitigate the issue.
May 5, 15:12 UTC
May 5, 15:12 UTC
Update -
We are investigating elevated queue times and failures on Actions Jobs running on Hosted Runners in East US affecting 8% of runs. Hosted Runners with private networking can fail over to a different Azure region to mitigate the issue.
May 5, 14:14 UTC
May 5, 14:14 UTC
Update -
We are investigating elevated queue times on Actions Jobs running on Standard Hosted Runners in East US affecting 10% of runs
May 5, 13:48 UTC
May 5, 13:48 UTC
Investigating -
We are investigating reports of degraded availability for Actions
May 5, 13:37 UTC
May 5, 13:37 UTC
May 4, 2026
Resolved -
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.
May 4, 16:40 UTC
May 4, 16:40 UTC
Monitoring -
The degradation has been mitigated. We are monitoring to ensure stability.
May 4, 16:36 UTC
May 4, 16:36 UTC
Update -
Webhooks is operating normally.
May 4, 16:35 UTC
May 4, 16:35 UTC
Update -
The degradation affecting Codespaces has been mitigated. We are monitoring to ensure stability.
May 4, 16:35 UTC
May 4, 16:35 UTC
Update -
The degradation affecting Issues has been mitigated. We are monitoring to ensure stability.
May 4, 16:34 UTC
May 4, 16:34 UTC
Update -
Pull Requests is operating normally.
May 4, 16:32 UTC
May 4, 16:32 UTC
Update -
Pages is operating normally.
May 4, 16:29 UTC
May 4, 16:29 UTC
Update -
Latency across services has normalized. We are continuing to investigate the root cause and prevent reoccurrence.
May 4, 16:29 UTC
May 4, 16:29 UTC
Update -
Actions and Packages are operating normally.
May 4, 16:28 UTC
May 4, 16:28 UTC
Update -
Git Operations is operating normally.
May 4, 16:25 UTC
May 4, 16:25 UTC
Update -
Pages is experiencing degraded performance. We are continuing to investigate.
May 4, 16:06 UTC
May 4, 16:06 UTC
Update -
Codespaces is experiencing degraded performance. We are continuing to investigate.
May 4, 16:05 UTC
May 4, 16:05 UTC
Update -
Pull Requests is experiencing degraded performance. We are continuing to investigate.
May 4, 15:56 UTC
May 4, 15:56 UTC
Update -
Actions is experiencing degraded performance. We are continuing to investigate.
May 4, 15:51 UTC
May 4, 15:51 UTC
Update -
Pull Requests is experiencing degraded availability. We are continuing to investigate.
May 4, 15:51 UTC
May 4, 15:51 UTC
Update -
Packages is experiencing degraded performance. We are continuing to investigate.
May 4, 15:50 UTC
May 4, 15:50 UTC
Update -
Git Operations is experiencing degraded performance. We are continuing to investigate.
May 4, 15:48 UTC
May 4, 15:48 UTC
Update -
We are investigating Increased latency and timeouts across multiple GitHub services.
May 4, 15:48 UTC
May 4, 15:48 UTC
Investigating -
We are investigating reports of degraded performance for Issues and Webhooks
May 4, 15:45 UTC
May 4, 15:45 UTC
May 3, 2026
No incidents reported.
May 2, 2026
No incidents reported.
May 1, 2026
Resolved -
On April 28, 2026, at approximately 14:07 UTC, GitHub received reports that pull requests were missing from search results across global and repository /pulls pages.
The issue was caused by a manually invoked repair job intended for a single repository, which was executed without the required safety flags. During execution of the repair job, the database query remained correctly scoped to the repo’s PR IDs. However, the Elasticsearch reconciliation logic did not apply the same scope. It interpreted the min and max PR IDs as a continuous range, causing unrelated PR documents across other repos to be marked for deletion. This resulted in the removal of 1,789,756,838 PR documents from the search index, approximately 49% of indexed PR documents.
Customer impact was limited to PR search and list discoverability. Primary storage was unaffected, and there was no impact to opening, updating, or merging PRs.
The issue was identified ~10 minutes after initial customer reports. Because it affected search index completeness rather than service availability, it was not caught by existing monitoring.
The root cause was a flaw in the search document repair framework: it allowed a scoped reconciliation to run without enforcing a matching Elasticsearch query scope. This created a destructive mismatch between the source-of-truth and the index. The issue was compounded by the ability to trigger the job from the production console without safety defaults. Prior testing focused only on safe backfill scenarios and did not cover this reconciliation path. Additionally, there was no automated detection for large-volume deletions in Elasticsearch.
We mitigated the incident through three parallel actions: (1) Deployed a MySQL-backed search fallback for the most active repos by traffic to restore PR visibility for highly impacted users (2) Initiated a snapshot restore and reindex process to repopulate missing pull request documents in Elasticsearch (3) Added a degradation notice on PR pages to inform users of incomplete search results while recovery was in progress. The incident was resolved on May 1, 2026 at 4:15 UTC, following completion and validation of the reindex process.
To prevent recurrence, we are prioritizing improvements to the repair framework and safeguards. These include enforcing scoped query alignment between primary storage and Elasticsearch, preventing destructive operations without explicit opt-in, strengthening guardrails for manual repair jobs, and evaluating restrictions on production console access.
In parallel, we are expanding automated test coverage for reconciliation safety invariants and introducing detection for anomalous deletion patterns in Elasticsearch so similar issues can be identified or blocked earlier.
We are committed to improving the safety and reliability of our repair systems and ensuring that operational workflows are resilient to both software defects and manual invocation risks.
May 1, 04:15 UTC
The issue was caused by a manually invoked repair job intended for a single repository, which was executed without the required safety flags. During execution of the repair job, the database query remained correctly scoped to the repo’s PR IDs. However, the Elasticsearch reconciliation logic did not apply the same scope. It interpreted the min and max PR IDs as a continuous range, causing unrelated PR documents across other repos to be marked for deletion. This resulted in the removal of 1,789,756,838 PR documents from the search index, approximately 49% of indexed PR documents.
Customer impact was limited to PR search and list discoverability. Primary storage was unaffected, and there was no impact to opening, updating, or merging PRs.
The issue was identified ~10 minutes after initial customer reports. Because it affected search index completeness rather than service availability, it was not caught by existing monitoring.
The root cause was a flaw in the search document repair framework: it allowed a scoped reconciliation to run without enforcing a matching Elasticsearch query scope. This created a destructive mismatch between the source-of-truth and the index. The issue was compounded by the ability to trigger the job from the production console without safety defaults. Prior testing focused only on safe backfill scenarios and did not cover this reconciliation path. Additionally, there was no automated detection for large-volume deletions in Elasticsearch.
We mitigated the incident through three parallel actions: (1) Deployed a MySQL-backed search fallback for the most active repos by traffic to restore PR visibility for highly impacted users (2) Initiated a snapshot restore and reindex process to repopulate missing pull request documents in Elasticsearch (3) Added a degradation notice on PR pages to inform users of incomplete search results while recovery was in progress. The incident was resolved on May 1, 2026 at 4:15 UTC, following completion and validation of the reindex process.
To prevent recurrence, we are prioritizing improvements to the repair framework and safeguards. These include enforcing scoped query alignment between primary storage and Elasticsearch, preventing destructive operations without explicit opt-in, strengthening guardrails for manual repair jobs, and evaluating restrictions on production console access.
In parallel, we are expanding automated test coverage for reconciliation safety invariants and introducing detection for anomalous deletion patterns in Elasticsearch so similar issues can be identified or blocked earlier.
We are committed to improving the safety and reliability of our repair systems and ensuring that operational workflows are resilient to both software defects and manual invocation risks.
May 1, 04:15 UTC
Update -
This incident has been resolved. Search and indexing functionality for pull requests are now fully restored. 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.
May 1, 04:11 UTC
May 1, 04:11 UTC
Update -
We have repaired the missing search records for affected Pull Requests and are working to identify and repair records left in a stale state after the recovery.
Apr 30, 03:49 UTC
Apr 30, 03:49 UTC
Update -
We have restored search/indexing functionality for over 99% of impacted pull requests. We are continuing to address the remaining affected pull requests and are reviewing outstanding gaps as part of the restoration process.
Apr 29, 22:22 UTC
Apr 29, 22:22 UTC
Update -
Mitigation is in progress, with full recovery of impacted pull request listings expected within approximately 24 hours.
Apr 29, 00:40 UTC
Apr 29, 00:40 UTC
Update -
We have made an interim mitigation to improve availability for some impacted repositories while reindexing continues, and we are actively monitoring the indexing progress.
Apr 28, 22:46 UTC
Apr 28, 22:46 UTC
Update -
Elastic search reindexing of pull requests is continuing. All data is preserved, but may not be available on pages relying on elasticsearch until the reindex is complete.
Pages and APIs that do not rely on elasticsearch, including the GitHub CLI (gh pr list) and API (/repos/{owner}/{repo}/pulls), are not impacted and can be used to retrieve pull request data in the interim.
Apr 28, 21:43 UTC
Pages and APIs that do not rely on elasticsearch, including the GitHub CLI (gh pr list) and API (/repos/{owner}/{repo}/pulls), are not impacted and can be used to retrieve pull request data in the interim.
Apr 28, 21:43 UTC
Update -
We are actively reindexing the remaining ElasticSearch indexes. Our priority is ensuring correctness and avoiding further impact. We are taking a measured approach to safely backfill data and will share additional updates as progress continues.
Apr 28, 15:58 UTC
Apr 28, 15:58 UTC
Update -
After yesterday’s incident, we are investigating cases where /pulls and /repo/pulls pages are not showing all indexed pull requests. This is because our Elasticsearch cluster does not currently contain all indexed documents.
No pull request data has been lost. As pull requests are updated, they will be reindexed. We are also working on accelerating a full reindex so these pages return complete results again.
Apr 28, 14:51 UTC
No pull request data has been lost. As pull requests are updated, they will be reindexed. We are also working on accelerating a full reindex so these pages return complete results again.
Apr 28, 14:51 UTC
Investigating -
We are investigating reports of degraded performance for Pull Requests
Apr 28, 14:17 UTC
Apr 28, 14:17 UTC
Apr 30, 2026
Apr 29, 2026
Apr 28, 2026
Resolved -
On April 28, 2026, from approximately 12:41 UTC to 17:09 UTC, GitHub Actions jobs using Standard Ubuntu 22 and Ubuntu 24 hosted runners experienced run start delays. Approximately 8% of hosted runner jobs using Ubuntu 22 and Ubuntu 24 experienced delays greater than 5 minutes or failures. Larger and self-hosted runners were not impacted.
This was caused by a performance regression introduced in the VM reimage process. That reimage delay lowered the overall capacity of runners available to pick up new jobs. This was mitigated with a rollback to a known good image version.
We are addressing the core issue with reimage performance and improving the granularity of reimage telemetry across our services and our compute provider to more quickly diagnose similar issues in the future. Finally, we are evaluating other rollout changes to automatically detect similar regressions.
Apr 28, 17:09 UTC
This was caused by a performance regression introduced in the VM reimage process. That reimage delay lowered the overall capacity of runners available to pick up new jobs. This was mitigated with a rollback to a known good image version.
We are addressing the core issue with reimage performance and improving the granularity of reimage telemetry across our services and our compute provider to more quickly diagnose similar issues in the future. Finally, we are evaluating other rollout changes to automatically detect similar regressions.
Apr 28, 17:09 UTC
Monitoring -
Actions is operating normally.
Apr 28, 17:08 UTC
Apr 28, 17:08 UTC
Update -
Less than 1% of hosted ubuntu-latest runs are delayed. We’re working through remaining steps to restore runner capacity.
Apr 28, 16:36 UTC
Apr 28, 16:36 UTC
Update -
Currently less than 2% of hosted ubuntu-latest and ubuntu-24.04 runs are delayed or failing. We are continuing to monitor for full recovery.
Apr 28, 15:41 UTC
Apr 28, 15:41 UTC
Update -
We've applied a mitigation to unblock running Actions. We're continuing to monitor.
Apr 28, 15:20 UTC
Apr 28, 15:20 UTC
Update -
We're still investigating the root cause for run start delays and failures for Actions hosted Ubuntu jobs, around 5% of jobs are impacted as of now.
Apr 28, 14:49 UTC
Apr 28, 14:49 UTC
Investigating -
Actions is experiencing degraded performance. We are continuing to investigate.
Apr 28, 14:02 UTC
Apr 28, 14:02 UTC
Monitoring -
Actions is experiencing capacity constraints with hosted ubuntu-latest and ubuntu-24.02, leading to high wait times. Other hosted labels and self-hosted runners are not impacted.
Apr 28, 13:59 UTC
Apr 28, 13:59 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
Apr 28, 13:59 UTC
Apr 28, 13:59 UTC
Apr 27, 2026
Resolved -
On April 27, 2026 between 16:15 UTC and 22:46 UTC, GitHub search services experienced degraded connectivity due to saturation of the load balancing tier deployed in front of our search infrastructure. This resulted in intermittent failures for services relying on our search data including Issues, Pull Requests, Projects, Repositories, Actions, Package Registry and Dependabot Alerts. The impact was varied by search target, with services seeing up to 65% of searches timing out or returning an error between 16:15 UTC and 18:00 UTC.
We detected the drop in search results through our ongoing monitoring and declared an incident at 16:21 UTC when we determined the issues would not self-heal. We tracked the incident as mitigated as of 21:33 UTC and monitored the systems until 22:46 UTC when we declared the incident resolved. Our existing monitoring did not classify the increased scraping as a risk and this dimension of the incident was only discovered while working to mitigate.
The saturation was caused by a large influx of anonymous distributed scraping traffic that was crafted to avoid our public API rate limits. This scraping traffic made up 30% of the day’s total search traffic, but it was concentrated within a four-hour period. The traffic originated from over 600,000 Unique IP addresses, with matching actor information across the board.
To mitigate, we immediately focused on relieving pressure from the load balancers while simultaneously working on scaling the load balancing tier, blocking the anomalous traffic and applying tuning to the balancers to fully resolve the incident.
Looking ahead, we’ve not only scaled the load balancer tier, but applied optimizations to improve our connection handling and re-use to reduce the possibility that a saturation event like this can re-occur. We’ve also added new monitors and controls within the platform to allow us to restrict anonymous traffic to mitigate the impact to our registered users.
Apr 27, 22:46 UTC
We detected the drop in search results through our ongoing monitoring and declared an incident at 16:21 UTC when we determined the issues would not self-heal. We tracked the incident as mitigated as of 21:33 UTC and monitored the systems until 22:46 UTC when we declared the incident resolved. Our existing monitoring did not classify the increased scraping as a risk and this dimension of the incident was only discovered while working to mitigate.
The saturation was caused by a large influx of anonymous distributed scraping traffic that was crafted to avoid our public API rate limits. This scraping traffic made up 30% of the day’s total search traffic, but it was concentrated within a four-hour period. The traffic originated from over 600,000 Unique IP addresses, with matching actor information across the board.
To mitigate, we immediately focused on relieving pressure from the load balancers while simultaneously working on scaling the load balancing tier, blocking the anomalous traffic and applying tuning to the balancers to fully resolve the incident.
Looking ahead, we’ve not only scaled the load balancer tier, but applied optimizations to improve our connection handling and re-use to reduce the possibility that a saturation event like this can re-occur. We’ve also added new monitors and controls within the platform to allow us to restrict anonymous traffic to mitigate the impact to our registered users.
Apr 27, 22:46 UTC
Update -
The degradation has been mitigated. We are monitoring to ensure stability.
Apr 27, 22:44 UTC
Apr 27, 22:44 UTC
Update -
The degradation has been mitigated. We are monitoring to ensure stability.
Apr 27, 22:35 UTC
Apr 27, 22:35 UTC
Monitoring -
The degradation affecting Actions, Issues, Packages and Pull Requests has been mitigated. We are monitoring to ensure stability.
Apr 27, 21:33 UTC
Apr 27, 21:33 UTC
Update -
We've applied a mitigation and continuing to monitor
Apr 27, 21:32 UTC
Apr 27, 21:32 UTC
Update -
Pull Requests is experiencing degraded performance. We are continuing to investigate.
Apr 27, 20:06 UTC
Apr 27, 20:06 UTC
Update -
We have identified the source of the additional load causing stress on our ElasticSearch clusters. We have disabled the source of that load and are seeing signs of recovery
Apr 27, 19:50 UTC
Apr 27, 19:50 UTC
Update -
Pull Requests is experiencing degraded availability. We are continuing to investigate.
Apr 27, 18:19 UTC
Apr 27, 18:19 UTC
Update -
We're continuing to see connectivity issues reaching elasticsearch. Impact on downstream services will be intermittent as we find the root cause
Apr 27, 18:17 UTC
Apr 27, 18:17 UTC
Update -
Users are experiencing intermittent failures to view issues, pull requests, projects and Actions workflow runs.
We are still investigating and attempting mitigations. We will provide further updates.
Apr 27, 17:35 UTC
We are still investigating and attempting mitigations. We will provide further updates.
Apr 27, 17:35 UTC
Update -
Pull Requests is experiencing degraded performance. We are continuing to investigate.
Apr 27, 16:53 UTC
Apr 27, 16:53 UTC
Update -
Packages is experiencing degraded performance. We are continuing to investigate.
Apr 27, 16:39 UTC
Apr 27, 16:39 UTC
Update -
Issues is experiencing degraded performance. We are continuing to investigate.
Apr 27, 16:36 UTC
Apr 27, 16:36 UTC
Update -
Customers across GitHub are experiencing failures with searches. Examples include: workflow run failures, projects failing to load, and timed out search requests. This is due to an ongoing infrastructure issue that we have been investigating.
Apr 27, 16:33 UTC
Apr 27, 16:33 UTC
Investigating -
We are investigating reports of degraded performance for Actions
Apr 27, 16:31 UTC
Apr 27, 16:31 UTC
Resolved -
On April 22, 2026 from 18:49 to 19:32 UTC , the Copilot Cloud Agent service began failing during session execution for users running the Agent HQ Codex agent. Codex agent sessions failed to start for all entry points (issue assignment, @copilot comment mentions). 0.5% of total Copilot Cloud Agent jobs were impacted (~2,000 failed jobs). Copilot and other agent sessions were unaffected.
This was caused by a model resolution mismatch in Codex agent sessions, resulting in an incompatible model being used at runtime. A mitigation was deployed to select a stable default model for Codex agent sessions.
We are working to harden the underlying model-resolution path so it correctly scopes to the requesting agent's supported models to prevent similar failure mode in the future.
Apr 27, 19:02 UTC
This was caused by a model resolution mismatch in Codex agent sessions, resulting in an incompatible model being used at runtime. A mitigation was deployed to select a stable default model for Codex agent sessions.
We are working to harden the underlying model-resolution path so it correctly scopes to the requesting agent's supported models to prevent similar failure mode in the future.
Apr 27, 19:02 UTC
Monitoring -
The degradation has been mitigated. We are monitoring to ensure stability.
Apr 27, 19:01 UTC
Apr 27, 19:01 UTC
Update -
We've found the issue and are working on deploying a solution to get Codex agent runs working again.
Apr 27, 17:26 UTC
Apr 27, 17:26 UTC
Update -
Copilot Cloud Agent (CCA) jobs using the Codex agent are failing after starting. To avoid this issue, please choose a different agent. We are investigating the cause and working towards remediation
Apr 27, 17:01 UTC
Apr 27, 17:01 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
Apr 27, 16:48 UTC
Apr 27, 16:48 UTC
Apr 26, 2026
No incidents reported.
Apr 25, 2026
Resolved -
On April 24, 2026, from approximately 11:39 UTC to April 25, 2026 at 00:15 UTC, GitHub Actions experienced delays and timeouts for Larger Hosted Runner jobs using VNet injection in the East US region without a failover region configured. Standard and Self-hosted runners were not impacted. This was caused by backend failures in our compute provider’s provisioning, scaling, and update operations for VMs in the East US region and mitigated by a rollback across all affected Availability Zones. More detail is available at https://azure.status.microsoft/en-us/status/history/?trackingId=5GP8-W0G.
We are working to improve the reliability of our annotations for jobs impacted by regional issues and are adding system log notifications as an additional customer communication channel alongside annotations.
VNet Failover is also now in public preview, allowing customers to evacuate Larger Hosted Runners using VNet injection in cases like this.
Apr 25, 00:36 UTC
We are working to improve the reliability of our annotations for jobs impacted by regional issues and are adding system log notifications as an additional customer communication channel alongside annotations.
VNet Failover is also now in public preview, allowing customers to evacuate Larger Hosted Runners using VNet injection in cases like this.
Apr 25, 00:36 UTC
Update -
This is related to the public impact, "Multiservice impact for Azure Workloads in East US" shared at https://azure.status.microsoft/
Apr 24, 19:14 UTC
Apr 24, 19:14 UTC
Update -
We are investigating reports of degraded performance for Larger Runners with vnet injection in East US and we are working with our service provider on mitigation.
Apr 24, 19:09 UTC
Apr 24, 19:09 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
Apr 24, 19:02 UTC
Apr 24, 19:02 UTC
Apr 24, 2026
Apr 23, 2026
Resolved -
On April 23, 2026, between 16:05 UTC and 20:43 UTC, the Pull Requests service experienced a regression affecting merge queue operations. PRs merged via merge queue using the squash merge method produced incorrect merge commits when the merge group contained more than one PR. In affected cases, changes from previously merged PRs and prior commits were inadvertently reverted by subsequent merges.
During the impact window 2,092 pull requests were affected. The issue did not affect pull requests merged outside of merge queue, nor merge queue groups using the merge or rebase methods.
It took approximately 3 hours and 33 minutes to identify the issue. The change completed deployment at approximately 16:05 UTC, and we became aware at 19:38 UTC following an increase in customer support inquiries. Because the issue affected merge commit correctness rather than availability, it was not detected by existing automated monitoring and was identified through customer reports.
The regression was introduced by a new code path that adjusted merge base computation for merge queue ref updates. This code path was intended to be gated behind a feature flag for an unreleased feature, but the gating was incomplete.
As a result, the new behavior was inadvertently applied to squash merge groups, producing an incorrect three-way merge. This caused subsequent squash merges to revert changes from earlier pull requests and, in some cases, changes between their starting points.
We mitigated the incident by reverting the code change and force-deploying the fix across all environments. After resolution, we identified affected repositories and sent targeted remediation instructions to repository administrators with step-by-step recovery guidance.
The regression was not identified during internal validation. Existing test coverage primarily exercised single-PR merge queue groups, which did not exhibit the faulty base-reference calculation. Because automated checks did not validate merge correctness for multi-PR squash groups, the defect surfaced only in production.
To prevent recurrence, GitHub is expanding test coverage for merge correctness validation. We are broadening automated coverage for merge queue operations, including regression checks that validate resulting Git contents across supported configurations, so issues affecting merge correctness are caught before reaching production.
We are committed to ensuring the correctness and reliability of merge queue operations. These actions will reduce the risk of similar regressions and improve confidence in future changes to the Pull Requests service.
Apr 23, 21:43 UTC
During the impact window 2,092 pull requests were affected. The issue did not affect pull requests merged outside of merge queue, nor merge queue groups using the merge or rebase methods.
It took approximately 3 hours and 33 minutes to identify the issue. The change completed deployment at approximately 16:05 UTC, and we became aware at 19:38 UTC following an increase in customer support inquiries. Because the issue affected merge commit correctness rather than availability, it was not detected by existing automated monitoring and was identified through customer reports.
The regression was introduced by a new code path that adjusted merge base computation for merge queue ref updates. This code path was intended to be gated behind a feature flag for an unreleased feature, but the gating was incomplete.
As a result, the new behavior was inadvertently applied to squash merge groups, producing an incorrect three-way merge. This caused subsequent squash merges to revert changes from earlier pull requests and, in some cases, changes between their starting points.
We mitigated the incident by reverting the code change and force-deploying the fix across all environments. After resolution, we identified affected repositories and sent targeted remediation instructions to repository administrators with step-by-step recovery guidance.
The regression was not identified during internal validation. Existing test coverage primarily exercised single-PR merge queue groups, which did not exhibit the faulty base-reference calculation. Because automated checks did not validate merge correctness for multi-PR squash groups, the defect surfaced only in production.
To prevent recurrence, GitHub is expanding test coverage for merge correctness validation. We are broadening automated coverage for merge queue operations, including regression checks that validate resulting Git contents across supported configurations, so issues affecting merge correctness are caught before reaching production.
We are committed to ensuring the correctness and reliability of merge queue operations. These actions will reduce the risk of similar regressions and improve confidence in future changes to the Pull Requests service.
Apr 23, 21:43 UTC
Update -
We have resolved a regression present when using merge queue with either squash merges or rebases. If you use merge queue in this configuration, some pull requests may have been merged incorrectly between 2026-04-23 16:05-20:43 UTC.
This behavior is still present in GitHub Enterprise Cloud with Data Residency, and we are rolling out the same fix.
Apr 23, 21:18 UTC
This behavior is still present in GitHub Enterprise Cloud with Data Residency, and we are rolling out the same fix.
Apr 23, 21:18 UTC
Update -
Pull Requests is operating normally.
Apr 23, 20:47 UTC
Apr 23, 20:47 UTC
Update -
We have identified a regression in merge queue behavior present when squash merging or rebasing. We have identified the root-cause and are in the process of reverting the change.
Apr 23, 19:58 UTC
Apr 23, 19:58 UTC
Investigating -
We are investigating reports of degraded performance for Pull Requests
Apr 23, 19:50 UTC
Apr 23, 19:50 UTC
Resolved -
Between 18:45 and 19:42 UTC on April 23, users were unable to start new agent tasks using either Claude or Codex agent on github.com. This was caused by a code change to how Copilot mission control routes task creation requests. Ongoing agent tasks and other Copilot agent features were not affected. We mitigated the impact by reverting the breaking change. We are adding extra monitoring and integration test coverage for the task creation path to prevent future recurrence.
Apr 23, 19:42 UTC
Apr 23, 19:42 UTC
Update -
We have identified the root cause of the issue and are working on mitigation.
Apr 23, 19:33 UTC
Apr 23, 19:33 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
Apr 23, 19:28 UTC
Apr 23, 19:28 UTC
Resolved -
On April 23, 2026, between 16:03 UTC and 17:27 UTC, multiple GitHub services experienced elevated error rates and degraded performance due to DNS resolution failures originating from our DNS infrastructure in our VA3 datacenter. Approximately 5–7% of overall traffic was affected during the impact window:
- Webhooks: ~0.35% of API requests returned 5xx (peak ~0.39%). ~0.88% of requests exceeded 3s latency; at peak, >3s responses represented ~10% of Webhooks API traffic.
- Copilot Metrics: ~9% of Copilot Insights dashboard requests returned 5xx.
- Copilot cloud agents: ~10% of cloud agent sessions were affected and failing.
- Octoshift: 0.88% of active repo migrations failed and 79% saw elevated durations (avg. 5.2 min) during this period.
- Git Operations: averaged 1.25% errors over the duration of the incident, with a peak of 2.07% errors.
- Actions: Workflow run status updates experienced delays of up to ~8s over the duration of the incident window.
Our DNS infrastructure in VA3 entered a degraded state and began intermittently returning NXDOMAIN responses and timing out on lookups for both internal service discovery and external endpoints. This caused a cascading impact across the dependent services listed above.
We identified a specific load pattern under which our DNS resolvers began failing. The evidence points to a recently introduced traffic-balancing mechanism, rolled out progressively to support our growth, as the root cause. We have since reverted this change.
We are immediately prioritizing investments in a more controlled rollout and validation process, including a dedicated environment to safely shadow production DNS traffic and detect these failure modes before they can affect production.
Apr 23, 17:30 UTC
- Webhooks: ~0.35% of API requests returned 5xx (peak ~0.39%). ~0.88% of requests exceeded 3s latency; at peak, >3s responses represented ~10% of Webhooks API traffic.
- Copilot Metrics: ~9% of Copilot Insights dashboard requests returned 5xx.
- Copilot cloud agents: ~10% of cloud agent sessions were affected and failing.
- Octoshift: 0.88% of active repo migrations failed and 79% saw elevated durations (avg. 5.2 min) during this period.
- Git Operations: averaged 1.25% errors over the duration of the incident, with a peak of 2.07% errors.
- Actions: Workflow run status updates experienced delays of up to ~8s over the duration of the incident window.
Our DNS infrastructure in VA3 entered a degraded state and began intermittently returning NXDOMAIN responses and timing out on lookups for both internal service discovery and external endpoints. This caused a cascading impact across the dependent services listed above.
We identified a specific load pattern under which our DNS resolvers began failing. The evidence points to a recently introduced traffic-balancing mechanism, rolled out progressively to support our growth, as the root cause. We have since reverted this change.
We are immediately prioritizing investments in a more controlled rollout and validation process, including a dedicated environment to safely shadow production DNS traffic and detect these failure modes before they can affect production.
Apr 23, 17:30 UTC
Update -
Webhooks is operating normally.
Apr 23, 17:10 UTC
Apr 23, 17:10 UTC
Update -
Many services are mitigated and are validating the remaining services.
Apr 23, 17:04 UTC
Apr 23, 17:04 UTC
Update -
The degradation affecting Actions and Copilot has been mitigated. We are monitoring to ensure stability.
Apr 23, 17:03 UTC
Apr 23, 17:03 UTC
Update -
We have identified the root problem and are working on mitigation.
Apr 23, 16:52 UTC
Apr 23, 16:52 UTC
Update -
Actions is experiencing degraded performance. We are continuing to investigate.
Apr 23, 16:34 UTC
Apr 23, 16:34 UTC
Update -
We are investigating multiple unavailable services.
Apr 23, 16:19 UTC
Apr 23, 16:19 UTC
Investigating -
We are investigating reports of degraded availability for Copilot and Webhooks
Apr 23, 16:12 UTC
Apr 23, 16:12 UTC
Resolved -
On April 23, 2026 between 14:30 UTC and 15:18 UTC multiple services were degraded on github.com. During this time approximately 1.5% of all web requests resulted in a 5xx status and unicorn pages for github.com users. We also saw elevated error rates across Actions workflow runs, Copilot, Codespaces and Packages, leading to degraded experiences during this timeframe. Codespaces impact peaked at 45% failures for create requests and 65% failures for resume requests. Packages impact was mainly Maven related with 50% failure rates in downloads and 70% failure rates in uploads. Actions experienced a peak of 8% of failed jobs and up to 85% of jobs impacted by run start delays of more than 5 minutes.
This was due to a configuration change to an internal billing service that led to a cache being overwhelmed and causing requests to time out. These timeouts cascaded across multiple services and eventually caused requests to queue up and exhaust web request workers.
This configuration change was reverted at 14:42 UTC and following this, all services began to see recovery immediately.
To prevent this situation in the future, we are taking steps to ensure that failures and timeouts in the billing service don’t cascade to other services causing impact. This includes implementing more aggressive timeouts on callers of these billing services, adding circuit breaker configurations for cache timeouts and using more resilient cache options. We have also decreased max request timeouts within the billing service that caused impact and added more capacity to our cache to prevent traffic spikes from having the same impact.
Apr 23, 15:18 UTC
This was due to a configuration change to an internal billing service that led to a cache being overwhelmed and causing requests to time out. These timeouts cascaded across multiple services and eventually caused requests to queue up and exhaust web request workers.
This configuration change was reverted at 14:42 UTC and following this, all services began to see recovery immediately.
To prevent this situation in the future, we are taking steps to ensure that failures and timeouts in the billing service don’t cascade to other services causing impact. This includes implementing more aggressive timeouts on callers of these billing services, adding circuit breaker configurations for cache timeouts and using more resilient cache options. We have also decreased max request timeouts within the billing service that caused impact and added more capacity to our cache to prevent traffic spikes from having the same impact.
Apr 23, 15:18 UTC
Monitoring -
The degradation affecting Actions, Codespaces, Copilot and Packages has been mitigated. We are monitoring to ensure stability.
Apr 23, 15:02 UTC
Apr 23, 15:02 UTC
Update -
A mitigation was applied and services have recovered. Actions is working through queued work before fully recovering.
Apr 23, 15:02 UTC
Apr 23, 15:02 UTC
Update -
Users are experiencing errors loading various web pages on github.com. Actions and Copilot Cloud Agent runs will be delayed.
Apr 23, 14:51 UTC
Apr 23, 14:51 UTC
Update -
Copilot is experiencing degraded performance. We are continuing to investigate.
Apr 23, 14:44 UTC
Apr 23, 14:44 UTC
Update -
Codespaces is experiencing degraded performance. We are continuing to investigate.
Apr 23, 14:42 UTC
Apr 23, 14:42 UTC
Update -
Packages is experiencing degraded performance. We are continuing to investigate.
Apr 23, 14:41 UTC
Apr 23, 14:41 UTC
Investigating -
We are investigating reports of degraded performance for Actions
Apr 23, 14:40 UTC
Apr 23, 14:40 UTC
Apr 22, 2026
Resolved -
On April 22, 2026, between 09:00 UTC and 22:05 UTC, the Copilot coding agent and pull request comment event processing were degraded. During this period, approximately 0.5% of total pull request and issue comments mentioned @copilot (~23,000 invocations), explicitly requested work from the Copilot coding agent but were not acted upon.
Creating, viewing, and replying to pull request comments was unaffected, and other Copilot
functionality continued to operate normally. The impact was limited to @copilot mentions on pull request comments not triggering Copilot coding agent runs, and to some downstream systems not receiving new pull request comment events during the impact window.
The cause was a serialization error that prevented pull request comment events from being published to downstream consumers, including the Copilot coding agent. This was related to the same class of issue as incident #4295 on April 20, affecting a another event type.
We mitigated the incident by deploying a fix that restored event publishing, after which the Copilot coding agent and other downstream consumers resumed processing pull request comment events normally.
We are working to complete our audit of related event schemas, migrate remaining consumers to use
the updated identifier fields, and improve monitoring to detect drops in publishing on critical event topics, to reduce our time to detection and mitigation of issues like this one in the future.
Apr 22, 22:43 UTC
Creating, viewing, and replying to pull request comments was unaffected, and other Copilot
functionality continued to operate normally. The impact was limited to @copilot mentions on pull request comments not triggering Copilot coding agent runs, and to some downstream systems not receiving new pull request comment events during the impact window.
The cause was a serialization error that prevented pull request comment events from being published to downstream consumers, including the Copilot coding agent. This was related to the same class of issue as incident #4295 on April 20, affecting a another event type.
We mitigated the incident by deploying a fix that restored event publishing, after which the Copilot coding agent and other downstream consumers resumed processing pull request comment events normally.
We are working to complete our audit of related event schemas, migrate remaining consumers to use
the updated identifier fields, and improve monitoring to detect drops in publishing on critical event topics, to reduce our time to detection and mitigation of issues like this one in the future.
Apr 22, 22:43 UTC
Update -
We have identified the root cause of the disruption affecting Copilot Coding Agent and Issues. A fix is being deployed.
Apr 22, 22:09 UTC
Apr 22, 22:09 UTC
Update -
We have identified the root cause of the disruption affecting Copilot Coding Agent and Issues. Copilot @-mentions on pull requests are not being processed, and some issue-related functionality may be degraded. A fix has been developed and is being applied.
Apr 22, 20:37 UTC
Apr 22, 20:37 UTC
Update -
Copilot @-mentions on pull requests are currently not being processed by Copilot Cloud Agent. We have found the issue and are investigating remediations.
Apr 22, 20:02 UTC
Apr 22, 20:02 UTC
Update -
Issues is experiencing degraded performance. We are continuing to investigate.
Apr 22, 19:55 UTC
Apr 22, 19:55 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
Apr 22, 19:53 UTC
Apr 22, 19:53 UTC
Resolved -
On April 22, 2026, between 15:16 UTC and 19:18 UTC, users experienced errors when interacting with Copilot Chat on github.com and Copilot Cloud Agent. During this time, users were unable to use Copilot Chat or Copilot Cloud Agent. Copilot Memory (in preview) was not available to Copilot agent sessions during this time. The issue was caused by an infrastructure configuration change that resulted in connectivity issues with our databases. The team identified the cause and restored connectivity to the database. Copilot Chat and Cloud Agent for github.com were restored by 18:16 UTC. Remaining regional deployments were restored incrementally, with full resolution at 19:18 UTC. We have taken steps to prevent similar infrastructure changes from causing these kinds of database operations in the future.
Apr 22, 19:18 UTC
Apr 22, 19:18 UTC
Update -
Copilot cloud agent and chat are mitigated for github.com.
Apr 22, 18:05 UTC
Apr 22, 18:05 UTC
Update -
We are now seeing recovery for Copilot cloud agent.
Apr 22, 17:49 UTC
Apr 22, 17:49 UTC
Update -
Mitigation is progressing for Copilot chat and cloud agent recovery.
Apr 22, 17:40 UTC
Apr 22, 17:40 UTC
Update -
Mitigation is progressing for Copilot chat and cloud agent.
Apr 22, 16:58 UTC
Apr 22, 16:58 UTC
Update -
We continue to work on mitigation for Copilot chat and cloud agent.
Apr 22, 16:24 UTC
Apr 22, 16:24 UTC
Update -
We are aware of users seeing errors interacting with Copilot chat on github.com and Copilot cloud agent. We have identified the cause and are investigating remediations.
Apr 22, 15:43 UTC
Apr 22, 15:43 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
Apr 22, 15:35 UTC
Apr 22, 15:35 UTC
Resolved -
On April 21, 2026, between 13:35 UTC and 01:24 UTC the following day the projects service was degraded. During this time period, projects may have been out of sync and users may have experienced delays in changes to projects and their items. Delays in reflected changes peaked at approximately 45 minutes. The delays were caused by serialization errors that failed events and triggered a flood of resyncs, overloading our event processing layers.
We mitigated the incident by speeding up processing time for incoming changes and otherwise waiting for all changes to be processed.
We are working to increase our capacity for processing updates to projects to reduce our time to mitigation of issues like this one in the future.
Apr 22, 01:24 UTC
We mitigated the incident by speeding up processing time for incoming changes and otherwise waiting for all changes to be processed.
We are working to increase our capacity for processing updates to projects to reduce our time to mitigation of issues like this one in the future.
Apr 22, 01:24 UTC
Update -
The issue remains mitigated. Users may still experience small delays in changes to projects while we process the backlog of events. We expect a full recovery in approximately two hours.
Apr 22, 00:00 UTC
Apr 22, 00:00 UTC
Update -
The issue remains mitigated. Users may still experience delays in changes to projects while we process the backlog of events. We expect a full recovery in approximately three hours.
Apr 21, 22:49 UTC
Apr 21, 22:49 UTC
Monitoring -
The degradation has been mitigated. We are monitoring to ensure stability.
Apr 21, 21:15 UTC
Apr 21, 21:15 UTC
Update -
Recovery from the delays affecting GitHub Projects continues to progress. We have deployed additional mitigations that are accelerating processing of the backlog. Users may still experience delays where changes to projects are not reflected immediately. We expect full recovery within approximately six hours.
Apr 21, 19:41 UTC
Apr 21, 19:41 UTC
Update -
The queues are continuing to decrease and we are working to accelerate the rate of processing through the queues.
Apr 21, 17:21 UTC
Apr 21, 17:21 UTC
Update -
The mitigation is deployed and we are seeing recorvery in the queues and will provide an update as to when full recovery will be realized.
Apr 21, 16:45 UTC
Apr 21, 16:45 UTC
Update -
We are deploying a fix to relieve the queue of delayed data. Some users may still experience delays with GitHub Projects where changes are not reflected immediately as remaining backlogs are processed.
Apr 21, 16:18 UTC
Apr 21, 16:18 UTC
Update -
We continue to investigate delays with GitHub Projects where changes may not be reflected immediately. Our team has identified the cause and applied mitigations to address the issue. We are seeing initial signs of recovery, though some delays may persist as the system works through a backlog of pending updates.
Apr 21, 15:42 UTC
Apr 21, 15:42 UTC
Update -
We are investigating reports of delays with GitHub Projects. Users may notice that changes made to projects are not reflected immediately. Our team has identified the source of the delays and is actively working to resolve the issue.
Apr 21, 15:07 UTC
Apr 21, 15:07 UTC
Investigating -
We are investigating reports of impacted performance for some GitHub services.
Apr 21, 15:03 UTC
Apr 21, 15:03 UTC
Subscribe to our developer newsletter
Get tips, technical guides, and best practices. Twice a month. Right in your inbox.
Subscribe