Global monitoring can be green while users in mainland China cannot connect. These observations may describe different things: an overseas probe reads a health endpoint, while a user attempts sign-in across several hosts on another network. Align the scope before deciding what additional evidence is needed.
This guide focuses on monitoring design and disagreements between observations. For initial diagnosis, use the access troubleshooting guide. Existing overseas monitoring remains useful; adding China observations fills a coverage gap rather than discrediting another tool.
1. Define exactly what the green indicator proves
Review the actual target, method, port, success condition, probe location and last execution time. An expected response from /health is not the same success condition as completing browser sign-in. A recent green result may predate the incident. Separate observation time, dashboard viewing time and notification delivery time.
Write the definition plainly: “An HTTPS health endpoint responds from this overseas probe.” Confirm redirect handling, dependency coverage and whether checks continued during the incident. Do not rename a limited measurement “availability for every user worldwide.”
2. Give reports and checks comparable fields
Record hostname, service port, observation network, timezone-aware time, method, result category and freshness. Add the user's failed step, browser error, connection type, and proxy or corporate gateway use. If a tool does not disclose a field, mark it unknown instead of inventing precise settings.
One hostname can serve different paths, ports and dependencies. A domain-level protocol check and a business URL are not identical requests; HTTP and HTTPS observations are not interchangeable. Keep diagnostic paths in controlled systems, sharing only templates without query tokens or personal identifiers.
3. Design layers instead of one universal indicator
| Observation layer | Evidence it contributes | Evidence still needed |
|---|---|---|
| Overseas uptime monitoring | Service state for selected locations and methods | Mainland China network observations |
| China domain checks | Network results within the method, time and coverage | User-device and application validation |
| Affected browser | The failing page, API or resource step | Contemporaneous server and network records |
| Application/infrastructure logs | Request handling, errors and changes | Requests that never arrived and other network evidence |
Assign owners to these layers. Homepage, authentication and API hosts are separate targets; one layer's normal result does not erase another's failure. WeaveBit domain checks do not log in, execute scripts or load every resource. They also do not replace browser certificate-trust validation or dedicated IPv6 and QUIC/HTTP/3 validation.
4. Repeat the original configuration before broadening coverage
When observations disagree, repeat the same target, port, method and node configuration, recording the new time. Changing the network and target while rechecking cannot establish recovery under the original conditions. Record intervening releases, DNS/CDN changes or access-policy changes too.
Then add GFW nodes relevant to the affected users' regions and carriers as separate comparisons. Review coverage in the current node list; actual selectable nodes are determined by Console or API availability when creating the task. This does not promise to reproduce a particular home connection or cover every residential network. Report actual scope rather than generalizing one node's outcome to all users in China.
5. Add the check that answers the missing question
For an initial DNS Pollution observation on one authorized hostname, use the free DNS check. A normal result means that observation did not report this abnormality, not that the application works. Keep indeterminate results awaiting confirmation rather than treating them as normal or blocked.
For multiple domains or broader HTTP/HTTPS-related questions, choose GFW Full directly; a separate DNS check for every domain is not a prerequisite. Full combines DNS Pollution, HTTP Host and TLS SNI dimensions plus a summary, not all seven methods. Select relevant GFW nodes; DNS Pollution does not require user-selected nodes. Follow the Full guide and result reference, preserving public states without speculating about internal assessment methods.
6. Investigate disagreement rather than counting votes
First compare target, port, method, network and time, then each tool's definition of success. A successful connection, a successful page response and a successful login are different conclusions. Two probes described as China nodes need not share an exit network or user conditions.
A fictional example, not a customer incident: two checks use the same hostname, but one records a successful TCP connection in the morning and the other a TLS timeout in the afternoon. Labels of Normal and Indeterminate did not answer the same question at the same time. Retain both records, then compare the networks using consistent ports and methods within a similar time window rather than declaring a tool wrong by majority vote.
If targets align but results still differ, document visible differences, repeat original configurations and assign follow-up. Keep missing observations unknown. A response, timeout or reset label alone does not identify the responsible party or cause.
7. Check the monitoring system's health too
Confirm tasks remain enabled, execution times advance, inventories are current and relevant nodes are available. For Console monitoring, also inspect balance, consumption and notification settings. No alert may mean no new observation or delayed delivery; it is not proof of no incident.
Group critical dependencies by importance and owner. Choose frequency from current Console options in line with budget and response capacity. Use the monitoring guide, or the API documentation for your own scheduling and storage. An API batch is not automatically recurring monitoring.
8. Hand over evidence and confirm recovery separately
A minimal record includes the failed step, host/port, timezone-aware time, user network, each observation's method and scope, normal/abnormal/indeterminate states, last valid execution, same-configuration follow-up, changes, owner and next action.
Manually share reviewed fields only. Remove cookies, authorization headers, keys, query tokens, identity and order details. Do not attach raw HAR, request bodies, full logs or replay commands.
Confirm recovery using fresh, comparable observations and the affected business experience, stating the verified scope. Add critical-domain monitoring through the Console entry point while retaining overseas monitoring and application validation. The goal is explainable evidence, not a permanently green dashboard.