Skip to main content
Flashduty RUM provides a complete pipeline from data filtering and alert grading to Flashduty alert processing. Properly configuring this pipeline can effectively reduce alert noise and help your team focus on what truly matters. This guide covers the core principles and typical scenario configurations to help you quickly reduce unnecessary alert noise.

​
Alert Processing Pipeline

RUM alerts pass through four layers from Error generation to human notification: We recommend configuring from top to bottom: first filter noise, then grade alerts, and finally fine-tune on the Flashduty side.

​
Step 1: Filter Noise Data

Before configuring alert grading, start by cleaning up the data source. Common noise sources include:
Errors from browser extensions or third-party ad/analytics scripts are unrelated to your business and should be excluded:
  • Error Stack contains chrome-extension://
  • Error Stack contains moz-extension://
  • Error Stack contains cdn.third-party.com
Some errors occur frequently but don’t affect user experience:
  • Error Message contains ResizeObserver loop
  • Error Message contains Script error
If you only care about production alerts, filter out other environments:
  • Environment not contains production
Filtered Errors will not participate in Issue aggregation or alerting, but the data is still retained. You can view these filtered errors in the Explorer using filter conditions.

​
Step 2: Configure Alert Grading

After filtering noise, use alert grading rules to differentiate the importance of different errors.

​
Grading Strategy Recommendations

Here are recommended rules ranked by business priority from high to low:
1

Production crashes → P0

A crash means the application is completely unavailable, requiring the highest priority response.
  • Condition: Environment contains production, AND Is Crash contains true
  • Alert level: P0
2

VIP user errors → P0

VIP user experience is directly tied to business value.
  • Condition: User ID contains vip (or match via custom field context.user.level contains vip)
  • Alert level: P0
3

Critical page errors → P1

Errors on payment, login, and checkout pages need priority handling.
  • Condition: Page URL contains /payment
  • Alert level: P1
You can create separate rules for each critical page, or use multiple match values in a single rule.
4

Other errors → P2 (default)

Errors not matching any rule are automatically classified as P2 and handled through standard processes. No additional configuration needed.
We recommend keeping the number of rules to 3-6, covering the most critical scenarios. Too many rules increase maintenance cost and can lead to priority confusion.

​
Step 3: Fine-Tune in Flashduty

Alert grading on the RUM side is based on individual Error attributes. For further processing based on the overall impact of an Issue, configure it in the Flashduty Alert Pipeline.

​
Typical Scenario Configurations

E-commerce apps focus on the transaction flow, so alert configuration should center on payment and ordering.

​
FAQ

They complement each other, serving different dimensions:
  • RUM Alert Grading: Based on individual Error attributes (user, page, environment, etc.), suitable for quick determination at the source
  • Flashduty Pipeline: Based on overall Issue information (affected user count, error count, etc.), suitable for more comprehensive assessment
We recommend setting base priority on the RUM side and making supplementary adjustments on the Flashduty side.
No. If you don’t configure any filter rules or alert grading, all Errors will still be aggregated into Issues and delivered to Flashduty with default severity. Existing behavior remains completely unchanged.

​
Further Reading

Issue Alerts

Complete configuration guide for alert triggers, custom grading, and data filtering

Alert Pipeline

Clean, transform, and filter alerts at the integration layer

Noise Reduction

Aggregate and suppress alerts at the channel level

Escalation Rules

Configure escalation rules to route alerts to the right responders