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.
Reachability
DNS / TCP / TLS for GitHub Codespaces surfaces
- GitHubgithub.com root—msfirst check running
- Codespaces hostgithub.com/codespaces—msfirst check running
- GitHub APIapi.github.com base—msfirst check running
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?
Why is my GitHub Codespaces stuck on loading?
Is Codespaces down or is it my network?
Is GitHub Codespaces down right now?
Why is my Codespace stuck on 'Starting'?
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.