Does Statuspage Work in China? Reachability, Hosting & Subscriber Data
Statuspage is hosted entirely offshore on Atlassian's AWS infrastructure — no mainland-China region and, unlike Jira or Confluence, no data-residency option — so a status page built to stay reachable during an incident depends on a cross-border path, and any subscriber emails and phone numbers you collect from China users sit offshore under PIPL. A compliance-first look.
Does Statuspage work in China?
Whether Statuspage "works" in China turns first on reachability — and, if you collect subscribers, on where their contact data lives — not on raw speed. A status page earns its keep by loading during an incident, yet Statuspage is hosted entirely offshore, so the page your mainland users open mid-outage depends on a cross-border path at its least dependable moment.
Atlassian's own data-residency documentation scopes its residency control to "Jira, Jira Service Management, Jira Product Discovery, Confluence, and Loom" — Statuspage is not on that list — and the locations it does offer (Australia, Canada, the EU, Germany, India, Japan, Singapore, South Korea, Switzerland, the UK and the USA) include none in mainland China, so a status page sits in the all-AWS "Global" pool. Separately, if you use subscriber notifications, Statuspage "can send out notifications to your customers via email and SMS" — collecting emails and phone numbers that, gathered from China users and held offshore, are a cross-border transfer PIPL governs. The table below is Atlassian's own wording and the rules it triggers.
This is a risk picture, not a verdict — a public status page with no subscribers carries little personal data, while reachability and subscriber storage are where the exposure sits. Our China team can map your Statuspage exposure with you →
Compliance snapshot
- ! Reachable in principle, but hosted entirely offshore on Atlassian's AWS (served on *.statuspage.io) — it depends on a cross-border path at the exact moment an incident makes that path least dependable
- ✕ No mainland-China region, and Statuspage isn't covered by Atlassian's data-residency control — its data sits in the all-AWS "Global" pool
- ! Turn on subscriber alerts and the emails and SMS phone numbers you collect are personal data held offshore — a PIPL cross-border transfer
- ! That data exposure scales with your subscriber volume and your role (a CIIO or large-volume handler owes in-country storage)
- ✓ A compliant in-country delivery path — and in-country subscriber storage where required — exists with no rebuild and no migration
What Statuspage's own documentation says about China
| Fact | Primary source |
|---|---|
| In Atlassian's own words: data residency "gives you control over where your in-scope app data for Jira, Jira Service Management, Jira Product Discovery, Confluence, and Loom is hosted" — a list that does not include Statuspage. The locations it offers (Australia, Canada, EU, Germany, India, Japan, Singapore, South Korea, Switzerland, UK, USA) contain no mainland-China region, and by default "all Atlassian apps are hosted in the Global location, which includes all of our AWS regions," with Atlassian moving data "between these regions as necessary." A Statuspage status page is therefore served from offshore, with no mainland-China hosting or residency option. | Atlassian — Understand data residency, retrieved 2026-10-07 |
| Turn on subscriber notifications and Statuspage collects the contact details it needs to reach people: by Atlassian's documentation it "can send out notifications to your customers via email and SMS," with subscribers added by email address or SMS phone number — individually, by CSV import, or via the API. Those emails and phone numbers are personal information; collected from users in China and stored on Statuspage's offshore infrastructure, they are a cross-border transfer PIPL governs — requiring notice, separate consent, and one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification). | Atlassian — Enable subscribers (Statuspage), retrieved 2026-10-07; PIPL Chapter III, Articles 38–43 |
| The subscriber-data exposure scales with volume and role, not with merely running a status page: under the CAC's March 2024 cross-border rules, a non-CIIO transferring fewer than 100,000 individuals' non-sensitive personal information in a calendar year is exempt from the security assessment, standard contract and certification. A large subscriber list, or sensitive handling, changes that calculus. | CAC — Regulations on Promoting and Regulating Cross-border Data Flows, March 2024 |
| For a CIIO or large-volume handler, personal information collected in China must be stored inside mainland China (PIPL Article 40; CSL Article 39 (formerly Article 37)). Statuspage offers no mainland-China region, so keeping your China subscribers' contact data on Chinese soil — and serving a status page that stays reachable from inside the mainland — means running that delivery and storage on infrastructure in the mainland, which is where an ICP filing enters the picture. | PIPL Article 40; CSL Article 39 (formerly Article 37) |
Sources verified by the 21YunBox compliance team on 2026-10-07.
For a mainland-China audience, the question about Statuspage is not how quickly it paints — it is whether the page loads at all when it matters, and where the contact details of the people you notify end up. Statuspage is hosted entirely offshore on Atlassian’s AWS infrastructure, with no region inside mainland China and, unlike Jira or Confluence, no data-residency option to pin it closer. That leaves two things exposed: a status page that must stay reachable during an incident is served across a border link at its least dependable, and any subscriber emails and phone numbers you gather from Chinese users live outside the mainland under China’s data law. Atlassian documents both in its own words.
Statuspage in China at a glance
| What decides it | In Atlassian's own terms |
|---|---|
| Where it runs | Hosted on Atlassian's AWS infrastructure and served on *.statuspage.io. By Atlassian's documentation, apps default to the “Global” location spanning “all of our AWS regions,” none of which is inside mainland China. |
| Data residency | Atlassian's residency control covers “Jira, Jira Service Management, Jira Product Discovery, Confluence, and Loom” — not Statuspage. There is no option to pin a status page's data, let alone to the mainland. |
| Staying reachable | A status page's job is to load during an incident. Served from offshore, it reaches mainland China across a cross-border link that is least reliable during exactly the disruption it exists to report. |
| Your subscribers' data | Enable subscriber notifications and Statuspage “can send out notifications to your customers via email and SMS,” collecting emails and phone numbers — personal information held offshore, a PIPL cross-border transfer. |
| Serving & storing in China | Keeping a status page reachable from inside the mainland, and China subscribers' contact data on Chinese soil, needs in-country delivery and storage — which an offshore-only service cannot provide and which brings an ICP filing into scope. |
A status page you cannot load is worse than none
The whole value of a status page is that it stays up when your product does not. It is the page a customer opens the moment your service feels broken — and for a mainland-China customer, Statuspage answers that moment from offshore. Hosted on Atlassian’s AWS infrastructure and served on *.statuspage.io, a status page reaches China only across the cross-border path, and that path is least dependable during precisely the congestion, routing churn and network stress that accompany a real incident. Statuspage is not singled out for blocking; the problem is structural. An offshore status page your China users cannot count on loading mid-outage does not merely underperform — it inverts its own purpose, because an incident they cannot see explained looks to them like one you are hiding. Reachability here is a delivery fact, not a compliance fact — but it is the first thing that decides whether Statuspage “works” for a China audience at all.
Hosted offshore, with no mainland region and no residency option
Where a status page is hosted settles what you can and cannot do about it. Atlassian’s data-residency documentation lets customers pin where in-scope data lives, but it scopes that control to “Jira, Jira Service Management, Jira Product Discovery, Confluence, and Loom” — Statuspage is absent from the list. By default, Atlassian says, “all Atlassian apps are hosted in the Global location, which includes all of our AWS regions,” and it will “dynamically determine where their in-scope data is located, and optimize performance by moving data between these regions as necessary.” Not one of those AWS regions sits in mainland China. So a Statuspage page is not merely far from China — there is no mechanism to bring it, or its data, inside the mainland.
That geography also forecloses an ICP filing. A public site served to mainland visitors from inside China turns on ICP recordal (ICP 备案) under State Council Order No. 292 and MIIT Order No. 33, and that filing must attach to a hosting resource physically located in the mainland. An offshore-only service has nothing to file against — which is why “we already publish status on Statuspage” does not carry into China: reaching the mainland and being cleared to serve it from inside it are two different things, and tuning the page closes neither gap.
Your subscribers’ contact data leaves the country
A purely public status page carries little personal data. The exposure appears the moment you use Statuspage’s subscriber notifications. By Atlassian’s own documentation Statuspage “can send out notifications to your customers via email and SMS,” and to do that it collects what it needs to reach them — email addresses and SMS phone numbers, added one by one, by CSV import, or through the API. Those are personal information. Gathered from users in mainland China and held on Statuspage’s offshore infrastructure, they are a cross-border transfer under the Personal Information Protection Law: the handler — you, Atlassian’s customer, not Atlassian — must give notice, obtain separate consent, and clear one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification).
The weight of that duty scales with your subscriber list and your role. Under the CAC’s March 2024 cross-border rules a non-CIIO moving fewer than 100,000 individuals’ non-sensitive personal information in a calendar year is exempt from those mechanisms, while a CIIO or large-volume handler must keep personal information collected in China inside the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a residency duty an offshore-only status service cannot meet.
This is a risk map, not a verdict. A status page with no subscribers is mostly a reachability question; add subscriber notifications and it becomes a cross-border-data question too — and how far that reaches depends on your volumes, your role and what you collect. Worth settling with counsel before you build.
Where 21YunBox fits — a compliant overlay, not a migration
You keep running Statuspage. We add the piece an offshore-only service cannot: a status channel that stays reachable from inside the mainland — ICP-filed, in-country delivery placed in front of your existing status page — so your China users can load it during the very incident it exists to report, with no rebuild and no second system. Where the law requires it, we also keep your China subscribers’ contact data on Chinese soil. Our China team maps your reachability and subscriber-data obligations against your entity and data volumes, then stands up the in-country delivery and storage a lawful China presence needs, while Statuspage stays exactly where it already runs.
Related reading:
Frequently Asked Questions
Is Statuspage blocked in China?
Not outright. Statuspage pages are hosted offshore on Atlassian's AWS infrastructure and served on statuspage.io, so they are reachable in principle but depend on a cross-border path — least dependable during the congestion and incident conditions a status page is meant for. The practical risk is less a hard block than a status page your mainland users cannot count on loading at the exact moment they need it.
Does using Statuspage create a China data-compliance problem?
Only to the extent you collect personal data through it. A purely public status page carries little. But if you enable subscriber notifications, Statuspage collects subscribers' emails and SMS phone numbers and holds them on offshore infrastructure with no mainland-China region — a cross-border transfer of personal information PIPL governs. Whether you also face an in-country storage duty depends on your role (for example, whether you are a CIIO) and the volume you handle. Treat it as a risk to confirm with counsel, not a blanket prohibition.
Can 21YunBox help make our Statuspage setup work for China?
Yes. Our China team can assess your reachability and subscriber-data exposure for your data volumes and role, and stand up a compliant, ICP-filed in-country delivery path for status communication — and, where the law requires your China subscribers' contact data to stay on the mainland, in-country storage — without moving you off Statuspage. Get in touch to work through your specific case.
