Intermittent 60s edge-to-origin stalls returning 503 — Fastly Burbank POP, SFO region

Anyone having this problem?
Region: SFO. Plan: Pro.
UPDATE: "Fastly's documentation notes that enabling origin shielding can resolve backend connection problems of this type. Has shielding been considered for the SFO origin?"
Requests to sfo.cloud.appwrite.io intermittently stall 30–60s and return a 503 from Varnish. The error page has no CORS headers, so browsers report it as a CORS failure — but it's an edge-to-origin read timeout.

The key measurement: Appwrite's own X-Debug-Speed shows the origin processing every request in 27–110ms. Across 40 requests, edge wait times were bimodal — 33 under 160ms, then 384ms, 5.6s, 27.6s, 35.0s, and 60,041ms, which returned the 503. The origin did 65ms of work while the edge waited a minute.
503 headers:
HTTP/1.1 503 backend read error
Server: Varnish
X-Served-By: cache-bur-kbur8200055-BUR
X-Cache: MISS
X-Timer: S1786668513.414699,VS0,VE60041
Content-Type: text/html
Ruled out:
Not query weight — affected collection has 12 docs, 19KB in 83ms normally. Stalls also hit /v1/health/version, which does no database work.
Not concurrency — a stall at 6 parallel requests while 12, 16, and 24 were clean. 40 serial requests also stalled 27.5s.
Not rate limiting — no x-ratelimit headers on any response.
Not my network — traceroute 7 hops, max 17ms, zero loss. 250 pings, 0% loss. TLS 33–45ms.
Not one bad node — stalls across six Burbank nodes (kbur8200035, 055, 067, 090, 096, 119).

Episodic — clean for stretches, then stalls cluster, then clean again. A VPN (different path) resolves it entirely, isolating it to the Burbank POP's route to origin.

Anyone else in Southern California seeing intermittent 503s on SFO?

Yeah, I can help with this. From the logs, it looks more like a Fastly edge-to-origin connection issue than an actual CORS problem. The origin is responding quickly, but the SFO/Burbank POP is sometimes taking up to 60s to get the response.
Have you tried enabling origin shielding for the SFO origin?

Thanks for taking a look — I really appreciate the quick response.

I don't think I'm able to enable shielding on my end. I'm on Appwrite Cloud, so the Fastly service in front of sfo.cloud.appwrite.io is yours rather than mine — per Fastly's docs, shielding is set as a property of the backend in the Fastly control panel, so it would need to be enabled on your side for the SFO origin.

One detail that might be relevant: Fastly recommends picking a shield POP that has a private network interconnect with the origin's cloud provider, so that hop uses the interconnect instead of the public internet. That's exactly where my measurements show the stalls happening — the origin responds in 65ms while the edge waits up to 60 seconds before timing out.

Happy to run any further diagnostics that would help. Thanks again for looking into it.

That makes sense, and your measurements actually point pretty strongly toward the Fastly-to-origin path.
I can take a closer look at the routing/POP behavior and help narrow down where the delay is coming from. I’ll DM you so we can go through the diagnostics privately and, if needed, I can help you work through a proper fix.

Thank you!