Does Honeycomb Work in China? Telemetry Data Residency, PIPL & Distributed Traces
Honeycomb runs no region inside mainland China — it stores telemetry in AWS us-east-1 (US) or eu-west-1 (EU) — so the high-cardinality events and distributed traces it ingests from Chinese users are shipped offshore, a cross-border transfer of personal information under PIPL. A compliance-first look at the data-residency door, and the ICP-filed, in-country path that keeps your stack exactly where it already runs.
Does Honeycomb work in China?
Yes — Honeycomb loads and ingests from mainland China, but that is the easy half. Honeycomb runs only two data locations, one in the US and one in the EU, and none inside the mainland, so every event and distributed trace you collect in China is stored on a Honeycomb backend offshore — a cross-border transfer of personal information, not a speed problem.
Honeycomb's own support article states that "Honeycomb has US-based and EU-based data residency," and that "Customer data can be stored and processed in AWS us-east-1 (US East - USA) or AWS eu-west-1 (Europe - Ireland)." Neither region is in mainland China, and there is no mainland location to pick. High-cardinality telemetry is personal by design: your spans and events carry user IDs, client IPs and whatever request fields your instrumentation attaches, and Honeycomb notes it "only has access to the telemetry data that customers send" — so the contents, and the duty for them, are yours. Gathered from mainland users and shipped to a US or EU backend, that personal information is a cross-border transfer PIPL governs (notice, a separate consent and a transfer mechanism, Articles 38–40), 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 on the page is Honeycomb's own wording and the China rule each line triggers.
This is a risk map, not a verdict — what applies turns on what your spans carry, how much of it is personal, and who your users are. Our China team can map your exposure with you →
What Honeycomb's own documentation says about China
| Fact | Primary source |
|---|---|
| Honeycomb runs no region inside mainland China. Honeycomb's own support article "Where is Honeycomb's data stored?" states that "Honeycomb has US-based and EU-based data residency," and that "Customer data can be stored and processed in AWS us-east-1 (US East - USA) or AWS eu-west-1 (Europe - Ireland)." You choose one location at sign-up; there is no mainland-China option, so the events and traces you collect in China are stored on a Honeycomb backend outside the mainland. | Honeycomb Support — Where is Honeycomb's data stored? (support.honeycomb.io), retrieved 2026-10-09 |
| The events and traces Honeycomb ingests are personal information. High cardinality is the product's purpose: each event and span carries the attributes your instrumentation attaches — user IDs, client IPs, request fields and more. Honeycomb's data-privacy documentation notes that "Unlike some other vendors, Honeycomb only has access to the telemetry data that customers send" — so the contents, and the responsibility for them, are the customer's. Collected from mainland users and shipped to a US or EU backend, that is a cross-border transfer of personal information under PIPL — notice, a separate consent and a transfer mechanism (Articles 38–40); unscrubbed attributes can also carry Article 28 sensitive personal information. | Honeycomb Docs — Compliance & Data Privacy (docs.honeycomb.io), retrieved 2026-10-09; PIPL Articles 28, 38–40 |
| Honeycomb offers no way to keep the data in the mainland. Honeycomb's subprocessor page, titled "Subprocessors for US and EU Honeycomb product," lists Amazon Web Services with locations "US, EU" and notes that the "Customer may designate data residency upon signup" — the only choices are the United States and the European Union, both outside the mainland. 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 data-residency duty Honeycomb's US and EU regions cannot satisfy. | Honeycomb — Subprocessors for US and EU Honeycomb product (honeycomb.io/subprocessors), retrieved 2026-10-09; PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37) |
| Reachability is the easy half — Honeycomb is a backend, not a hosted site. Honeycomb's exporters and UI reach it from inside China, so the exposure is not whether it connects but where the telemetry it ingests comes to rest. The ICP filing question (State Council Order No. 292; MIIT Order No. 33) attaches to the public mainland dashboard or app you operate, not to Honeycomb as a backend service — while the PIPL cross-border and data-residency duties attach to the events and traces Honeycomb stores offshore. | Honeycomb 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 team, the question about Honeycomb is almost never whether the UI opens or whether an exporter can reach the ingest endpoint — both usually work. The real question is where the telemetry it gathers is allowed to come to rest. Honeycomb answers that plainly in its own documentation: it runs two data locations, one in the United States and one in the European Union, and none inside mainland China. So the events and distributed traces your services emit in China are ingested and then stored on a Honeycomb backend offshore. Because high-cardinality telemetry routinely carries personal information — client IP addresses, user IDs, and whatever request fields your instrumentation attaches — exporting it across the border is a transfer China’s law governs. The dashboard loading is the easy half; where the traces land is the exposure.
Honeycomb in China at a glance
| What decides it | In Honeycomb's own terms — and China's law |
|---|---|
| Where the data comes to rest | Honeycomb offers “US-based and EU-based data residency”; customer data is stored in AWS us-east-1 (US) or eu-west-1 (Ireland). There is no mainland-China location to choose, so telemetry gathered in China comes to rest offshore. |
| What the telemetry contains | High-cardinality events and distributed traces carry whatever your instrumentation attaches — user IDs, client IPs, request paths and fields. Honeycomb “only has access to the telemetry data that customers send,” so what crosses the border is exactly what your spans carry. |
| Can you keep it in China | No. The only locations are the US and the EU; neither is in the mainland, so a CIIO or large-volume handler's in-country storage duty cannot be met on Honeycomb alone. |
| Your China users' data | Collected in the mainland and shipped to a US or EU backend, it is a cross-border transfer PIPL governs — notice, a separate consent and a transfer mechanism (Articles 38–40); unscrubbed attributes can carry Article 28 sensitive personal information. |
| Is it reachable? | Yes — exporters and the UI connect from inside China. Reachability is not the axis; where the events and traces are stored is. |
No mainland region, so your telemetry comes to rest offshore
Honeycomb offers two data locations, and you choose one when you sign up. Its support documentation states that “Honeycomb has US-based and EU-based data residency,” and that “Customer data can be stored and processed in AWS us-east-1 (US East - USA) or AWS eu-west-1 (Europe - Ireland).” The US location answers at api.honeycomb.io and the EU location at api.eu1.honeycomb.io. Neither sits in mainland China, and there is no mainland location to select. So the OpenTelemetry collectors and SDKs running on your mainland services export their spans and events to whichever of those two offshore backends your team is on. Connecting to Honeycomb was never the obstacle; keeping the telemetry it ingests inside the country is.
The events and traces Honeycomb ingests are personal information
Observability data is not anonymous by nature — the opposite, really. High cardinality is the whole point of Honeycomb: you attach as many attributes to each event and span as you can, so you can slice by any of them later. Those attributes routinely include a user ID, a client IP, an account identifier, a request path, headers, and arbitrary fields your developers add. Honeycomb notes that “Unlike some other vendors, Honeycomb only has access to the telemetry data that customers send” — which places the contents, and the responsibility for them, squarely on you: what crosses the border is exactly what your instrumentation emits. A single mainland user’s client IP is already personal information, and under China’s Personal Information Protection Law sending it to a US or EU backend is a cross-border transfer. The handler — you, not Honeycomb — must give notice, take a separate consent for the overseas transfer, and clear one transfer mechanism: a data-export security assessment, the CAC standard contract, or certification (PIPL Articles 38–40).
Trimming your spans narrows what leaves — it does not close the door
Because Honeycomb only holds what you send, you have real control over the contents: you can drop or hash fields in your collector pipeline, omit client IPs, and keep sensitive values out of span attributes before anything is exported. That is worth doing. But trimming changes what crosses the border, not the fact that it crosses, and it does nothing for residency. Attributes that are not scrubbed can also carry sensitive personal information — precise location, or financial and health identifiers — which PIPL Article 28 singles out for stricter handling and a dedicated consent. And if you are a critical information infrastructure operator or a large-volume handler, personal information gathered in China has to be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37) — the data-localization requirement renumbered by the 2025 amendment that took effect January 1, 2026), a duty neither the US nor the EU Honeycomb location can satisfy. Separately, an ICP filing (State Council Order No. 292; MIIT Order No. 33) attaches to any public dashboard or app you actually serve to mainland visitors from inside China — a different door from Honeycomb-the-backend, and one that does not travel with your Honeycomb account.
This is a risk map, not a verdict: whether you owe separate consent, a transfer mechanism, in-country storage, an ICP filing, or some mix of them turns on what your spans carry, how much of it is personal, and who your users are — worth settling with counsel before you wire your collectors to an offshore backend.
Where 21YunBox fits — a compliant overlay, not a migration
You keep running Honeycomb. What an observability backend with only US and EU locations cannot give you is a lawful home inside China for the personal data your collectors and SDKs gather there. That is the piece 21YunBox adds. We map the PIPL cross-border and data-residency obligations that attach to the events and traces Honeycomb ingests — against your entity, your data volumes, and who your users are. Where telemetry cannot lawfully leave, we localize it onto a consented, in-country processing-and-storage pattern that keeps that data in the mainland. And we deliver the public, China-facing side on ICP-filed, in-country infrastructure — the 21YunBox Optimizer — set in front of the stack you already run, with no rebuild, no second codebase, and no move off Honeycomb for the telemetry that may lawfully cross. 21YunBox never uses or suggests circumvention of any kind; the point is a setup that runs legally and compliantly for your users in China.
Related reading:
- Cross-border data transfers under PIPL
- China’s data-export security assessment measures
- China’s Cybersecurity Law and data localization
- How to get an ICP filing for China
