GitHub Outage: Git Operations, Pull Requests, and Actions

GitHub's status page logged an incident titled Incident with Git Operations, Pull Requests and Actions on October 7, 2026. Widespread impact occurred from 15:06 to 15:16 UTC, with webhooks and issues also degraded. The incident was opened at 15:14 and resolved at 16:25 UTC, with GitHub stating it had identified the root cause and was applying mitigations.

A second critical incident followed, with widespread impact from 16:52 to 17:01 UTC, opened at 17:17 and resolved at 18:04 UTC. GitHub said it had applied mitigations and did not anticipate another recurrence, and that a detailed root cause analysis would be shared.

GitHub's status history also shows critical incidents affecting Actions and Pages on October 5, from 19:11 to 22:49 UTC, and degraded webhooks and pull requests on October 6, from 19:57 to 23:40 UTC. Whether these were related had not been stated.

GitHub had not published a root cause at the time of writing. Explanations circulating in commentary, such as infrastructure failover problems or load from AI agents, were not confirmed by GitHub and should be treated as speculation until the root cause analysis appears.

Ten minutes of failed Git operations can break CI pipelines, fail deploys mid-rollout, drop webhook-triggered automation, and leave pull request checks in inconsistent states. Teams often spend far longer than the incident itself cleaning up retries and stuck jobs.

Make deploy pipelines idempotent and safe to retry, avoid partial deploys when a step fails, and ensure rollbacks do not depend on the same provider that is failing. Keep a documented manual deploy path for emergencies.

Webhooks may be delayed or dropped during incidents. Consumers should reconcile state periodically rather than relying solely on events, and providers' redelivery features should be used after incidents to catch missed events.

Mirroring critical repositories and caching dependencies internally lets builds continue during source host outages. Artefact registries independent of the source host keep deployments possible.

GitHub's status updates gave impact windows and a commitment to a root cause analysis. Customers should subscribe to provider status feeds, correlate them with internal alerts, and record provider incidents in their own incident records so postmortems reflect external causes accurately.

Log every provider incident that affects you, with impact and duration. Over a quarter, this data supports decisions about redundancy, mirrors, and contractual expectations.

Read provider postmortems for lessons that apply to your own systems: failover behaviour, recurrence after mitigation, and how detection worked. Recurrences within an hour are common when mitigation addresses symptoms before the underlying trigger is removed.

October 5 Actions and Pages incident; October 6 webhooks and pull requests degradation; October 7 two critical incidents at 15:06 and 16:52 UTC, per GitHub's status page.

Short provider outages cause long cleanups. Make pipelines retry-safe, reconcile webhooks, mirror critical repositories, and track provider incidents in your own records.

During the incident, which of your pipelines failed, which deploys were interrupted, and which webhooks went missing? Recording this in your own incident record turns a provider outage into a list of resilience improvements for your systems, independent of what the provider's root cause analysis eventually says.

Subscribe to GitHub's status updates in the channel your on-call team watches. When builds fail suddenly, the first check should be provider status, saving time otherwise spent debugging your own code.

After recovery, re-run failed pipelines deliberately rather than all at once, check for half-completed deploys and roll forward or back, redeliver missed webhooks, and verify pull request checks reflect actual results. A short checklist for this cleanup saves hours of confusion.

Many organisations run source control, CI, package registries, and project management on one platform. Convenience creates a single point of failure. For critical services, consider which of these functions need an independent fallback during a forge outage.

Root cause analysis pending at the time of writing.