Frontend Development 12 min read

Design of a WeChat Mini Program Frontend Error Monitoring System

This article presents a comprehensive design for a WeChat Mini Program frontend error monitoring system, covering background challenges, architectural and process design, SDK implementation, reporting mechanisms, and a visualized backend to help developers quickly locate and resolve runtime exceptions.

58 Tech
58 Tech
58 Tech
Design of a WeChat Mini Program Frontend Error Monitoring System

This article introduces a WeChat Mini Program frontend error monitoring system that captures and collects exceptions occurring during the lifecycle of online mini‑program projects.

Background : After a frontend project goes live, online issues are inevitable. While backend services can log errors, mature frontend monitoring solutions are scarce, especially for mini programs. Existing open‑source tools such as BadJS, JSTracker, fdSafe, sai.js, Sentry, and Fundebug each have limitations and do not fully satisfy all project needs.

Users often attribute performance problems to their devices, leading to high churn when other mini programs work fine. Because mini programs have low acquisition and abandonment costs, poor user experience quickly results in loss of users.

The current monitoring in WeChat’s backend lacks granularity, including:

Network request error statistics without quick server‑side location.

JS error statistics without detailed stack traces.

No page‑level monitoring to assess user experience.

No regional or carrier monitoring.

High page‑exit rates without performance correlation.

No monitoring of promise or async/await errors.

Design Solution

1. Architecture Design

SDK development: aggressive instrumentation, error interception, proxy monitoring, reporting strategy, API design, log interface, and data storage.

Real‑time query of reported logs.

Visualization management backend.

2. Process Design

The SDK acts like a dash‑cam, recording error timestamps and details locally, then reporting them to the backend. The server stores the data, groups errors by project, visualizes them, and sends alert emails when error thresholds are exceeded.

3. SDK Design – The Four Ws

(1) WHO : Collect basic user information such as IP (retrieved by the server during reporting), openid, and unionid, which are usually stored in globalData or local storage.

(2) DO WHAT : From a user‑visible perspective, errors are divided into five categories; developers and operators treat them with the same priority.

(3) WHICH ERROR – three main types:

HTTP request errors : non‑200 status codes or request fail callbacks; both request stack and full request details are stored.

JS errors : captured via aggressive instrumentation (function hijacking) and onError listeners in app.js; includes onLaunch, onShow, onHide, onError lifecycle hooks.

Resource upload/download errors : monitor wx.uploadFile and wx.downloadFile fail callbacks when uploading canvas‑generated QR codes or saving images.

(4) WHICH ENVIRONMENT : The SDK also records page stack and method stack information when users interact with pages, enabling visual reproduction of user flows in the backend.

4. Reporting Method

Errors are sent via API requests; to handle large log volumes, sampling, merging, and filtering are applied. Reporting can be configured to trigger after a certain number of logs (default 3) and can be synchronous or asynchronous (default sync).

During SDK initialization, new error types can be added, and certain errors can be excluded from reporting to avoid endless loops when the reporting endpoint itself fails.

5. Backend Visualization System

After the server receives reported data, it analyses and presents it through a visual dashboard that includes:

Total error count, proportion, and trend charts for a selected time window.

Grouped identical errors with priority, assignment, and actionable controls.

Filters by SDK version and error category.

Per‑user view showing page stack, method stack, request stack, basic user info, device version, and usage scenario.

Conclusion

Frontend error monitoring is a long‑term task that is crucial for any frontend development. Our system focuses on native WeChat Mini Program code and will gradually extend compatibility to Baidu, Alipay, and Toutiao mini programs, achieving a single SDK that monitors multiple platforms.

Because mini programs differ from traditional web frontends, we will employ source‑map techniques to simulate detailed error information and add compatibility for promise/async‑await errors, while further optimizing the reporting mechanism.

Author : Zhao Bingqi, Senior Frontend Engineer at 58.com ABG, responsible for second‑hand car mini‑program development.

frontendsdkArchitectureWeChat Mini ProgramLoggingerror monitoring
58 Tech
Written by

58 Tech

Official tech channel of 58, a platform for tech innovation, sharing, and communication.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.