Skip to main content

Is NuGet Down?

No — NuGet is up

Reachable from all 8 checked regions

Average response time: 911ms

Last checked · checks run every 6 hours

Official status page: https://status.nuget.org

NuGet uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
789ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 70 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

70-day clean streak
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 32 checks
Sep 16: 100.00% uptime, 32 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 32 checks
Sep 21: 100.00% uptime, 32 checks
Sep 22: 100.00% uptime, 54 checks
Sep 23: 100.00% uptime, 32 checks
Sep 24: 100.00% uptime, 32 checks
Sep 25: 100.00% uptime, 32 checks
Sep 26: 100.00% uptime, 32 checks
Sep 27: 100.00% uptime, 32 checks
Sep 28: 100.00% uptime, 32 checks
Sep 29: 100.00% uptime, 32 checks
Sep 30: 100.00% uptime, 32 checks
Oct 1: 100.00% uptime, 31 checks
Oct 2: 100.00% uptime, 32 checks
Oct 3: 100.00% uptime, 32 checks
Oct 4: 100.00% uptime, 32 checks
Oct 5: 100.00% uptime, 32 checks
Oct 6: 100.00% uptime, 32 checks
Oct 7: 100.00% uptime, 32 checks
Oct 8: 100.00% uptime, 32 checks
Oct 9: 100.00% uptime, 32 checks
Oct 10: 100.00% uptime, 32 checks
Oct 11: 100.00% uptime, 32 checks
Oct 12: 100.00% uptime, 32 checks
Oct 13: 100.00% uptime, 32 checks
Sep 14 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

iad
184ms
DNS 73ms TCP 19ms TLS 45ms TTFB 164ms
jnb
2789ms
DNS 317ms TCP 241ms TLS 490ms TTFB 2548ms
lax
427ms
DNS 134ms TCP 40ms TLS 84ms TTFB 344ms
lhr
504ms
DNS 19ms TCP 94ms TLS 193ms TTFB 409ms
nrt
962ms
DNS 89ms TCP 172ms TLS 349ms TTFB 790ms
ord
303ms
DNS 175ms TCP 22ms TLS 51ms TTFB 280ms
sin
1468ms
DNS 55ms TCP 234ms TLS 474ms TTFB 1233ms
sjc
654ms
DNS 361ms TCP 48ms TLS 101ms TTFB 607ms

What NuGet does

NuGet.org is the package registry the .NET ecosystem restores from. Practically every .NET build that is not fully vendored or mirrored pulls dependencies through it, which makes it a build-time dependency for a very large number of organisations that never think about it until a restore fails. Its status page separates browsing, restore, search and package publishing.

What an outage looks like

Builds fail at restore with errors such as unable to load the service index for source https://api.nuget.org/v3/index.json, or a timeout against that host. CI pipelines break while local builds using a warm package cache keep succeeding, which is the clearest signal that the registry rather than your code is the problem. Search returns nothing in Visual Studio, and pushing a new package version fails or hangs.

What to do about it

Check status.nuget.org, which reports NuGet.org browsing, Restore, Search and Package Publishing as four separate services, so a publishing failure and a restore failure are distinguishable. During a restore incident, builds with a populated local package cache generally still work, so avoid clearing the cache. Do not repeatedly retry a publish that appeared to fail, since a version can land server-side without returning success and the number cannot be reused.

Is it down for everyone, or just you?

If this page says NuGet is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 17 cities across three regions to find out where it breaks.

Test it yourself

Related services

GitHub
GitHub
GitLab
GitLab
Docker Hub
Docker Hub
Bitbucket
Bitbucket

NuGet outage FAQ

Why does my build fail on CI but work on my machine?
Because your machine has a populated package cache and the CI runner usually does not. A clean runner restores every dependency from NuGet.org on each build, so it feels the outage immediately, while a local build resolves from the global packages folder and never reaches the network. This asymmetry is the fastest confirmation that the registry rather than a code change is the cause.
Can I keep building while NuGet.org is down?
Often yes. Restores that hit an existing local cache succeed without touching the network, so builds whose dependencies are unchanged carry on. What breaks is adding a new package, upgrading a version, or building on a clean machine. Teams that keep a private mirror or an artifact feed with upstream caching ride out registry incidents almost entirely, which is the real argument for running one.
Should I clear my NuGet cache to fix a restore error?
Not during an outage, and this is the one action most likely to make things worse. Clearing the cache removes the packages that are currently letting your builds succeed, and repopulating them requires the registry that is unavailable. If restores were working an hour ago and now fail, treat the cache as an asset to protect until the status page is green again.
Is my package still published if the push failed?
Possibly, and it is worth checking before retrying. A push can be accepted server-side while the response fails to return, which leaves a version that exists but appeared to fail. NuGet.org does not allow re-using a version number, so a blind retry produces a confusing conflict. After recovery, look up the package listing first and only push again if the version genuinely is not there.
Does a NuGet outage affect Visual Studio itself?
Visual Studio keeps working; the parts of it that talk to the registry do not. Package Manager search returns no results, the browse tab fails to populate, and adding a dependency errors. Editing, compiling against already-restored packages, debugging and everything local continue normally. Search is a separate component from Restore, so search can be broken while restores still succeed.

How we measure this

  • We request NuGet's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where NuGet publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when NuGet goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required