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?
