Google Cloud Storage suffered elevated latencies and error rates on upload and write operations for 5 hours 52 minutes on 8 October 2026. The fault sat on Google's side, affecting both the general storage service and the us-central1 region specifically.
Started
18:24 UTC
Duration
Lasted 5h 52m
Source
IsDown
Next time
Google Cloud is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Google Cloud Storage, Google Cloud Storage (us-central1)
What happened?
Google's status page logged a single incident starting at 18:24 UTC, describing elevated latencies and error rates for customers performing upload or write operations against Google Cloud Storage. Two components carried the flag: Google Cloud Storage overall, and the us-central1 region entry specifically. The incident ran for 5 hours 52 minutes before resolution. Google filed no updates against this incident, so there is no record of how the fault progressed, whether it was scoped further, or what fixed it. One filing is what you get, and it carries the weight of the whole account. No user reports were filed during the window, which is unsurprising given write-path latency issues often show up as slowness rather than hard failures that prompt someone to report. Over the past 90 days, Google Cloud has logged 5 incidents with a median duration of 5 hours 52 minutes, meaning this incident sat exactly at the median for recent recurrence. Across all time, Google Cloud has logged 960 incidents, averaging 13 per month. No post-mortem has been published, and Google's status page gives no cause for the latency and error rate increase. The affected operation, uploads and writes, is specific enough to suggest a backend or storage-layer issue rather than a network-wide problem, but nothing on record confirms that.
Learning
UptimeRobot's own probes against compute and storage components, run from both EU and NA regions every 60 seconds, showed 100% uptime across the 24 hour, 7 day and 30 day windows, and this incident was not registered against those probes. That is not a contradiction. External synthetic checks against Google Cloud Storage typically test that a basic operation completes, not that every upload or write runs at normal speed under load, so elevated latency and a higher error rate on a specific operation type can sit entirely inside Google's infrastructure without ever tripping a simple reachability check from outside. The failure shape here is a degraded write path, not a down service, and that is exactly the kind of fault that slips past black-box monitoring while still costing you real time if your product depends on fast uploads. If your own health checks looked fine during this window, that is expected, they were testing your half of the system, not Google's storage backend. Over 90 days this is the fifth such incident, each lasting close to 6 hours on median, so it is a recurring pattern rather than a one-off. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
