GitHub Actions and Issues Degraded Oct. 12, Stalling Vercel Builds for GitHub-Connected Projects
GitHub mitigated Oct. 12 degradation in Actions, Issues and Projects but notifications remain backlogged, while Vercel confirms GitHub-connected builds are failing. What agent teams should pause and check.
From 12:21 UTC onward on Oct. 12, GitHub worked through an afternoon degradation that hit the exact surfaces coding-agent teams live in: Actions, Issues, Projects, and notifications. Vercel then confirmed the impact extended downstream, with GitHub-connected builds and deployments failing or queuing.
If your overnight lanes, fix-loops, or deploy previews looked flaky during that window, do not debug the agent first. Check the upstream incident, pause retries, and hold merges and production promotions until three signals clear: the GitHub incident is resolved and notification delays clear, the Vercel build incident is resolved, and your own canary completes end-to-end.
What broke
GitHub opened the incident with Actions, Pull Requests and Issues at 12:21 UTC on Oct. 12, reporting degraded performance for Actions, Issues and Pull Requests. By 12:33 UTC it detailed the symptoms: trouble loading the Actions tab UI, interacting with the Checks API, queueing new Actions runs, creating and updating issues, and requesting PR reviews, including via REST and GraphQL APIs.
That list matters for agents. Checks API gaps break status-gated merges. Queueing delays stall on: pull_request workflows, scheduled runs, and agentic fix-loops that open a PR, wait for CI, then iterate. Issue create and update errors break triage bots and task-sync workflows. PR review-request errors break auto-reviewer assignment.
GitHub said Pull Requests was operating normally at 13:02 UTC, then warned at 13:38 UTC that its initial mitigation was not fully successful, with delays and errors continuing across Actions, issues and projects, plus delayed notifications. Later updates report Issues mitigated at 14:35 UTC and Actions mitigated at 14:36 UTC with monitoring for stability, followed by a broader Actions, issues and projects mitigation at 14:37 UTC with a notification fix still in progress.
The latest posted updates shift the remaining work to notifications. At 15:19 UTC GitHub said it applied a mitigation for notifications and they had resumed but would stay delayed while working through a backlog. The 15:50 UTC update repeats that state: notifications have resumed but will continue to be delayed as the backlog clears. The incident remained unresolved on the GitHub Status overview at capture time, even while that overview listed Actions, Issues, Pull Requests, Git Operations, Webhooks and API Requests as Operational.
Vercel confirms downstream build failures
Vercel opened a separate increased build and deployment failures incident at 13:35 UTC, initially describing build failures and deployments that fail to start. It moved to Identified at 14:08 UTC, then noted at 14:57 UTC that failure rates had decreased but some builds remained queued and were taking longer to start.
At 16:10 UTC Vercel explicitly tied its incident upstream: due to an upstream incident at GitHub, some builds and deployments for GitHub-connected projects are still failing. It lists the affected components as Build and Deploy Builds and CI and CD Git Integrations.
For agent teams the sourced effect is narrow but consequential: some GitHub-connected builds and deployments are still failing, some builds were queued and slow to start at 14:57 UTC, and deployments can fail to start. Treat a stalled preview or failed production deploy during this window as a possible downstream effect of that unresolved incident, not as proof of a broken prompt or application change.
What to do with agent lanes right now
Treat this as an upstream degradation, not a prompt or code regression. The highest-leverage move is to stop the loop from amplifying it.
| If you see | Do this | Why |
|---|---|---|
| Actions runs stuck in queued or waiting, Checks never report | Pause scheduled and retry-heavy workflows, keep one canary | Limits extra load while providers work through queues |
| Issue-creation or PR-review calls failing from bots | Queue work locally, back off with jitter, do not spam retries | GitHub flagged REST and GraphQL errors for those calls |
| Vercel GitHub-connected deploys failing or stuck | Hold auto-merges and production promotions until recovery signals clear | Vercel attributes continuing failures to the GitHub incident |
| Missing notifications | Assume silent success or silent failure, verify state via UI or API before acting | GitHub says notifications are resumed but backlogged |
A minimal status check before you rerun anything:
# check the canary workflow, not the whole matrix
gh run list --workflow ci.yml --limit 5
gh run view <run-id> --json status,conclusion,updatedAt
# example: pause new triggers from the agentic fix-loop while queue times are elevated
# disabling stops new triggers; it does not cancel runs already queued or running
gh workflow disable "agent-fix-loop.yml"
# re-enable only after GitHub and Vercel both report recovery and the canary passes
gh workflow enable "agent-fix-loop.yml"
For Vercel-connected repos, check the deployment list for QUEUED or FAILED before promoting a preview to production. Vercel said at 14:57 UTC some builds remained queued and slow to start, and at 16:10 UTC some GitHub-connected builds and deployments were still failing.
This follows a busy week for GitHub reliability. The team already dealt with four-hour Actions degradation on Oct. 5 where nearly half of workflow runs failed at peak, plus two resolved degradations on Oct. 7 affecting Git, Pull Requests, Issues and Actions. For broader practice on self-healing pipelines and machine commits, see Agentic CI/CD.
What remains and what to watch
As of the latest verified updates, Actions, Issues and Projects mitigations are in place and being monitored, while notifications are delayed by backlog. Vercel still reports continuing failures for GitHub-connected projects tied to that upstream incident.
Watch for three signals before resuming normal agent throughput:
- GitHub marks the incident resolved and notification delays clear.
- Vercel marks its build incident resolved, not just decreased failure rates.
- Your own canary workflow completes end-to-end, including Checks reporting, issue write-back, and Vercel preview deployment.
Until then, keep lanes in degraded mode: hold merges and production promotions, keep retries throttled, and require explicit human sign-off on any deployment an agent already started during the window.