Boost Frontend Issue Detection: Lessons from JSTracker’s Monitoring Evolution

In the past year, the Taobao frontend team unified monitoring integration, yet the detection rate of frontend failures and issues remained low. In FY21, all Taobao‑frontend‑related incidents were discovered manually. Improving online issue detection is the top priority.

What is an Issue?

Any actual online impact, even minor, that does not meet the fault definition is collectively called an issue.

How is Issue Detection Rate Calculated?

Issues include those recorded online, discovered during gray‑rollbacks, and those appearing in urgent releases.

The article introduces thoughts on issue detection rate and the evolution of the JSTracker platform , an end‑to‑end frontend monitoring and data analysis system focused on safety production and experience metrics.

Background

To better analyze current issues, online‑recorded issues are categorized into three types:

Detection issues: page white‑screen, empty holes, or

undefined

errors.

Business issues: require business to add instrumentation to be discovered.

Alarm issues: traffic drop, new error logs, etc., without alarm subscription.

Statistical analysis of 2020‑2021 Taobao online issues shows detection issues (7%), business monitoring gaps (15%), and alarm coverage gaps (7%).

The low detection rate is mainly due to incomplete detection coverage, insufficient alarm capability, and missing business monitoring points.

Analysis & Thoughts

Collaboration with business developers reveals a large gap in monitoring awareness and goals; most businesses only integrate the monitoring SDK and subscribe to basic metrics, making many frontend issues hard to detect through conventional technical indicators.

Link Analysis

A typical page load passes through five nodes, each potentially causing issues:

Entry configuration delivery: operational config issues.

Container loading: mini‑program or WindVane container startup failures.

Origin resources: JS, image loading failures.

JS execution: blocking rendering or functional failures.

API: data mismatches or errors affecting page content.

Page rendering stage: white‑screen, empty holes, style glitches.

Page interaction stage: feature unavailability, page jitter.

Metric Analysis

Current monitoring focuses on technical metrics such as JSError, Crash, and API errors. However, technical anomalies often do not correlate with user‑perceived problems; for example, a large number of JS errors may have no business impact. Therefore, business side needs to focus on experience metrics that truly reflect online issues.

By correlating experience metric anomalies with technical metric anomalies, a reasonable issue discovery and resolution path emerges, requiring a shift from monitoring technical metrics to monitoring experience metrics.

Technical Solution

The analysis leads to three improvement areas for the monitoring platform:

Unexpected rendering (white‑screen detection)

Business monitoring upgrade

Alarm monitoring upgrade

Unexpected Rendering

JSTracker already integrates UC kernel white‑screen data, but lacks detection for external and iOS scenarios. The SDK must capture page‑no‑content, error pages, and missing first‑screen modules.

By collecting page information in the SDK, modeling and statistical analysis in the cloud can determine whether rendering matches expectations based on DOM node counts across different stages.

Statistical results classify logs into expected and unexpected nodes, visualized as distribution charts where red indicates unexpected rendering.

Rendering status release: recent hour distribution, red = unexpected rendering, X‑axis = DOM node count, Y‑axis = sample count.

Unexpected anomaly rate: calculated every 5 minutes based on DOM node statistics.

Business Monitoring

The goal is to accurately reflect and measure business health. Using an order‑placement scenario, current custom instrumentation suffers from missing log standards, limited field extensibility, and weak platform capabilities.

SDK layer: core logic extracted into

jstracker-core

library, compatible with sdk‑assets and universal‑tracker, providing a unified reporting interface.

Platform side: added metric dimension extensions, custom attribute capabilities, and custom error‑rate (success‑rate) metrics; optimized business monitoring UI.

Example on H5 homepage: focus on ad carousel, navigation components; monitor exposure anomaly ratio, click counts, and click‑through rates.

Business extension: custom dimension fields for multi‑dimensional filtering and aggregation.

Custom metric capability: support custom error rates, latency, etc., calculated from page PV or custom PV metrics.

Alarm Monitoring

Alarm monitoring must provide effective alerting for experience metrics. Fragmented environments (different system versions, client versions, complex upstream/downstream dependencies) require fine‑grained alarm dimensions, strategies, and schemes.

Alarm dimensions: monitor metrics by frontend version, client version, browser version, etc.

Alarm strategies: configure thresholds, error rates, YoY, MoM for alerts.

Alarm schemes: subscribe to different alert plans based on scenario, e.g., new error logs during gray releases or complex business flows.

Conclusion

Frontend safety production still lags behind backend. Improving issue detection requires both platform capability enhancements and business cooperation in monitoring governance. Future work will continue to optimize unexpected rendering detection, reduce integration cost, strengthen business monitoring configuration, expand scenario coverage, and enrich fine‑grained alarm dimensions while lowering subscription overhead.