CC的 - 通知歷史

This incident has been resolved. Customers experiencing 5xx errors with Pages deployments should redeploy to resolve.

A fix has been released customer experiencing 5xx errors on their pages deployments should redeploy to resolve.

Issue has been identified, a fix is being implemented.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

This issue has been resolved.

We are monitoring recovery on Claude Opus 4.7, and working to fully resolve remaining errors impacting Haiku 4.5. We will provide additional updates shortly.

We are currently working to resolve some additional errors impacting Claude Opus 4.7 and Haiku 4.5, we will provide an additional update shortly.

We have seen success rates on Claude Opus 4.7 and Sonnet 4.6 return to normal. We are monitoring closely to ensure no further issues, and will provide an additional update shortly.

We are continuing to work to fully resolve issues impacting Claude Opus 4.7, and Sonnet 4.6. At this time, success rates on Claude Opus 4.7 have stabilized. We will provide additional updates shortly.

We have identified an issue resulting in elevated error rates, primarily on Claude Opus 4.7 and Sonnet 4.6. We are working to resolve these issues, and will provide additional updates as soon as possible.

On May 20, 2026, between 16:00 UTC and 17:45 UTC, GitHub Actions customers experienced run start delays exceeding 5 minutes. Approximately 4.5% of all runs were delayed during the impact window, with scale set jobs disproportionately affected. 30% of scale set jobs were delayed and 4% failed to start entirely.

The incident was caused by a misconfigured health check on an internal service that assigns jobs to runners. A brief latency spike in an upstream dependency triggered health check failures across several pods, removing them from service and concentrating load on the remaining capacity. The added load drove memory pressure that escalated into a cascading failure in one regional cluster, leaving it unable to self-recover.

Responders mitigated the incident by scaling capacity in the healthy regional clusters and draining traffic away from the impaired one, after which run start latency recovered. To prevent recurrence, we are strengthening our health check configuration to avoid cascading failure scenarios and evaluating automated mitigations to rebalance traffic when a region is degraded.

Customer impact has fully subsided. We are maintaining yellow status while we deploy a permanent fix to prevent recurrence.

We've applied a mitigation to fix the issues with queuing and running Actions jobs. We are seeing improvements in telemetry and are monitoring for full recovery.

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

A subset of runners are taking longer than expected to connect, which may delay some jobs from beginning execution. We are actively working to mitigate the issue.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The incident has been resolved. Error rates were elevated between 5:20 PT / 12:48 PT and 6:48 PT / 13:48 PT.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The incident is resolved. The elevated error rate was between 05:37 PT / 12:37 UTC and 06:58 PT / 13:37 UTC.

A fix has been implemented and we are monitoring the results.

The incident is now resolved. The impact was between 16:25 PT / 23:25 UTC and 16:33 PT / 23:33 UTC.

This incident has been resolved.

We are seeing success rates across all services return to normal, and are monitoring closely to prevent any further issues. Impact occurred from 17:34–18:52 UTC.

We are continuing to work to resolve the issues preventing users from accessing Claude.ai, and causing elevated authentication errors for requests to the API and Claude Code.

We have identified an issue resulting in elevated errors on the Anthropic API, as well as issues accessing Claude.ai, including log-in paths for Claude Code. We are working to resolve these issues, and will provide an update as soon as possible.

On March 30, 2026, between 10:11 UTC and 13:25 UTC, GitHub Actions experienced degraded performance. During this time, approximately 2.65% of workflow jobs triggered by pull request events experienced start delays exceeding 5 minutes. The issue was caused by replication lag on an internal database cluster used by Actions, which triggered write throttling in our database protection layer and slowed job queue processing.

The replication lag originated from planned maintenance to scale the internal database. Newly added database hosts triggered guardrails in the throttling layer, restricting write throughput. The incident was mitigated by excluding the new hosts from replication delay calculations.

To prevent recurrence, we have updated our maintenance procedures to ensure new hosts are excluded from throttling assessments during scaling operations. Additionally, we are investing in automation to streamline this type of maintenance activity.

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.

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.

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

This incident has been resolved.

We have rolled out a second mitigation for elevated Build errors and are seeing recovery. All builds are now excluding the Dubai region (dxb1) from their deployment targets as a temporary measure. We will provide additional updates as they become available.

We have rolled out a first mitigation for elevated Build errors. Builds that use Middleware are now excluding the Dubai region (dxb1) from their deployment targets as a temporary measure, and should complete successfully again. We are now working on a mitigation for Builds that are using Edge Functions.

We are currently deploying a mitigation for elevated Build errors. Builds that use Middleware or Edge Functions will exclude the Dubai region (dxb1) from their deployment targets as a temporary measure. We will provide additional updates as they become available.

We are still seeing elevated errors in Builds in all regions, because Middleware and Edge Functions may be deployed globally. Builds that don't use Middleware and Edge Functions are not impacted. We are continuing to work on a fix for this issue.

The dxb1 Edge traffic is currently being rerouted to the nearest Edge region (bom1) to mitigate the impact. We will provide additional updates as they become available.

We have rolled out mitigations and are seeing recovery. If you are still seeing build failures and are using Dubai (dxb1) as your primary Vercel Functions region, you can switch to another region as a workaround.