Supabase Storage Latency, June 2026: US-West-2 Storage Requests Slowed ~9 Hours

The shape: on June 12 2026, Supabase Storage requests in US-West-2 ran slow, not down, for about 8 hours 40 minutes, returning 200s the whole time. A check that asserts only a 200 status code stayed green through the entire window. The instrument that surfaces a regional 200-but-slow degradation is a response-time threshold on an HTTP monitor against a Storage-backed endpoint, set near your warm p95. Velprove ships response-time thresholds and 5 regions on every plan, so running the same probe from more than one region is what tells you the slowdown is the vendor's, not yours.

Here is the one load-bearing fact to hold onto. A plain HTTP monitor asserting only status_code = 200 on a Storage URL would have reported 100 percent uptime through the entire window, because Storage kept returning 200s. It was just slow.

What broke on June 12, 2026 (and what didn't)

What was affected was narrow. Supabase named one product, Storage, and one region, US-West-2, and nothing else. The shape was a slowdown, not a stoppage: requests kept returning 200s throughout the window, and Supabase classified the incident as minor with the Storage component in degraded performance rather than an outage state. Operations were described as returning to normal once mitigation took hold, with a job-queue backlog draining afterward.

What did not happen matters just as much. This was not a hard outage, and the vendor did not name any other Supabase product or any other region as affected. Supabase published no root cause; the only causal word in the record is "load," in the phrase "load mitigation strategies," and we quote that and stop. There is also a single source here, the Supabase status page, with no third-party corroboration, which is normal for a minor single-region blip and is stated so the post claims no more than the record supports.

The timeline (UTC, primary-source)

The timeline below is taken verbatim from the Supabase Status incident permalink. All times UTC. Source: Supabase Status incident zwmwcs0r4hll.

The published machine timestamps run from 2026-06-12T16:00:44Z to 2026-06-13T00:40:18Z, which works out to approximately 8 hours 40 minutes. That hours figure is our derivation from the two published timestamps, not a number Supabase stated, and the window crossed midnight into June 13 UTC. Note the asynchronous tail: the request path returned to normal around 20:26 UTC, but the incident did not resolve until 00:40 UTC, because a job-queue backlog still had to drain after the latency recovered. Recovery of the request path was not the end of the incident.

Supabase did not publish a root cause. The only causal hint is the vendor's own phrase "load mitigation strategies" in the 16:30 update. We quote that and stop. We do not extrapolate "load" into a traffic spike or a subsystem failure, and as of writing there is no postmortem at the incident URL; minor incidents typically do not get one. This is also a single source. We did not independently observe the latency, and there is no third-party corroboration, which is normal for a minor single-region blip and is stated here so the post claims no more confirmation than exists.

One disambiguation. This is not the February 12 2026 us-east-2 incident, which was a hard regional outage with its own signed postmortem and a much wider blast radius. Different incident, different region, different severity. That one is covered in the full Supabase monitoring guide; keep the two distinct.

Why a status-code check stayed green

The whole reason this incident is worth a teardown is the gap between what the status code said and what users felt. Storage endpoints returned success codes throughout. The degradation lived in response time, not in the status code. A monitor that only looks at the code on the front of the response saw a healthy 200 every single interval, while the actual user experience, a signed-URL fetch or a Storage REST read taking far longer than usual, was degraded the whole time.

This is a textbook member of the silent-outage family: green status, degraded reality. We have written up the broader catalog in the silent-outage taxonomy, green status and degraded reality. A 200-but-slow latency shift is the same family of problem as a 200-but-wrong-body or a 200-but-empty response: the status code is true and useless at the same time.

The only external instrument that turns this from invisible into a red alert is a response-time threshold, set near your real warm p95. That is the bridge to the rest of this post: what to assert on, how to calibrate it, and how to use more than one region to tell a vendor slowdown apart from your own.

How to monitor Supabase Storage for latency

The primitive is a Velprove HTTP monitor pointed at a Storage-backed endpoint that exercises your real Storage path: a public object URL, a signed-URL fetch, or a Storage REST read. You are not probing some synthetic health route. You are hitting the same Storage surface your users hit, so the monitor feels the same latency they would.

The load-bearing detail is the Success Conditions you set. Three work together here, and the order of importance is deliberate:

1. Response time under a threshold. This is the assertion that catches a 200-but-slow regional degradation. Set the threshold at roughly 1.5x to 2x your warm p95, measured over a real traffic window. This is the same calibration discipline the Supabase monitoring guide uses for the Edge Function response-time tail. A threshold set too loose rides straight through a slow-but-under-threshold degradation; set too tight, it false-pages on normal variance. A default uptime check does not catch latency for free; the threshold is the catch.
2. Status code equals 200. This catches the rarer case where Storage fails hard rather than just slows down. It is the assertion most people start and stop with, and on its own it is exactly what stayed green through this incident.
3. Body contains a known string. Assert on a string the object or endpoint always returns, and the probe becomes a content-correctness check too, not just a timing and status check. Optional, but recommended, and the same pattern the guide uses for its Edge Function body_contains assertion.

Calibrating the response-time threshold to warm p95

The threshold is the whole monitor, so do not pull a round number from a docs page. Measure your warm p95 over a representative traffic window, the response time at the 95th percentile once caches are warm, then set the alert at about 1.5x to 2x that. The multiplier leaves room for normal variance while still tripping on a sustained shift like this one. If your warm p95 on a signed-URL fetch is 180ms, a threshold around 300ms to 360ms flags a real degradation without paging on jitter. The same discipline is laid out for Edge Functions in the full Supabase monitoring guide, so the cluster reads consistently.

One trap to avoid: do not put a Storage write or mutation on the monitor path. Point the probe at a read-only object or path, so a year of probes every few minutes does not quietly accumulate state in your bucket. A public object URL or a read-only signed-URL fetch is the right target.

Using multiple regions to localize a regional slowdown

Velprove offers 5 regions on every plan, but be precise about what that buys you: each check runs from one region you pick. A single monitor does not magically watch all five at once. So for a single-region incident like this one, the value of multiple regions is not coverage, it is differential diagnosis.

Configure the same Storage probe from more than one region, which means more than one monitor. When the response time on the probe pathing toward US-West-2 climbs while probes from other vantages stay flat, you have localized the slowdown to the vendor's region rather than to your own app or network. That is a different and more useful signal than a single red monitor: it tells you where the problem is, not just that there is one. The mechanism requires more than one monitor, on a plan that allows it.

This fits inside the free tier without a paid plan: 5 regions on every plan including Free, 10 monitors on Free, so a two- or three-vantage differential setup is well within reach. If your Storage read needs an auth step before the object fetch, multi-step API monitors are free up to 3 steps.

The honesty boundary

The strongest version of this post is the version that names what it does not claim.

First, and most important: Velprove did not detect this incident. We did not monitor Supabase Storage in US-West-2, and we are not claiming we caught it or would have caught it as a matter of fact. Everything above is the failure shape that response-time monitoring is built to surface, presented as a worked example. If you read a detection into this post, that is more than the facts support.

Second, there is no detection-time lead to claim here. Supabase opened this incident already in identified status at 16:00 UTC, the same minute the incident's own start timestamp records, so there is no published gap between impact start and acknowledgment to measure a lead against. We do not invent one.

Third, detection is not prevention. A response-time monitor surfaces a slowdown faster and tells you it is upstream. It does not stop the slowdown.

Fourth, the monitor catches this only if the response-time threshold is calibrated near real warm p95. A loose threshold rides through a slow-but-under-threshold degradation; a default check with no response-time assertion catches nothing here at all.

Fifth, one region per check. The differential-diagnosis value above requires configuring the same probe from more than one region; a single monitor watches a single vantage.

Sixth, we do not know what broke inside Supabase. The only word the vendor published is "load," in the phrase "load mitigation strategies." We quote it and stop, with no speculation about cause, no quantitative latency figures, and no affected-customer counts, because none were published.

This pattern, not just this incident

A regional 200-but-slow latency shift on a managed surface, Storage here, is a recurring shape, not a one-off. The instrument outlives this particular blip: a response-time threshold calibrated to warm p95, plus a multi-region differential to localize it. Build that once and it is ready the next time a managed dependency slows in one region while its status code keeps saying 200.

It reads as a pair with a teardown we published recently. In the GitHub Actions May 2026 detection teardown, the same underlying lesson shows up on a different surface and a different failure shape: there the endpoint returned 200 with a body that told the truth the status code hid, so the catching primitive was a body assertion. Here the body is fine and the truth is in the timing, so the catching primitive is a response-time threshold. Same family in the silent-outage catalog, green status and degraded reality, different assertion to catch it.

Monitor your Supabase Storage

A 200-but-slow regional degradation like this June 12 incident is invisible to a status-code-only check and visible to a response-time threshold set near your warm p95. Velprove's free plan covers the setup: 10 monitors, 5 regions on every plan, response-time thresholds on every plan, and no credit card; if your Storage read needs an auth step first, multi-step API monitors are free up to 3 steps. Point an HTTP monitor at a read-only Storage object, add the response-time threshold, and the next regional slowdown surfaces on a monitor instead of in a support ticket.

This post owns the Storage angle. For the full Supabase monitoring set, Auth, RLS, Edge Functions, and Realtime, see the complete Supabase monitoring guide. Start free and point a response-time monitor at your own Storage surface.

Frequently Asked Questions

What happened during the Supabase Storage latency incident in June 2026?

Storage requests in US-West-2 ran slowly between 2026-06-12 16:00 UTC and 2026-06-13 00:40 UTC, approximately 8 hours 40 minutes, with the window crossing midnight UTC. Supabase classified it minor and the Storage component sat in degraded performance, not outage. Requests were served, just slowly, and a job-queue backlog drained after the request path recovered. Only the Storage surface and only the US-West-2 region were named. Supabase did not publish a root cause; the only stated mitigation was load mitigation strategies.

Was Supabase down during the June 2026 Storage incident?

No. This was a latency degradation, not an outage. Storage requests continued to return successfully throughout; they were slower than normal in US-West-2. Other Supabase products and other regions were not named as affected. Do not conflate it with the separate February 12 2026 us-east-2 incident, which was a hard regional outage with its own postmortem.

Can an uptime monitor catch a Supabase Storage latency degradation?

Only if it asserts on response time, not just the status code. A check that asserts status_code = 200 alone stays green through a 200-but-slow degradation. Add a response_time_ms assertion set at roughly 1.5x to 2x your warm p95 on an HTTP monitor against a Storage-backed endpoint, and a sustained shift above that threshold trips an alert. Calibration is the catch: too loose and it rides through, too tight and it false-pages.

Did Velprove detect the June 2026 Supabase Storage slowdown?

No, and this post makes no such claim. Velprove did not observe this incident, and there is no detection-time-lead figure to quote, because Supabase opened the incident already identified, at the same minute it began, so there is no published impact-versus-acknowledgment gap. What we can say is the failure shape, a regional 200-but-slow latency degradation, is exactly what a response-time-threshold monitor is built to surface, and what a status-code-only check is not.

How do I localize a Storage slowdown to Supabase's region instead of my own app?

Run the same Storage probe from more than one Velprove region. Each Velprove check runs from one region you pick out of five, so a single monitor cannot watch all five at once, but configuring the same Storage HTTP monitor from two or three vantages turns it into a differential test. When the response time climbs on the probe pathing through the affected region while the others stay flat, the slowdown is localized to the vendor's region, not to your network or app.