Most “does X work in China” claims on the internet are folklore: a single anecdote, no date, no vantage point. The China Network Reachability Benchmark replaces that with a fixed panel, a documented probe method, and dated, repeatable runs.
This page is the methodology — the contract for every data release that follows. The first full-panel report ships the week of October 26, 2026.
What we probe
The panel holds 35 endpoints across 11 categories of the global SaaS stack. These are not hypothetical examples — they are the dependencies that appear again and again in real client assessments:
| Category group | Endpoints in the panel |
|---|---|
| Frontend delivery | Google Fonts API and static, jsDelivr, cdnjs, unpkg |
| Analytics & tag management | Google Analytics, Google Tag Manager, Segment, Amplitude, Mixpanel |
| Maps, payments, identity | Google Maps JS API, Stripe API and Stripe.js, PayPal API, Auth0 |
| Push, SMS & email | Twilio API, Firebase Cloud Messaging, OneSignal, Resend |
| Video & social embeds | YouTube thumbnail CDN, X/Twitter embed platform |
| AI APIs | OpenAI, Anthropic, Gemini |
| Developer infrastructure | GitHub, npm registry, PyPI, Docker Hub registry, Hugging Face |
| Cloud & productivity APIs | Google Cloud Storage, AWS S3, Slack, Notion, Microsoft Graph, Zoom |
Selection rule. A dependency enters the panel when it recurs across real client stacks; API hosts are probed at a representative public path, never behind authentication. The full machine-readable list ships with the data release.
From where, and how
- Probe platform. A commercial Mainland China probe network dispatches one-shot HTTP detections from carrier-grade nodes — the same probe engine Chinaready runs in production for client diagnostics, so there is no benchmark-specific code path.
- Node locations. Probe points sit inside Mainland China across the three carriers (China Telecom, China Unicom, China Mobile), concentrated in provincial capitals. Runs rotate through six regional node groups — North, East-core, East-south, Central & Southwest, South, Northwest — so after a full cycle of runs, the pooled series covers every probe city in the network.
- Probe semantics. One HTTP GET per endpoint per node; the result is an HTTP status with timing, or a failure classification (DNS failure, timeout, connection reset).
What the numbers mean
Each endpoint gets a per-node result, and classification happens at the endpoint level:
| Classification | Rule |
|---|---|
available | ≥90% of probe nodes received an HTTP response — any status code |
limited | Responses from some nodes only, or degraded timing versus the endpoint’s global baseline |
unavailable | No meaningful response from any node |
Two rules keep the numbers honest. First, reachability is not correctness: for API hosts, a 404 or 405 counts as reached — the cross-border path delivered, which is the decision-relevant fact. Second, timing is a distribution: response times are reported as median and p90 across nodes, never as a single headline number.
What this method cannot see
The limits, stated up front:
- No JavaScript execution. A page that loads but renders blank is “reachable” here. This benchmark isolates network-level dependency failure — the layer that decides architecture — not rendering behavior.
- Snapshots, not laws. Cross-border behavior varies by region, carrier, and time. Every release runs twice (initial plus a confirmation re-run within seven days) before publishing, and every number carries its run date.
- Probe-panel routing. Commercial probe nodes may differ from consumer last-mile routing in edge cases; carrier coverage is represented, individual cities are not a guarantee.
Reuse
Extend the panel
This benchmark is not a fixed monument — the panel grows. If a service you depend on is missing, tell us and it joins the next weekly run: send the endpoint you want probed through the Contact Us form, and reference “benchmark panel” in your message. Community-submitted endpoints are credited in the run changelog unless you ask otherwise.
The endpoint panel and this methodology are published, and every run’s endpoint-level results ship as dated CSV/JSON downloads. If you want the same read on your own dependency list, a China Readiness Assessment applies this exact machinery to your stack, with engineers reading the results.
