Live

OSV vulnerability data delays.

OSV advisory backlog processing has completed, and returned to normal processing at 07:00 PM UTC. All systems are now operating normally.

The latest update from Cloudsmith.

State

Resolved

Started

54 d ago

2026-09-08 14:14 UTC

Lasted

4 h 50 min

until 2026-09-08 19:03 UTC

Worst impact

Degraded

Timeline

6 updates
14:1415:2616:3817:5119:03
DegradedUpdate postedTimes in UTC

Investigating

1 h 45 min 36%

Monitoring

3 h 5 min 64%

Updates

Times in UTC

As posted by Cloudsmith

Resolved2026-09-08 19:03 UTC

OSV advisory backlog processing has completed, and returned to normal processing at 07:00 PM UTC. All systems are now operating normally.

Monitoring2026-09-08 18:01 UTC

We're seeing improvement in processing the backlog of OSV vulnerability data. Please note that the new advisories may still take longer than usual to appear against affected packages and trigger policy evaluation while the backlog clears. Our engineers are continuing to monitor progress. Next update at 07:00 PM UTC.

Monitoring2026-09-08 17:03 UTC

Following the configuration changes, we're seeing improvement in processing the backlog of OSV vulnerability data. New advisories may still take longer than usual to appear against affected packages and trigger policy evaluation while the backlog clears. Our engineers are continuing to monitor progress.

Monitoring2026-09-08 15:58 UTC

We've made some configuration changes to help process the backlog of OSV vulnerability data. New advisories may take longer to appear against affected packages and trigger policy evaluation. Our engineers are currently monitoring the backlog.

Investigating2026-09-08 14:53 UTC

We continue to experience delays in OSV vulnerability data. New advisories may take longer to appear against affected packages and trigger policy evaluation. Our engineers are investigating

Investigating2026-09-08 14:14 UTC

We are experiencing delays in OSV vulnerability data. New advisories may take longer to appear against affected packages and trigger policy evaluation. Our engineers are investigating.

Cloudsmith in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

18

Days with an incident

18

Median duration

1 h 28 min

This incident

3.3× the median

How long each incident lasted, on the day it started. The outlined bar is this incident.

17 h 31 min
median 1 h 28 min
90 days agoToday

Other Cloudsmith incidents

All incidents

Follow Cloudsmith

Your coding agent knows when Cloudsmith is down, and tells you when a failure is theirs, not yours. You can also get Cloudsmith incidents in a feed reader or in Slack.

Prompt
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.

Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.

Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "cloudsmith" and tell me if Cloudsmith has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.

Paste this into any coding agent. It adds the server with its own MCP setup.

RSS
https://outages.cc/feed.xml?providers=cloudsmith
Slack
/feed subscribe https://outages.cc/feed.xml?providers=cloudsmith

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane