Skip to main content
GitHub Codespaces

Is GitHub Codespaces down? Live reachability check

Container-based dev environments from GitHub

Live GitHub Codespaces reachability — the container-based dev environment tied to GitHub, checked from your browser against public GitHub surfaces.

This page checks from your browser whether GitHub's public hostnames used by Codespaces answer a request. Those responses are opaque, so it cannot see whether a dev container will actually start, and it never touches your signed-in sessions. githubstatus.com is the authority on confirmed Codespaces incidents; if it reports everything healthy while your Codespace fails, the cause is usually a container build error, an organisation policy, or a local network that blocks the WebSocket connection the editor needs.

GitHubCodespaces reachability check

Requests sent from your own browser to GitHubCodespaces's public hostnames, repeated every 15s. This measures whether those hostnames answer you — not whether every GitHubCodespaces feature is working.

Running first check…

Reachability

DNS / TCP / TLS for GitHub Codespaces surfaces

3 endpoints
  • GitHub
    github.com root
    —ms
    first check running
  • Codespaces host
    github.com/codespaces
    —ms
    first check running
  • GitHub API
    api.github.com base
    —ms
    first check running
Sampling every 15s · Last updated — · Next in 15s · Percentages cover only the 20 most recent samples from this browser tab; nothing is stored or aggregated across visitors.Open GitHubCodespaces ↗

Codespaces runs inside github.com; there is no dedicated public API for browser-based reachability. These checks confirm GitHub's surfaces are up. Container start failures and region incidents show on GitHub's official status page.

About GitHubCodespaces

GitHub Codespaces spins up a full VS Code dev environment inside a container tied to a GitHub repo. Because the surface lives at github.com, its availability tracks GitHub itself — but container start times and region routing add extra failure modes on top.

GitHubCodespaces at a glance

Launched
2020 (GA 2021)
Parent
GitHub (Microsoft)
Runtime
Dev container (OCI image)
Free tier
60 core-hours/month (personal)
Regions
Multi-region (auto-selected)

Common GitHubCodespaces issues

  • Container start timeout

    Custom dev containers can time out at build. Push a simpler devcontainer.json or use a prebuild to cache heavy setup.

  • Port forwarding not working

    Private forwarded ports require signed-in access. Mark the port Public in the Ports tab or share the URL from an authenticated session.

Background

GitHub launched Codespaces in 2020 as a browser-based VS Code environment powered by cloud containers. It went generally available in 2021 and became a core piece of GitHub's developer experience story after the Microsoft acquisition.

Frequently asked

How do I know if GitHub Codespaces is down?
Check the official GitHub Status dashboard at githubstatus.com or use replit.health to test live reachability. If public GitHub API services or Codespaces containers fail to respond, an outage is likely occurring.
Why is my GitHub Codespaces stuck on loading?
A stuck Codespace usually indicates container build failures, network timeout issues, or corrupted devcontainer configurations. Rebuilding the container or launching from a different region often resolves transient loading stalls.
Is Codespaces down or is it my network?
If githubstatus.com reports green but your Codespace fails, check your local firewall, VPN, and corporate proxy settings. WebSocket connections on standard ports are required for Codespaces terminal communication.
Is GitHub Codespaces down right now?
Green dots on github.com and api.github.com mean the front doors are reachable. Codespaces-specific incidents (container start failures, region outages) are reported on GitHub's status page.
Why is my Codespace stuck on 'Starting'?
Most stuck starts are region-level capacity issues or a prebuild that hasn't finished. Try a smaller machine type or a different region.

Learn more

How this check works, and what it cannot tell you

Every measurement on this page is produced by your own browser, not by a server we run. When the page loads, it issues a fetch() request to each hostname listed above, records how long the request took to settle, and repeats the cycle every 15 seconds for as long as the tab stays open. There is no backend collector, no historical database, and no shared uptime figure — reload the page and the sample window starts over.

Why the results are “reachability”, not “status”

GitHubCodespaces does not publish permissive cross-origin (CORS) headers on the hostnames worth checking, so the browser will not let this page read the response. The requests therefore run in no-cors mode and come back as opaque responses: the fetch resolves, but the status code, headers and body are all withheld by the browser's security model. That has one consequence worth being blunt about — a 200, a 500, a rate-limit page and a maintenance splash screen are indistinguishable from each other here. All four resolve, and all four light the dot green.

What a green dot does establish is a real, complete chain: your DNS resolver answered, a TCP connection opened, the TLS handshake succeeded, and the far end returned something. That chain is genuinely useful, because it is exactly the part that breaks during DNS misconfigurations, expired certificates, edge routing failures and total regional outages. It is also the part your own firewall, VPN, corporate proxy or DNS filter breaks — which is why a red dot here should be cross-checked from a different network before you conclude anything about GitHubCodespaces.

What this page does not measure

  • Anything behind a login. Workspaces, containers, dashboards and account state all require an authenticated session, which this page never has.
  • Feature-level health. Editor sessions, language servers, AI agent runs, build queues and deployment rollouts can be badly degraded while the public hostnames answer normally.
  • Incident scope. This page cannot distinguish a global outage from a problem on your connection; only the operator's own status page can confirm scope.
  • Latency attribution. The millisecond figures include your network path and your device, so they are a rough comparison between endpoints at one moment, not a measurement of server performance.

How to read it in practice

Treat the board as a first, fast signal and the operator's status page as the authority. Red here plus red on the official page is a confirmed incident: wait it out rather than making destructive changes. Green here plus a posted incident means the failure is in a subsystem this page cannot see. Red here plus a green official page most often means something local — test from a phone hotspot to confirm before troubleshooting further.

Primary sources. Authoritative incident and maintenance history for GitHubCodespaces: www.githubstatus.com. Product behaviour and troubleshooting documentation: docs.github.com/en/codespaces. Opaque-response behaviour is defined by the Fetch standard's no-cors request mode; see MDN: Request.mode. More on interpreting these checks in our resources.

This is an independent, unofficial page. It is not affiliated with, endorsed by, or sponsored by GitHubCodespaces, and no data here carries a guarantee of accuracy or availability.