Status: MOSTLY RECOVERED — COPILOT STILL DOWN. At 16:59 UTC GitHub declared the degradation mitigated across API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks, and all seven are back to Operational. Copilot was not named in that update and is still marked as a Major Outage. The incident remains open while GitHub monitors for stability.
Last confirmed: 17 August 2026, 16:59 UTC (22:29 IST). This post is updated as GitHub posts new information.
Is it broken for you too? Report what's failing on our Downbits GitHub tracker — API, login, website or DNS. The more reports come in, the faster everyone else can tell whether it's GitHub or their own setup.
GitHub broke for developers worldwide for three hours and nineteen minutes, with roughly one in five requests to the website and the API returning errors, and about half of all archive downloads and raw repository content requests failing outright. The incident opened at 13:40 UTC (19:10 IST) on 17 August 2026 and widened steadily until GitHub declared seven of the eight affected services mitigated at 16:59 UTC. Copilot was not one of them.
The practical effect was larger than the error percentages suggest. A 50% failure rate on archive downloads and raw content means package installs that pull from GitHub, Docker builds that fetch files over raw github user content, and Go module downloads were all failing intermittently. Combined with a Major Outage on Actions, most CI/CD pipelines that touch GitHub in any way were unreliable for the entire affected window.
Is GitHub Down Right Now?
Not any more, with one exception. GitHub's own status page now shows every affected service back to Operational except Copilot, which is still marked as a Major Outage. Here is the component-by-component state as of the most recent check:
| Service | Current state | 90-day uptime |
|---|---|---|
| Copilot | Major Outage | 99.84% |
| API Requests | Operational | 99.82% |
| Issues | Operational | 99.88% |
| Pull Requests | Operational | 99.88% |
| Actions | Operational | 99.33% |
| Git Operations | Operational | 99.99% |
| Webhooks | Operational | 99.99% |
| Pages | Operational | 99.65% |
| Packages | Operational | 100.0% |
| Codespaces | Operational | 99.97% |
| Copilot AI Model Providers | Operational | 99.88% |
Those uptime figures moved measurably across the afternoon. Actions fell from 99.39% to 99.33%, API Requests from 99.87% to 99.82%, and Issues and Pull Requests from 99.94% to 99.88%. Roughly three hours of downtime was written into GitHub's 90-day record in a single sitting.
The omission is worth dwelling on. GitHub's 16:59 update named seven services individually and said nothing about Copilot, yet Copilot is the one component its own dashboard still flags as a Major Outage. Either it recovered on a separate track that GitHub has not described, or it was left out by oversight. GitHub has not clarified which.
What Is Broken and What Still Works
Beyond the headline services, GitHub confirmed during the incident that SAML and OIDC authentication, SCIM provisioning, and Team Sync were affected. For enterprise customers that was the most disruptive part — organisations using single sign-on saw developers unable to authenticate at all, and automated user provisioning stopped flowing. GitHub's mitigation update did not address these separately, so treat SSO as recovered alongside the core services rather than confirmed independently.
Copilot is now the outlier. The Copilot AI model providers stayed operational for the whole incident, so whatever is keeping Copilot itself down sits in GitHub's own authorisation and routing layer rather than with any upstream AI provider. Packages and Codespaces were never affected at all.
Full Timeline of the GitHub Outage
All times 17 August 2026. UTC first, IST in brackets.
- 13:40 UTC (19:10 IST) GitHub opens the incident, reporting impacted performance for some services.
- 13:41 UTC (19:11 IST) API Requests degraded.
- 13:42 UTC (19:12 IST) Actions degraded.
- 13:44 UTC (19:14 IST) Webhooks degraded.
- 13:45 UTC (19:15 IST) GitHub quantifies it for the first time — a roughly 20% error rate across Pull Requests, Issues and other experiences.
- 13:46 UTC (19:16 IST) Issues degraded.
- 13:58 UTC (19:28 IST) Pull Requests degraded.
- 14:04 UTC (19:34 IST) Scope widens: 20% error rate on web and API traffic, and around 50% on archive downloads and raw repository content. Root cause still unknown.
- 14:24 UTC (19:54 IST) SAML and OIDC authentication, SCIM and Team Sync added to the impact list.
- 14:31 UTC (20:01 IST) Copilot degraded.
- 14:45–14:58 UTC (20:15–20:28 IST) Pull Requests, Issues, Actions and Webhooks are each escalated from degraded performance to degraded availability.
- 14:58 UTC (20:28 IST) GitHub says it is applying mitigations based on its investigation so far and monitoring for improvement.
- 15:01 UTC (20:31 IST) API Requests escalated to degraded availability.
- 15:10 UTC (20:40 IST) Pages degraded.
- 15:21 UTC (20:51 IST) Git Operations degraded — the first sign that core clone, fetch and push traffic is affected.
- 15:42 UTC (21:12 IST) Impact figures unchanged. GitHub says it is applying mitigations.
- 16:16 UTC (21:46 IST) More than two and a half hours in, GitHub states it is still working to identify the root cause — the error rates are unchanged from the 14:04 update.
- 16:36 UTC (22:06 IST) The turn. GitHub says it has identified the problematic component, taken corrective action, and is seeing "strong signs of recovery", with error rates still slightly elevated.
- The incident remains open.
- 16:59 UTC (22:29 IST) GitHub declares the degradation affecting API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks mitigated, and moves to monitoring. All seven return to Operational. Copilot is absent from the update and stays at Major Outage.
Has GitHub Said What Caused It?
Partly. At 16:36 UTC, nearly three hours into the incident, GitHub said it had identified the problematic component and applied corrective action. It has not said what that component is.
The wording matters. Twenty minutes earlier, at 16:16 UTC, GitHub was still reporting that it was working to identify the root cause, with error rates unchanged from where they had sat since 14:04. Between those two updates, engineers found something and pulled it. Identifying a faulty component is not the same as understanding why it failed, so a full root cause analysis is still pending — GitHub publishes these for most significant incidents, usually within a few days.
The shape of the failure was informative even before that. Error rates were partial rather than total, consistent at around 20% for web and API traffic, with content-serving paths failing at more than double that rate. That pattern points to a subset of infrastructure — a shard, a cluster, a region or a degraded dependency — rather than a total collapse, which is why some users reported GitHub working normally while others could not load a pull request.
GitHub's August 2026 Reliability Record
This is not an isolated bad day. Today's incident is the 13th separate incident GitHub has logged in the first 17 days of August 2026, spread across nine different days. The pattern is more revealing than any single outage:
| Date | Incident | Documented cause |
|---|---|---|
| 3 Aug | Copilot chat and agent errors, ~4,066 users affected in one hour | Model-list requests exceeded an internal rate limit |
| 5 Aug | 100% of new Copilot cloud agent jobs are delayed for 52 minutes | Rate limit applied more broadly than intended |
| 6 Aug | GitHub Pages — around 128,000 deployments not processed | The configuration change cut processing capacity |
| 6–7 Aug | Actions down over 9 hours; 71% of workflow runs failing at peak | Routine deployment exposed a capacity and concurrency weakness |
| 10 Aug | Fine-grained personal access tokens silently failed to create | The front-end JavaScript change broke the confirmation step |
| 11 Aug | GraphQL API timeouts | Resource contention from high utilisation at one site |
| 12 Aug | 500 errors on Pull Requests, Issues, and Search | Query hint pointed at an index that a migration had removed |
| 12 Aug | Log in and release asset download failures | Not published |
| 13 Aug | Three incidents — Webhooks, Copilot models, GHEC Team Sync | Background job, upstream provider, sync degradation |
Two themes run through almost all of them: capacity headroom and change management. Configuration changes and routine deployments repeatedly pushed services past limits that were not being monitored closely enough to catch before customers did. GitHub's own write-up of the 6 August Actions failure conceded that its availability metrics had not fully captured the impact.
The cost shows in the 90-day uptime figures. Actions sits at 99.33%, which works out to roughly 14 and a half hours of downtime in 90 days — an order of magnitude worse than the 99.99% that Git Operations and Webhooks maintain. Pages at 99.65% translates to about seven and a half hours. For teams whose deployment pipeline runs entirely on Actions, that is a meaningful business risk, not a rounding error.
What Developers Should Do Right Now
Check Copilot separately. Everything else is mitigated, but Copilot is still marked as a Major Outage and GitHub has given no timeline for it. If chat or agent features are failing in your IDE, that is the incident, not your configuration.
Assume workflow triggers are being lost. In the 6 August Actions incident, GitHub confirmed that push and pull request events dropped during the outage could not be replayed automatically — affected users had to push a new commit or re-run workflows manually. Audit your workflow runs from the 13:40–16:59 UTC window now and re-trigger anything that never fired.
Pin your dependencies elsewhere if you can. Builds that fetch tarballs or raw files from GitHub during the build step are failing roughly half the time. If you have a package registry mirror or vendored dependencies, use them until this clears.
Enterprise SSO admins should hold off on user provisioning changes. SCIM and Team Sync are affected, so team membership changes made now may not apply correctly or may apply late.
Do not force-push or run migrations against a repository during degraded Git operations. Partial failures during write operations are the worst time to be doing anything irreversible.
How to Check GitHub Status Yourself
The canonical source is GitHub status. GitHub Enterprise Cloud customers should check their regional page instead, because these track separate infrastructure: GitHub US, GitHub EU, GitHub AU, and GitHub JP.
For automated monitoring, GitHub publishes an Atom feed and an RSS feed of incident history, and supports email, SMS, Slack, and webhook notifications. Teams that depend on GitHub for deployments should wire the webhook into their own alerting rather than finding out from a failed build.
Official status pages tell you what a vendor has admitted to. They do not tell you what is breaking for people in your region, on your ISP, or in the specific corner of the product you happen to use. For that side of the picture, our sister site Downbits runs a GitHub outage tracker where you can see what other developers are reporting and add your own report — API, login, website or DNS. If Git operations are failing for you but the status page still says degraded rather than down, that gap is worth logging.
Disclosure: Downbits is operated by the Cyber Kendra team.
Related: this is the second major infrastructure failure to hit developers and site owners this month. See our full coverage of the Namecheap outage, which took hosting and DNS offline for more than 30 hours after a cooling failure at its Phoenix data centre.
Frequently Asked Questions
Is GitHub down for everyone?
No. This is a partial outage with roughly a 20% error rate on web and API traffic, so many requests still succeed. Whether you notice it depends on which service you are using and how lucky your individual requests are.
When will GitHub be back up?
Most of it already is. GitHub mitigated the degradation across API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks at 16:59 UTC and moved to monitoring. Copilot was left out of that update and is still marked as a Major Outage, with no separate timeline given.
Are git push and git clone working?
Yes. Git Operations was degraded from 15:21 UTC and confirmed mitigated at 16:59 UTC. Clone, fetch and push are back to normal, and were never fully down.
Are my repositories or data at risk?
Nothing GitHub has published points to data loss or a security incident. This is an availability problem, and no breach or compromise has been indicated.
Why is GitHub Copilot not working?
Copilot is the one service that has not recovered. GitHub's 16:59 mitigation update covered seven other services and omitted Copilot, which is still marked as a Major Outage. The Copilot AI model providers are operational, so the failure is in GitHub's own service layer rather than the underlying models.
Is this related to Microsoft or Azure?
GitHub has not attributed the incident to any upstream provider, and no Azure connection has been stated. Treat any such claim as unconfirmed until GitHub publishes a root cause analysis.
Updates
2026-08-17, 16:59 UTC (22:29 IST) — GitHub declares the degradation mitigated across API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks and moves to monitoring. All seven show Operational. Copilot is not mentioned and remains at Major Outage. The incident is not yet resolved.
2026-08-17, 16:36 UTC (22:06 IST) — GitHub has identified the problematic component and applied corrective action, reporting strong signs of recovery with error rates still slightly elevated. The component it found has not been named. The incident remains open and the status dashboard still shows five services in Major Outage.
2026-08-17, 16:16 UTC (21:46 IST) — GitHub says it is still working to identify the root cause. Error rates unchanged.
2026-08-17, 15:42 UTC (21:12 IST) — Incident ongoing. Five services in Major Outage. GitHub applying mitigations, no root cause published. Error rates approximately 20% for web and API, and 50% for archive downloads and raw content.
This is a developing story. We are tracking GitHub's status page and will update this post as recovery continues and when GitHub publishes its root cause analysis.