Is Netlify down? Live reachability check

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”

Netlify 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 Netlify.

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 Netlify: www.netlifystatus.com. Product behaviour and troubleshooting documentation: docs.netlify.com. 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 Netlify, and no data here carries a guarantee of accuracy or availability.