Status: RECOVERING, NOT RESOLVED. GitHub says it has identified the component behind the failure and taken corrective action, and is seeing strong signs of recovery. Error rates remain slightly elevated and the incident is still open. The status dashboard has not yet been downgraded — API Requests, Issues, Pull Requests, Actions and Copilot are all still marked as a Major Outage.
Last confirmed: 17 August 2026, 16:36 UTC (22:06 IST). This post is updated as GitHub posts new information.
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. Do report the issue on the site so that others too can know about the problem
GitHub broke for developers worldwide for close to three hours, 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 reported the first real progress at 16:36 UTC.
The practical effect is 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 have been unreliable for the entire afternoon.
Is GitHub Down Right Now?
Yes, though recovery is underway. GitHub's own status page confirms the incident, and this is a genuine platform-wide problem rather than a local network issue. Here is the component-by-component state as of the most recent check. Note that the dashboard has not yet been downgraded to reflect GitHub's 16:36 recovery update, so these markers lag what engineers are reporting:
| Service | Current state | 90-day uptime |
|---|---|---|
| API Requests | Major Outage | 99.83% |
| Issues | Major Outage | 99.90% |
| Pull Requests | Major Outage | 99.90% |
| Actions | Major Outage | 99.35% |
| Copilot | Major Outage | 99.86% |
| Git Operations | Degraded Performance | 99.99% |
| Webhooks | Degraded Performance | 99.99% |
| Pages | Degraded Performance | 99.65% |
| Packages | Operational | 100.0% |
| Codespaces | Operational | 99.97% |
| Copilot AI Model Providers | Operational | 99.88% |
Those uptime figures are moving in real time. Over the course of this incident, Actions has slipped from 99.39% to 99.35%, API Requests from 99.87% to 99.83%, and Issues and Pull Requests from 99.94% to 99.90%. Each of those fractions represents close to an hour of additional downtime being written into GitHub's 90-day record while the incident runs.
Worth noting for anyone cross-checking: GitHub's incident page still lists the affected components as Webhooks, API Requests, Issues, Pull Requests, and Actions, even though its own updates have since added Copilot, Pages, and Git Operations. The component dashboard is the more current of the two.
What Is Broken and What Still Works
Beyond the headline services, GitHub has confirmed that SAML and OIDC authentication, SCIM provisioning, and Team Sync are affected. For enterprise customers, that is the most disruptive part of this incident — organisations using single sign-on may find developers unable to authenticate at all, and automated user provisioning has stopped flowing.
Packages, Codespaces, and the Copilot AI model providers are still reporting normal operation. Copilot itself is in Major Outage, but the underlying model infrastructure is healthy, which points at GitHub's own authorisation and routing layer rather than any AI provider problem.
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.
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.35%, which works out to roughly 14 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
Do not retry aggressively. With a partial error rate, hammering failed requests adds load to the infrastructure that is already struggling and makes recovery slower for everyone.
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. Expect to audit and re-trigger once this incident is resolved.
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?
GitHub has not given a completion time, but recovery is underway. As of 16:36 UTC it had identified and corrected the faulty component and was reporting strong signs of recovery, with error rates still slightly elevated and the incident not yet closed.
Are git push and git clone working?
Git Operations moved to degraded performance at 15:21 UTC, so clone, fetch and push may still be slow or fail intermittently as recovery progresses. They were not fully down at any point.
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 in Major Outage as part of this incident. The Copilot AI model providers remain 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: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.