GitHub Incidents impacting CircleCI functionality
GitHub's APIs appear to be operating normally.
The latest update from CircleCI.
State
Resolved
Started
76 d ago
2026-08-17 14:04 UTC
Lasted
5 h 1 min
until 2026-08-17 19:05 UTC
Worst impact
Partial outage
Timeline
7 updatesIdentified
2 h 18 min 46%
Monitoring
2 h 43 min 54%
Updates
Times in UTCAs posted by CircleCI
GitHub's APIs appear to be operating normally.
Some of GitHub's APIs are still degraded, resulting in a small number of failures relating to commit status updates and hook processing. We will continue to do our best to mitigate these effects.
GitHub API error rates and latencies appear to have recovered. We will continue to monitor.
We have started to observe improved stability in GitHub APIs. We will continue to monitor as they recover.
We are continuing to see high error rates on GitHub's APIs and reduced webhook traffic. Customers using GitHub as their VCS may experience impact to their CircleCI platform experience as a result. This is directly linked to the incident GitHub is experiencing: https://www.githubstatus.com/incidents/zkxwbgr0cnmx We will provide updates as more information becomes available.
We are continuing to see high error rates on GitHub APIs and reduced webhook traffic. We will continue to provide updates as more information becomes available.
GitHub has reported an incident that is impacting CircleCI pipeline triggering and logging in: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Jobs that are in flights are running, but status reporting to GitHub Pull Requests may fail.
CircleCI in the last 90 days
Full historyIncidents in 90 days
27
Days with an incident
25
Median duration
1 h 39 min
This incident
3.0× the median
Other CircleCI incidents
All incidentsCircleCI·Delays for gen2 dedicated IP range jobs
## **Summary** From 14:20 to 19:08 UTC on October 28, customers running Gen 2 Docker jobs using IP Ranges saw increased wait times for their jobs to start. From 14:20 until 17:02, the delays were intermittent, and from 17:02 to 18:50, the delays were continuous. No other job types were affected. The incident was caused by limited availability of the cloud instances we had configured for the IP Ranges cluster. In response, our engineering team added additional fallback instance types to the IP Ranges cluster and transferred capacity from one of our other Gen 2 clusters to the IP Ranges cluster. By 18:50, wait times had improved, and by 19:08 they had fully recovered. After we resolved the incident, we increased the number of baseline cloud instances we maintain for IP Ranges jobs. We have also configured an IP Ranges cluster in an additional cloud region. The original status page can be found here: [Delays for gen2 dedicated IP range jobs](https://status.circleci.com/incidents/8q9j33r2r
CircleCI·Increased Docker gen2 wait times
## Summary From 15:44 to 20:55 UTC on October 21, customers running Gen 2 Docker jobs saw increased wait times for their jobs to start. Delays were longest on the 2xlarge resource class, where jobs waited up to 20 minutes. The incident was caused by limited availability of the cloud instances we had configured to meet demand, particularly for 2xlarge jobs. In response, our engineering team configured additional instance types, configured additional Gen 2 Docker clusters. By 20:55 UTC, wait times had returned to normal and the incident was resolved. After the incident was resolved, we expanded our Gen 2 Docker fleet into additional cloud regions, and we continue actively standing up additional cloud regions to prevent similar incidents in the future. The original status page can be found here: [October 21 - Increased Docker gen2 wait times](https://status.circleci.com/incidents/5jb50gh55gtj). ## Background When CircleCI executes a Docker job, we schedule it on one of several clusters of
CircleCI·Increased wait times for macOS jobs on m4pro.large
Wait times for macOS jobs on the m4pro.large resource class have returned to normal. We thank you for your patience while the backlogs cleared.
CircleCI·Delays starting macOS jobs that use Xcode 26.6.0
Between approximately 14:00 UTC and 15:51 UTC on October 14, customers running macOS jobs that use Xcode 26.6.0 or Xcode 26.4 experienced delays starting jobs. From approximately 14:00 UTC, jobs that use Xcode 26.6.0 on the M4 Pro large resource class waited 30 minutes or more to start, and these delays recovered at approximately 15:12 UTC. From approximately 15:11 UTC, jobs that use Xcode 26.4 waited about 30 minutes to start. The issue has been resolved and all affected functionality has returned to normal. We thank you for your patience while our team worked on implementing a fix.
CircleCI·Delay in data appearing in UI and API
## Summary Between 11:15 UTC and 23:47 UTC on October 9, CircleCI customers experienced hours-long delays and failures across pipelines, workflows and jobs, along with delays in the CircleCI UI, API and notifications. * From 11:15 to 13:00 UTC, pipelines were created but not processed, and outbound webhooks and Slack and email notifications were not sent. * From 13:00 to 14:40 UTC, workflows and jobs started with delays while we worked through the backlog. * From 15:15 to 20:48 UTC, workflows and jobs started with increasing delays, of up to about an hour, and the CircleCI UI and API fell behind by up to about 2 hours. During this time, some jobs failed to start and some in-progress workflows failed. * From 20:48 to 22:10 UTC, we temporarily paused starting new workflows and jobs so our systems could recover. New pipelines were accepted and queued during this time. * From 22:10 to 23:47 UTC, queued workflows and jobs resumed and were successfully processed. Some of them had waited up t
Follow CircleCI
Your coding agent knows when CircleCI is down, and tells you when a failure is theirs, not yours. You can also get CircleCI incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "circleci" and tell me if CircleCI has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=circleci/feed subscribe https://outages.cc/feed.xml?providers=circleciFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane