Status

Updated every 60 s from the nodes themselves, not from a third-party prober. Times are UTC.

Nodes

NodeLocationState30d uptimep50 / p95 RTTCache hit
uk1Londonoperational99.98%12 / 34 ms94.1%
nl1Amsterdamoperational99.99%9 / 27 ms96.3%
nl2Amsterdamoperational99.97%9 / 29 ms95.8%
nl3Amsterdamoperational99.99%10 / 26 ms95.1%
nl4Amsterdamoperational99.94%10 / 31 ms93.7%
nl5Amsterdamoperational99.98%9 / 28 ms95.4%
de1Frankfurtoperational99.99%8 / 22 ms96.9%
ch1Zurichoperational99.91%11 / 30 ms89.2%
bg1Sofiaoperational99.88%14 / 41 ms87.6%
pl1Warsawoperational99.96%11 / 29 ms94.8%
ru1Moscowdegraded97.20%18 / 260 ms91.4%

ch1 and bg1 joined on 2026-08-04, so their hit ratio is still filling up. A cold node looks worse than it is for roughly two weeks.

Incident history

ru1 transit instability2026-08-06 09:40 → ongoing

Two of three upstreams started dropping inbound sessions. Node kept serving from cache. We are not moving it out of the pool because cache hits are unaffected and it is the only node with usable latency inside RU.

uk1 address migration2026-07-19 02:10 → 02:55

Planned. The node moved to a new address. Sessions established on the old IP were drained rather than cut, so the window looked longer than the actual switch. Old address stays reachable until 2026-09-01.

nl2 / nl3 CPU saturation2026-04-11 14:20 → 16:05

Brotli level 11 on large objects pinned both nodes at 100% during a customer's release. Lowered to 6 for objects over 1 MB. This is why that default exists.

Purge API v0 removal2026-02-27

Announced in December, removed on schedule. Four accounts were still calling v0 and got 410 for a day before we reached them. Our fault for not paging harder.