How to Build Effective Frontend Monitoring and Alerting Strategies

Background

1. Monitoring strategy levels across services are inconsistent; lack of standards leads to some services having complete monitoring while others cannot reuse.

2. The group's frontend monitoring platform is incomplete, causing high alarm noise; developers cannot think through and create effective monitoring, leading to ignored alerts.

3. Platform's dashboard, log, and alarm capabilities are poor compared to industry, limiting tool value.

4. Frontend monitoring lacks independent technical value; it often duplicates backend monitoring. Its value should include user experience, device compatibility, and missing elements.

1. Business Value Positioning of Frontend Monitoring

1.1 Link Tracing

The diagram shows five core links that can cause frontend failures.

1.3 Monitoring Classification

Monitoring Categories

Passive collection: performance monitoring, resource availability, load time, runtime exceptions (compatibility, etc.)

Active reporting: abnormal business response monitoring, business availability monitoring, rendering fault monitoring

Detailed Categories

Resource Availability (auto‑collected by SDK)

Page resources (HTML) load timeout/slow access

Logic resources (JS) load timeout/slow access

Style resources (CSS) load timeout/slow access

Image resources load timeout/slow access

API resources timeout/slow (frontend default 3 s)

Upstream dependencies / third‑party SDK / service interfaces

Fault Localization (custom reporting)

Goal: Detect quickly, stop loss fast.

Customer‑complaint faults: retrieve session‑level request/response logs to assist backend fault location.

Release faults: after new feature/page/component launch, boundary cases trigger dual‑line alerts for timely mitigation.

Business input anomalies

Rendering Faults (custom reporting)

Missing elements (components, sections)

Element disorder (under construction)

Illegal values (price zero, negative, etc.)

Element render failure

Compatibility rendering faults

White‑screen monitoring (under construction)

Business Unavailability (custom reporting)

System exception (API unavailable)

Upstream service unavailable

Interface timeout

Identity mismatch

No data available (e.g., coupon without product)

Overwhelming traffic

Other business attributes

2. Monitoring & Alert Strategies

2.1 Monitoring Targets

Key monitoring objects: critical elements, high‑traffic pages/components, high‑value components, loss‑prone components/pages.

Routine inspection objects: low‑activity components/pages, scheduled monitoring points.

2.2 Efficient Reporting

One report, multiple monitoring points.

Use the platform’s regex fuzzy‑matching on the message field to configure flexible monitoring of an entire downstream chain for a single interface.

2.3 Effective Monitoring (Optimization)

Technical solutions set monitoring policies to identify business‑boundary cases.

Regular online log reviews enrich and tune alerts and monitoring.

Periodically clean up zombie monitors and alerts.

3. Standardizing Monitoring Alerts

3.1 Interface Service Fault Standard

<code>{
  "success": false | true, // communication code: whether interface returns normally
  "errorCode": "xxxxxx", // error code indicating reason and category
  "data": {}, // business data for frontend display
  "message": "xx interface unavailable", // brief description of exception
  // ... other fields
}</code>

3.2 Rendering Layer Fault Standard

White screen (type: no_page) – message: white_screen_ business _pageURL; data: runtime exception logs, slow resource/interface logs.

Illegal amount (type: illegal_money) – message: illegal_money_ business _elementInfo; data: actual amount, data source, request, response, pin.

Element missing (type: no_element) – message: element_missing_ business _elementInfo; data: element info, data source, request, response, pin.

Dependency resource fault (type: rely_error) – message: dependency_fault_ business _resourceInfo; data: resource info, fault logs.

Compatibility fault (type: compatibility_error) – message: compatibility_error; data: exception resource info, runtime logs, device, system info.

3.3 Reporting Action Standard

<code>monitor.reportError({
  type: 'interface_error',
  message: 'xx service exception, fault info: ' + functionID + '...',
  data: {
    request: {...},
    response: {...}
  }
});</code>

<code>monitor.reportError({
  type: 'render_error',
  message: 'element_missing_xxx_section',
  data: {
    element: elementInfo,
    functionID: xxx,
    request: {...},
    response: {...},
    pin: xxx
  }
});</code>

4. Fault‑Response SOP (Precise Issue Discovery)

4.1 SOP

1. Monitoring point collection and reporting.

2. Set multiple alerts matching business faults.

3. Platform receives alerts.

4. Open alert to view fault curve.

5. Use alert info to view logs and locate fault.

Report to monitoring platform, create liaison group for deeper diagnosis.

7. Report potential customer‑complaint, loss, and system risk to product‑research.

8. Formulate emergency loss‑mitigation plan and turn into technical solution.

9. Follow up bug‑fix testing, release, and monitor alert curve.

10. Emergency response and inform business group of resolution.

11. Follow up on fault platform and conduct timely post‑mortem.

Scan to join the technical discussion group