Skip to main content

Is NuGet Down?

No — NuGet is up

Reachable from all 8 checked regions

Average response time: 725ms

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
694ms
Avg response, 30 days

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

30-day history

13-day clean streak
Jul 19: no data
Jul 20: no data
Jul 21: no data
Jul 22: no data
Jul 23: no data
Jul 24: no data
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: no data
Aug 1: no data
Aug 2: no data
Aug 3: no data
Aug 4: no data
Aug 5: 100.00% uptime, 16 checks
Aug 6: 100.00% uptime, 32 checks
Aug 7: 100.00% uptime, 31 checks
Aug 8: 100.00% uptime, 32 checks
Aug 9: 100.00% uptime, 32 checks
Aug 10: 100.00% uptime, 40 checks
Aug 11: 100.00% uptime, 32 checks
Aug 12: 100.00% uptime, 32 checks
Aug 13: 100.00% uptime, 31 checks
Aug 14: 100.00% uptime, 32 checks
Aug 15: 100.00% uptime, 31 checks
Aug 16: 100.00% uptime, 32 checks
Aug 17: 100.00% uptime, 24 checks
Jul 19 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.

ams
570ms
DNS 42ms TCP 103ms TLS 211ms TTFB 467ms
arn
1036ms
DNS 410ms TCP 122ms TLS 251ms TTFB 914ms
lhr
534ms
DNS 26ms TCP 99ms TLS 202ms TTFB 435ms
nrt
854ms
DNS 91ms TCP 141ms TLS 286ms TTFB 711ms
ord
475ms
DNS 352ms TCP 81ms TLS 9ms TTFB 455ms
sin
1218ms
DNS 14ms TCP 237ms TLS 480ms TTFB 981ms
sjc
314ms
DNS 38ms TCP 55ms TLS 90ms TTFB 269ms
syd
1182ms
DNS 154ms TCP 192ms TLS 390ms TTFB 988ms
yyz
155ms
DNS 42ms TCP 14ms TLS 34ms TTFB 141ms

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 all 18 regions to find out where it breaks.

Test it yourself

Related services

GitHub
GitHub
GitLab
GitLab
Docker Hub
Docker Hub
B
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 — 8 of them answered the most recent check.
  • 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 the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required