DigitalOcean latency check.
Round-trip latency from your browser to DigitalOcean regions. Hit in parallel, median ms reported. Click rerun for a fresh measurement.
DigitalOcean latency check — browser-measured RTT to DigitalOcean regions using Spaces (S3-compatible) regional endpoints.Measured live from your browser to 0 DigitalOcean region endpoints. Three samples per region in parallel, fetch(no-cors) + median ms reported, four-second timeout.
Digital Ocean · 0 regions
// endpoint used
<region>.digitaloceanspaces.com — Spaces is DigitalOcean's S3-compatible object store, with one hostname per region. Hit with fetch(no-cors).
// what it measures
Per datacenter, 4 samples in a row; the first is dropped as warm-up and the median of the other 3 is what you see. It reflects TCP + TLS + first-byte timing — a few ms over a bare ping, but consistent for comparing datacenters.
// what it doesn't
We keep nothing and send nothing anywhere — the only requests made are the probes themselves. Droplet-to-droplet latency between datacenters is a different question; measure that with mtr from inside DO.
// digitalocean latency faq
How does this DigitalOcean latency test work?
Each DigitalOcean region with Spaces — the platform's S3-compatible object store — exposes a hostname like nyc3.digitaloceanspaces.com. The test times fetch(no-cors) requests against those: four sequential samples per region, the first dropped as TLS warm-up, median of the rest reported. It all runs in your browser with no backend, so nothing about your run is collected. Expect values a few ms above an ICMP ping since a TLS handshake is included, with reliable region-to-region ordering.
Which datacenters does DigitalOcean run?
DigitalOcean's footprint is deliberately small: New York (NYC1-3), San Francisco (SFO2-3), Toronto (TOR1), Amsterdam (AMS3), Frankfurt (FRA1), London (LON1), Singapore (SGP1), Bangalore (BLR1), and Sydney (SYD1). The number is the facility's sequence within a metro — NYC1 and NYC3 are different buildings, not versions. This test covers the regions that expose Spaces endpoints. Notice the gaps: no South America, no Africa, no Middle East — if your users live there, budget for the long haul.
How should I pick a droplet region?
Closest region to your users wins, and with under a dozen metros the choice is usually obvious: BLR1 for India, SGP1 for Southeast Asia, SYD1 for Australia, FRA1 or AMS3 for continental Europe. Two DO-specific wrinkles: within a metro, prefer the newest facility (NYC3 over NYC1, SFO3 over SFO2), since older datacenters periodically stop accepting some new resources, and check the product availability matrix — Spaces and some managed offerings don't exist in every datacenter.
Is pricing the same in every DigitalOcean region?
Yes — and it's a genuine differentiator. A $6 droplet costs $6 in Bangalore, Sydney, or New York, and bandwidth pricing is uniform too. Compare that with AWS, Azure, and GCP, where the same instance can vary 20-50% by region and egress rates differ by geography. On DigitalOcean, latency, feature availability, and data residency are your only real selection criteria; you never have to trade milliseconds against your monthly bill the way hyperscaler region pickers force you to.
Does DigitalOcean have network tiers or a global CDN?
There's no tier knob — no Premium-versus-Standard choice like GCP's; every droplet gets the same network. Load balancers are regional, though DigitalOcean has since added a Global Load Balancer product for multi-region HTTP routing. Spaces buckets ship with a built-in CDN you can toggle on, which serves static assets from edge locations. For everything else, teams commonly put Cloudflare in front of their droplets — a well-trodden and well-supported pattern in the DO ecosystem.
How do VPC networks work across DO regions?
A DigitalOcean VPC is scoped to one datacenter: droplets in NYC3 and droplets in FRA1 cannot share a private network out of the box, and traffic between their public IPs crosses the open internet. DigitalOcean has introduced VPC peering to connect networks privately, but the model remains far more region-bound than GCP's global VPC. Practical advice: keep chatty services — app plus database — inside one region's VPC, and encrypt anything crossing regions; WireGuard and Tailscale are popular here.
Why doesn't DigitalOcean have availability zones?
There is no AZ abstraction — the datacenter is the unit. NYC1, NYC2, and NYC3 are separate facilities in the New York metro, but DigitalOcean makes no synchronized failure-domain promises between them the way AWS does for us-east-1a/b/c. High availability therefore means redundant droplets behind a regional load balancer and, for serious uptime targets, spanning two metros entirely — say NYC3 plus TOR1 — with your own replication strategy, since managed cross-region failover is largely on you.