Is GitHub Copilot Down? Checking Status and Working Around It

To see whether GitHub Copilot is down, open githubstatus.com, GitHub’s official status page. It lists Copilot as its own component, and separately lists Copilot AI Model Providers, so you can tell a Copilot-wide incident from a problem with one vendor’s models. If both show as operational and Copilot still fails, the cause is usually not an outage: it is a rate limit, a used-up AI credit allowance, a sign-in problem, a proxy or certificate on your network, or a file your organization has excluded. The error message usually says which. Below is how to read the page, how to tell those apart, and what to do while you wait.

Check the official status page first

The GitHub status page↗ (opens in a new tab) is where GitHub posts incidents and updates them until they are resolved. GitHub’s own advice for slow Copilot responses starts there, to confirm whether an ongoing incident is affecting Copilot or related services. Third-party “is it down” sites collect user reports, which can be a useful second opinion, but they show what people are experiencing rather than what GitHub has confirmed. As of September 30, 2026 the page lists these components:

• Copilot: the Copilot service itself.
• Copilot AI Model Providers: the models Copilot calls. Incidents here often name one provider or model.
• Git Operations, API Requests, Webhooks, Issues, Pull Requests, Actions, Packages, Pages and Codespaces: the rest of GitHub, which Copilot’s agents depend on.

The Copilot AI Model Providers component is the one to understand. In September 2026 alone, the incident history included elevated errors for OpenAI models provided by Copilot and a degradation of one Gemini model, each while other models kept working. When the incident names a model, switching to another one is often all you need. Not every incident is tied to a component, either: a Copilot code review incident on September 28, 2026 was posted without one, so read the incident titles, not only the colored bars.

The cloud agent works on GitHub Actions and returns its work as a pull request, so an Actions or Pull Requests incident can stop it even when the Copilot component is green.

Get told instead of checking

Subscribe to Updates on the status page offers email, text message, Slack and webhook notifications, and the incident history is available as RSS and Atom feeds. A Slack subscription in a shared channel saves a team from checking separately.

Errors that are not outages

Most “Copilot is down” moments are one of these. Read the exact message.

• A rate limit: “You’ve hit a rate limit.” GitHub’s page on usage limits↗ (opens in a new tab) says rate limits are temporary and the advice is to wait and try again, and to look at your usage if you are sending frequent or automated requests. The message may give a reset time.
• AI credits used up: since June 1, 2026, Chat, agent mode, the CLI and the cloud agent spend a monthly allowance of GitHub AI Credits. When it is gone, the options are a budget for additional usage, an upgrade or the monthly reset. Inline completions on paid plans are not billed in credits, so completions working while chat fails is a clue.
• “GitHub Copilot could not connect to server”: often a missing Copilot plan on the account you are signed in with, or a stale token. Sign out of Copilot and back in to get a new one.
• Network: read ETIMEDOUT or read ECONNRESET usually means a proxy. GitHub’s guide to network errors↗ (opens in a new tab) notes that https:// proxy URLs are not supported.
• Certificates: “unable to verify the first certificate” or “certificate signature failure” usually means a corporate proxy or security software inspecting traffic. Install the company certificate in your operating system’s trust store rather than turning off strict SSL.
• Copilot silent in some files: your organization may have excluded them. The Copilot icon in the status bar shows a diagonal line, and new exclusion settings can take up to 30 minutes to reach an IDE.
• Agent missing from the picker: a setting, a policy or an old VS Code, not an outage. See GitHub Copilot agent mode not working.

Is it you or them? A two-minute check

1. Open githubstatus.com and look at Copilot and Copilot AI Model Providers, then the incident titles.
2. Read the whole error. A reset time means a limit; “connect” or “certificate” means your network; “rate limit” means wait.
3. Try another model, or Auto. If one model fails and another works, it is the provider, not you.
4. Try another surface: Copilot Chat on GitHub.com if the IDE fails, or the IDE if the CLI fails.
5. Test the connection from your machine with the commands below. Each should return HTTP 200.
6. Update the Copilot extension and restart the editor. If it still fails, collect the extension’s logs before you ask for help.

# completions endpoint
curl --verbose https://copilot-proxy.githubusercontent.com/_ping

# chat endpoint
curl --verbose https://api.githubcopilot.com/_ping

# through an HTTP proxy
curl --verbose -x http://YOUR-PROXY-URL:PORT -i -L https://copilot-proxy.githubusercontent.com/_ping

What to do meanwhile

Keep working on something else

• Switch model. GitHub’s page on auto model selection↗ (opens in a new tab) says Auto tracks real-time health and availability of each model before routing a request, so Auto is a sensible fallback during a provider incident. Which models you can pick is in GitHub Copilot models.
• Switch surface. Chat on GitHub.com, the IDE, Copilot CLI and the GitHub Copilot app share an account but not always the same failure.
• Use your own model. In VS Code, Manage Models adds a provider with your own key; the GitHub Copilot app and the CLI can also use your own provider. On Business and Enterprise a policy has to allow it.
• Wait out a rate limit rather than retrying in a loop. Repeated automated requests make it worse.

Or stop cleanly

An outage in the middle of an agent task mostly costs you context. Three habits make restarting easy:

• Commit or stash what is on disk. The agent’s edits are only files; git keeps them safe whatever happens to the session.
• For the cloud agent, the work lives on its branch and pull request, so a failed session can be picked up by asking @copilot again in the pull request once the incident clears.
• Write down where you stopped: what was done, what was half done, and the next step. That note is what lets a fresh session, or a different assistant, carry on without starting over.

Keep the state on a board, not in the session

The third habit pays off beyond outages. If the plan and progress live only in a chat, an incident, a rate limit or a closed editor costs you the thread. On fenbs, the task holds it: the note says what the problem is, the plan says how it will be done, a comment records where the work stopped, and the test status says what was checked. Copilot connects to fenbs over MCP at https://fenbs.ai/api/mcp; when the service is back, a new session calls fenbs_get_context, reads the rules on the Decisions and rules page and the tasks In Progress, and carries on. History shows which assistant changed what, so you can see what finished before it stopped. fenbs is an online service too; Copy as Markdown puts the board on your clipboard if you want a copy to keep. Handoff notes in detail: handing work between AI agents and people.