Netlify status

How we check Netlify

We watch www.netlify.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

Netlify serves its own marketing site from the same CDN that serves customer sites, which makes it a real signal about the delivery path rather than a health endpoint that reports on itself. We deliberately do not watch the dashboard or the build API, because those can be degraded while every deployed site keeps serving perfectly, and treating them as the same thing would make this page cry wolf.

What is Netlify?

Netlify hosts and delivers web front ends: a repository is built into static files and functions, those are pushed out to a content delivery network, and visitors are served from a location near them. Deploys are atomic, so a site is either fully on the old version or fully on the new one, and rollbacks are close to instant. For teams that once ran a web server and a deploy script, Netlify replaces both, which is convenient right up to the point where you need to work out which half of it is having a bad day.

That split between building and serving is the most useful distinction during an incident. Build infrastructure and the CDN fail separately. When builds are queued or failing, the site your visitors load is untouched, because it was deployed earlier and is being served from the edge without needing the build system at all. The cost is that you cannot ship, which is frustrating but not customer-facing. When the CDN is degraded, the inverse applies: the dashboard may work perfectly, builds may succeed, and none of it helps, because the path between visitors and your content is the part that has failed. Reaching for a redeploy during a delivery incident is a common instinct and an unhelpful one.

Most Netlify-hosted sites that go down do so for reasons Netlify is not responsible for, and it is worth being blunt about that before assuming an outage. A custom domain depends on DNS records that live at your registrar and on a certificate that has to be issued and renewed for that exact hostname. Either can break while Netlify is entirely healthy, and both produce a site that will not load in a browser. Redirect rules, headers, and proxy rewrites are configuration you control, and a change to them takes effect on the next deploy without any warning that it will break a path you did not test. The first question worth asking is whether the netlify.app subdomain still serves the same content, because that single check separates a platform problem from a domain problem in about ten seconds.

Geography adds the last complication. A CDN by design serves different visitors from different locations, so a regional degradation is invisible to anyone testing from elsewhere. A colleague reporting a site that will not load, while everyone else sees it working, is not necessarily confused. Reading the per-region response times above separately, rather than as one averaged verdict, is what makes that pattern visible instead of getting smoothed away.

Frequently asked questions

Is Netlify down right now?

Check the board above; it reflects our own probes against Netlify's CDN from all five of our regions, refreshed every couple of minutes and confirmed across two regions before this page would call it down.

My Netlify build is failing but my site is still up. Is that an outage?

Usually not, and the two are worth separating. Builds run on Netlify's build infrastructure, while your live site is served from the CDN, so a build queue that has stalled leaves the previously deployed version serving visitors normally. Check the deploy log for the failing build first, since a dependency that changed or a missing environment variable produces exactly this pattern with nothing wrong on Netlify's side.

Do Netlify Functions failures show up here?

No. This page measures whether Netlify's CDN responds to a request for a static asset, not whether your functions execute successfully. A function that errors, times out, or exhausts its memory is a runtime problem visible in your function logs, and it will not change the readings above.

Why does my custom domain fail while netlify.app still works?

Because the two take different paths to the same content. A custom domain depends on your DNS records pointing correctly and on a valid certificate having been issued for that hostname, and either can break independently of Netlify's delivery network. If the board above shows Netlify healthy and your netlify.app subdomain loads, the problem is almost certainly in DNS or certificate provisioning rather than in the platform.

How is this different from Netlify's own status page?

Their page reports what Netlify's engineers have confirmed from inside the platform and decided to publish. This page reports what our probes measured from outside it, on a fixed schedule, whether or not an update has been written yet. During a live incident the two are worth reading together.