Ctrip Mini-Program Automated Error Warning Solution

Ctrip’s front‑end framework team built a complete and generic error monitoring solution for its WeChat mini‑programs. The solution injects a buildId into the code during CI deployment, provides an SDK that automatically captures runtime errors, and corrects pagePath offsets to accurately notify responsible developers.

Why error monitoring is needed – Ctrip’s mini‑programs serve a massive C‑end user base with diverse devices and scenarios. Users cannot always report problems, so proactive collection and real‑time monitoring of errors are essential for system stability and user experience.

Source‑map storage and mapping – After CI uploads the mini‑program, the buildId is embedded in the bundle. A fixed robotId is used to upload the source code and retrieve the corresponding source‑map file. The source‑map is stored on Ctrip’s file server, and its link, buildId, timestamp, and remarks are saved in a MySQL database to ensure accurate mapping.

Error collection and log reporting – In the client, errors are captured via wx.onError and wx.onUnhandledRejection . Key fields (pagePath, message, stack) are extracted, pagePath offsets are corrected, and the error, appId, and buildId are reported through the User Behavior Tracking (UBT) system.

Data aggregation – Reported errors are cleaned, filtered, and aggregated on the server, then stored in an APM MySQL database. Aggregated data can be displayed by department, platform, pagePath, version, and top error types, providing the basis for alerting.

Real‑time monitoring and alerting – Alerts are sent at three lifecycle stages: development, experience, and production. Development alerts trigger every minute per pagePath; experience alerts add approval steps; production alerts fire based on error volume thresholds (e.g., >100 errors per page in 5 minutes or >300 errors per Bundle in 1 hour). Alerts are delivered via TripPal and escalated through the BigEyes governance system if not responded to in time.

Figure 1: Error warning stages diagram.

Figure 2: Design of the error warning solution.

Source‑code mapping – When viewing an error in the APM UI, developers can click a link to the source‑code parsing system. Using the stored buildId, the system fetches the correct source‑map, resolves the original source location, and displays it in Monaco Editor for quick debugging.

Figure 12‑15: Error overview, aggregation, detail, and source‑code pages.

Conclusion – The automated error warning solution enables early detection of runtime errors during development and testing, dramatically reduces production‑stage errors, and improves overall stability and user experience. Since adoption, daily error counts have dropped by about 95%, earning strong positive feedback from business units.