Skip to main content

Is NuGet Down?

No — NuGet is up

Reachable from all 8 checked regions

Average response time: 576ms

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

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

30-day history

19-day clean streak
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, 32 checks
Aug 18: 100.00% uptime, 32 checks
Aug 19: 100.00% uptime, 32 checks
Aug 20: 100.00% uptime, 32 checks
Aug 21: 100.00% uptime, 32 checks
Aug 22: 100.00% uptime, 32 checks
Aug 23: 100.00% uptime, 39 checks
Jul 25 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
552ms
DNS 23ms TCP 103ms TLS 211ms TTFB 447ms
arn
727ms
DNS 103ms TCP 122ms TLS 250ms TTFB 605ms
bom
1174ms
DNS 180ms TCP 196ms TLS 396ms TTFB 978ms
cdg
707ms
DNS 199ms TCP 97ms TLS 200ms TTFB 610ms
dfw
203ms
DNS 76ms TCP 23ms TLS 50ms TTFB 181ms
ewr
273ms
DNS 69ms TCP 37ms TLS 78ms TTFB 236ms
fra
590ms
DNS 43ms TCP 106ms TLS 220ms TTFB 484ms
gru
762ms
DNS 26ms TCP 136ms TLS 280ms TTFB 624ms
iad
175ms
DNS 71ms TCP 17ms TLS 46ms TTFB 159ms

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