Does AppDynamics Work in China? Data Residency, PIPL & Your APM Telemetry
AppDynamics operates no SaaS controller inside mainland China — its controllers sit in the Americas, EMEA and APAC (Oregon, São Paulo, Frankfurt, London, Mumbai, Singapore and Sydney) — so the traces, snapshots and error data its agents collect from Chinese users are stored on an offshore controller, a cross-border transfer of personal information under PIPL. A compliance-first look at the data-residency door and the lawful in-country path that keeps your APM where it already runs.
Does AppDynamics work in China?
Yes — AppDynamics loads and ingests from mainland China, but that is the easy half. AppDynamics operates no SaaS controller inside the mainland, so every trace, snapshot, metric and error payload your agents capture in China is shipped to and stored on an AppDynamics controller offshore — a cross-border transfer of personal information, not a speed problem.
AppDynamics's own "SaaS Domains and IP Ranges" page lists its SaaS controllers under Americas (Oregon, São Paulo), EMEA (Frankfurt, London) and APAC (Mumbai, Singapore, Sydney) — none in mainland China (its only China-linked entry, Hong Kong, is a synthetic-agent location, not a controller, and a separate jurisdiction). APM telemetry is not anonymous: snapshots and traces carry URLs, parameters, SQL and client IPs, and AppDynamics ships "Sensitive Data Collection and Security" controls precisely because captured data can expose sensitive information. Gathered from mainland users and sent to an offshore controller, that personal information is a cross-border transfer PIPL governs (notice, separate consent and a transfer mechanism, Articles 38–43), and for a CIIO or large-volume handler it must be stored in China (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). The table below is AppDynamics's own wording and the rule each line triggers.
Treat this as a risk map, not a verdict — what applies turns on how much of your telemetry is personal, your role as handler, and who your users are. Our China team can map your exposure with you →
What AppDynamics's own documentation says about China
| Fact | Primary source |
|---|---|
| AppDynamics runs no SaaS controller inside mainland China. Its own "SaaS Domains and IP Ranges" page states, "This page lists the current Splunk AppDynamics SaaS IP ranges and domains for each region," and groups those regions under Americas (Oregon, São Paulo), EMEA (Frankfurt, London) and APAC (Mumbai, Singapore, Sydney). There is no mainland-China controller to choose — the only China-linked entry, Hong Kong, is a synthetic-agent location, not a controller region — so the traces, snapshots, metrics and error data you capture in China are stored on a controller outside the mainland. | Splunk AppDynamics — SaaS Domains and IP Ranges (help.splunk.com), retrieved 2026-10-09 |
| The telemetry AppDynamics captures is personal information. APM snapshots and business-transaction traces follow a user's request and carry URLs, parameters, SQL and the context behind slow or errored calls, while browser and end-user monitoring tie activity to a session and a client IP. AppDynamics's "Sensitive Data Collection and Security" page says "This page describes how to prevent sensitive data collection in your application environment" and provides masking controls — a vendor acknowledgment that captured telemetry can expose sensitive data. Collected from mainland users and sent to an offshore controller, that is a cross-border transfer of personal information under PIPL — notice, separate consent and a transfer mechanism (Articles 38–43). | Splunk AppDynamics — Sensitive Data Collection and Security (help.splunk.com), retrieved 2026-10-09; PIPL Articles 38–43 |
| The SaaS tier offers no way to keep the data in the mainland. Every AppDynamics SaaS controller region is offshore; the only in-country option is a separate, self-managed on-premises Controller, whose "setup allows for local management of the Splunk AppDynamics Controller and its associated components" — with residency, security and operations then entirely the customer's. For a critical information infrastructure operator or a large-volume handler, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a residency duty the offshore SaaS controllers cannot satisfy. | Splunk AppDynamics — On-Premises Deployment (help.splunk.com), retrieved 2026-10-09; PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37) |
| Reachability is the easy half — AppDynamics is a backend, not a hosted site. The Controller UI and agent ingestion generally load from inside China, so the exposure is not whether AppDynamics connects but where the telemetry it collects is stored. The ICP filing question (State Council Order No. 292; MIIT Order No. 33) attaches to the public mainland website or app you operate, not to AppDynamics as a monitoring backend — while the PIPL cross-border and data-residency duties attach to the telemetry AppDynamics carries offshore. | Splunk AppDynamics documentation, retrieved 2026-10-09; State Council Order No. 292; MIIT Order No. 33 |
Sources verified by the 21YunBox compliance team on 2026-10-09.
For a mainland-China audience, the question about AppDynamics is seldom whether the Controller UI loads — it usually does. The question is where the telemetry it gathers is allowed to come to rest. AppDynamics answers that in its own documentation: it operates no SaaS controller inside mainland China. So the agents instrumented on your mainland servers, and the browser monitoring running in your mainland visitors’ sessions, capture business-transaction traces, snapshots, metrics and error data in China and send them to an AppDynamics controller in the Americas, EMEA or APAC. Because APM telemetry routinely carries personal information — client IP addresses, user IDs, the contents of requests — exporting it is a cross-border transfer China’s law governs. The dashboard being reachable is the delivery half; where the telemetry lands is the exposure.
AppDynamics in China at a glance
| What decides it | In AppDynamics's own terms |
|---|---|
| Where it runs | SaaS controllers in the Americas (Oregon, São Paulo), EMEA (Frankfurt, London) and APAC (Mumbai, Singapore, Sydney). None is in mainland China — the only China-linked entry, Hong Kong, is a synthetic-agent location, not a controller region, and a separate jurisdiction besides. |
| What the telemetry contains | Business-transaction traces, transaction snapshots, error payloads and browser-monitoring sessions carry user IDs, client IPs, URLs and request contents. AppDynamics ships “Sensitive Data Collection and Security” controls precisely because captured data can expose sensitive information. |
| Your China users' data | Captured in the mainland and sent to an offshore controller, it is a cross-border transfer PIPL governs; CIIOs and large-volume handlers owe an in-country storage duty an offshore controller cannot meet. |
| In-country storage option | The SaaS tier names no mainland region. A separate, self-managed on-premises Controller can run inside China — but then residency, security and operations become entirely yours to carry. |
| Is it reachable? | Generally yes — the Controller UI and agent ingestion load from inside China. The exposure is where the telemetry is stored, not whether it arrives. |
No mainland controller region, so your telemetry leaves the country
AppDynamics — a Cisco company, now presented in its documentation as Splunk AppDynamics — lists its SaaS controllers in its own “SaaS Domains and IP Ranges” page, which states plainly: “This page lists the current Splunk AppDynamics SaaS IP ranges and domains for each region.” Those regions are grouped under Americas (Oregon, São Paulo), EMEA (Frankfurt, London) and APAC (Mumbai, Singapore, Sydney). Not one of them is inside mainland China, and there is no mainland controller to select. So the agents on your mainland servers, and the browser monitoring in your mainland users’ sessions, gather their telemetry in China and ship it to whichever offshore controller your tenant is provisioned in. Connecting to AppDynamics was never the obstacle; keeping the data it collects inside the country is.
The telemetry AppDynamics captures is personal information
APM data is not anonymous by default. Traces follow a user’s request across your services; snapshots capture the detail of individual slow or errored transactions — the URLs, parameters, SQL and call context behind them; error payloads carry the message and stack of what failed; and browser and end-user monitoring tie activity to a session and a client IP. AppDynamics itself treats this as sensitive: its “Sensitive Data Collection and Security” documentation says “This page describes how to prevent sensitive data collection in your application environment,” and provides controls to hide query literals and mask values — tools you only need because the captured telemetry can carry personal and sensitive data in the first place. A single mainland user’s client IP is already personal information, and under China’s Personal Information Protection Law sending it to an offshore controller is a cross-border transfer — the handler (you, not AppDynamics) must give notice, obtain separate consent, and clear one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification (Articles 38–43).
Masking narrows what crosses — it does not close the border
AppDynamics gives you levers to reduce what leaves: you can mask sensitive values, hide query literals and filter what agents collect before it is sent. Those are worth configuring. But masking changes what crosses the border, not the fact that the telemetry crosses it, and it does nothing for the residency question. If you are a critical information infrastructure operator or a large-volume handler, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37) — the 2025 CSL amendment, in force 2026-01-01, renumbered the data-localization rule from Article 37 to Article 39) — and with every SaaS controller offshore, there is no in-country store on the SaaS tier to meet that duty. The ICP filing (State Council Order No. 292; MIIT Order No. 33) is a separate door that attaches to whatever public mainland site or app you operate, not to AppDynamics as a backend monitoring service.
Treat this as a risk map rather than a ruling: whether you owe a transfer mechanism, in-country storage, or both turns on how much of your telemetry is personal, your role as handler, and who your users are — worth settling with counsel before you wire anything up.
The lawful path — map, localize, deliver
You keep running AppDynamics. What a monitoring platform with no mainland controller cannot hand you is a lawful place inside China for the personal data its agents and browser SDK capture there — and that is the gap 21YunBox closes, across three legs:
- Map. Our China compliance team charts the lawful path for your setup — the PIPL cross-border obligations on your telemetry, the residency duty if you are a CIIO or large-volume handler, and the ICP footing your public mainland presence needs — against your entity, your data volumes and who your users are.
- Localize. Where telemetry cannot lawfully leave, we move it onto a China-legal footing — a self-managed on-premises Controller run inside the mainland, or a consented in-country processing-and-storage pattern — replacing only what cannot run compliantly on the offshore SaaS controller.
- Deliver. We stand up ICP-filed, in-country delivery with the 21YunBox Optimizer, set in front of the stack you already run — no rebuild, no second codebase, and no switch away from AppDynamics for the telemetry that can lawfully leave. 21YunBox never uses or suggests circumvention of any kind; the Optimizer is lawful, ICP-filed, in-country delivery.
Related reading:
- How to get an ICP filing for China
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- China’s data-export security assessment measures
