Skip to main content
Cloudsmith logo

Is Cloudsmith Down?

No — Cloudsmith is up

Reachable from all 8 checked regions

Average response time: 153ms

Last checked · checks run every 6 hours

Official status page: https://status.cloudsmith.com

Cloudsmith uptime

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

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

30-day history

15-day clean streak
Sep 14: no data
Sep 15: no data
Sep 16: no data
Sep 17: no data
Sep 18: no data
Sep 19: no data
Sep 20: no data
Sep 21: no data
Sep 22: no data
Sep 23: no data
Sep 24: no data
Sep 25: no data
Sep 26: no data
Sep 27: no data
Sep 28: no data
Sep 29: 100.00% uptime, 16 checks
Sep 30: 100.00% uptime, 32 checks
Oct 1: 100.00% uptime, 30 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, 31 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.

ams
157ms
DNS 35ms TCP 8ms TLS 27ms TTFB 116ms
arn
98ms
DNS 47ms TCP 1ms TLS 11ms TTFB 86ms
nrt
178ms
DNS 142ms TCP 2ms TLS 10ms TTFB 171ms
ord
84ms
DNS 14ms TCP 1ms TLS 23ms TTFB 68ms
sin
182ms
DNS 142ms TCP 1ms TLS 8ms TTFB 175ms
sjc
79ms
DNS 38ms TCP 1ms TLS 8ms TTFB 71ms
syd
234ms
DNS 197ms TCP 1ms TLS 6ms TTFB 229ms
yyz
213ms
DNS 98ms TCP 11ms TLS 32ms TTFB 178ms

What Cloudsmith does

Cloudsmith is a hosted artifact management platform: private repositories for containers, packages and ML models in more than 30 formats, including Docker, npm, Python, Maven, Helm and Debian. CI pipelines push builds to it and servers and developer machines pull from it. Upstream proxying lets it fetch and cache packages from public registries, so it often sits between your builds and npm, PyPI or Docker Hub.

What an outage looks like

Builds fail or slow down while installing dependencies: docker pull errors, Docker or Helm OCI login failures, timeouts from api.cloudsmith.io, or slow Python package downloads. Uploads can succeed but sit awaiting synchronization, so a later job cannot find the version it just pushed. Past incidents also delayed policy evaluations, OSV vulnerability data and new upstream packages appearing in repositories, while downloads kept working.

What to do about it

Check status.cloudsmith.com, which splits Package Uploads, Package Sync, Package Downloads, the REST API, Upstreams and Security Scanning from the web apps and integrations. Uploads are processed asynchronously, usually within about a minute, so add a wait and retry to CI or upload with cloudsmith push, which waits for sync. If a package fails to sync, resync it rather than uploading again: Cloudsmith describes resync as a retry.

Is it down for everyone, or just you?

If this page says Cloudsmith 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

Docker Hub
Docker Hub
N
npm
P
PyPI
GitHub
GitHub

Cloudsmith outage FAQ

Is Cloudsmith down for everyone or just me?
Check status.cloudsmith.com, but read incidents for their region and format. Cloudsmith says its availability figures are aggregated across tiers, regions and package formats, and that each customer's experience varies. Incidents are often scoped, such as US East latency and timeouts between 19:16 and 20:11 UTC on August 31, 2026, or slow downloads for Python packages only.
Does an npm, PyPI or Docker Hub outage affect Cloudsmith?
Not for packages already cached. In Cache and Proxy mode Cloudsmith stores each package it fetches from an upstream in your repository, which its documentation says helps protect you from upstream outages. In Proxy Only mode requests go through to the upstream for anything not in your repository, so those packages depend on the public registry being up.
Why is my uploaded package not available yet?
Cloudsmith processes uploads asynchronously, so a new package waits for synchronization before it can be downloaded. That usually takes about a minute, longer under heavy load or many parallel uploads. Cloudsmith suggests a wait and retry in CI, a repository webhook that tells your build system when the package has synced, or cloudsmith push, which waits for sync. Package Sync has its own status row.
Are packages or webhooks lost during a Cloudsmith incident?
Usually not, but check the incident text. On August 21, 2026 new upstream packages were not cached between 17:00 and 18:45 UTC; pulls kept working and the missing packages were cached on later pulls. Webhooks for the Package Downloaded event were also affected in that window, and Cloudsmith said missed events would not be replayed.
Did the Cloudsmith status page move?
Yes. On May 1, 2025 Cloudsmith moved to a new incident management platform at status.cloudsmith.com, and the old status.cloudsmith.io address redirects there. Email subscriptions were migrated automatically. RSS readers need the new feed at status.cloudsmith.com/feed.rss, and Slack users re-subscribe with /feed subscribe followed by status.cloudsmith.com/slack.rss.

How we measure this

  • We request Cloudsmith'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 Cloudsmith 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 Cloudsmith 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