Under attack? Emergency onboarding in under 30 minutes. Open a mitigation line →
All regions nominal · Network status
Infrastructure

Where the traffic goes, and what happens when part of it fails.

A network diagram is easy to draw and hard to keep honest. This page describes the footprint we route across, the architecture behind it, and the failure modes we have designed for rather than the ones we hope you never hit.

320+
Edge locations
Own and partner PoPs in routing scope
42
Countries
With at least one serving location
18 Tbps
Absorption capacity
Aggregate mitigation headroom
6+
Delivery networks
Under active scheduling

Footprint figures reflect the current draft build plan. Replace with verified capacity and PoP counts before this page is published.

Coverage

Regional depth, not just a pin map

Coverage is only useful where your users are. These are the regions we hold serving capacity, peering and operational depth in.

Twenty-two serving locations, three operating regions

Drag the globe to rotate it. Larger markers are regional hubs holding mitigation capacity and an operations shift; the arcs are the inter-hub paths that carry failover traffic when a region degrades.

Regional hub Serving location
  • Hover a marker for its current median latency
  • Hubs carry absorption capacity, not just cache
  • Every region can serve every other region's traffic

Latency values shown are illustrative targets pending live measurement.

REGION 01Primary

Asia-Pacific

Our deepest region, and where the operations team sits. Dense metro coverage, direct peering with the major regional carriers, and mitigation capacity sized for the traffic patterns this part of the world actually produces.

SingaporeHong KongTokyoSeoulJakartaManilaSydneyMumbai
REGION 02Full service

Europe, Middle East & Africa

Coverage shaped by residency requirements as much as by latency. EU traffic can be pinned to EU serving locations and EU-resident logging without a bespoke contract.

FrankfurtAmsterdamLondonParisMadridDubaiJohannesburg
REGION 03Full service

Americas

North and South American coverage with attention to the routes that are usually an afterthought: intra-LATAM paths, and the long haul between Brazilian users and North American origins.

AshburnDallasLos AngelesTorontoSão PauloSantiagoBogotá
Architecture

Four layers, each able to fail without the others

The design goal is not that nothing breaks. It is that when something breaks, the blast radius is one layer and the recovery is automatic.

LAYER 01LAYER 02LAYER 03LAYER 04 Resolution Anycast authoritative DNSGeo & latency steeringHealth-checked recordsSub-second propagation FAILS TO: last-known-good answer Ingress Anycast prefix announcementL3/L4 volumetric filteringConnection & TLS terminationPer-PoP capacity shedding FAILS TO: adjacent PoP withdrawal Decision WAF & bot scoringCache lookup & policyRoute selection per requestEdge compute execution FAILS TO: last valid policy set Origin Shielded origin poolsHealth-based failoverMulti-cloud & private DCStale-while-revalidate FAILS TO: cached response Operations layer Telemetry, detection, change control and incident response across all four layers, with every operator action signed and retained.
Resilience

The failure modes we plan for

Every one of these has happened to somebody. The question is only whether the design assumed it.

Route weights shift away from the affected provider in that region on measured error rate and latency, not on a status page. The rest of your traffic is untouched.

The prefix is withdrawn from that location and anycast delivers users to the next nearest ingress. Sessions re-establish; the failure shows up as a latency bump rather than an outage.

Edge nodes keep serving with the last valid policy set. You lose the ability to make changes, not the ability to serve traffic. This is a deliberate trade and it is the right way round.

Origin shielding collapses the request fan-in, stale-while-revalidate keeps cached content flowing, and a queue holds the uncacheable paths rather than letting them take the origin down entirely.

Renewal and deployment are automated across every network in the path, and the expiry window is monitored independently of the automation that manages it. Two failures, not one, are required for an outage.

Rules deploy in stages with automatic halt conditions on error rate and block rate. Rollback is a single action and every change is attributed to a named operator.

Compliance posture

What we can evidence

Controls are built to map cleanly onto the frameworks our customers are assessed against, and the evidence is assembled from the same audit trail the operations team works from rather than reconstructed for the auditor.

  • Signed, immutable record of every operator action and rule change
  • Configurable log residency and retention up to seven years
  • Role-based access with least-privilege defaults and periodic review
  • Documented incident classification and customer notification timelines
  • Subprocessor register maintained and available on request

Name only the certifications actually held, with their audit dates and scope, before this section is published. Claimed but unheld certifications are the fastest way to fail a procurement review.

Status

Current network state

Asia-Pacific deliveryOperational
EMEA deliveryOperational
Americas deliveryOperational
DNS resolutionOperational
Control plane & APIOperational
Sentinel operationsOperational

Static placeholder. Replace this panel with a live feed from your status provider, or link out to it, before launch. A hard-coded "all green" is worse than no status page at all.

Ask us the awkward architecture questions.

Bring your network lead. We would rather spend an hour on failure modes now than explain them to you during an incident.