Skip to content

Commit 08a5363

Browse files
Fiona2016Fiona2016
committed
feat: rum alert docs
1 parent a1c6eb3 commit 08a5363

3 files changed

Lines changed: 318 additions & 12 deletions

File tree

‎docs.json‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -715,7 +715,8 @@
715715
{
716716
"group": "Best Practices",
717717
"pages": [
718-
"en/rum/best-practices/distributed-tracing"
718+
"en/rum/best-practices/distributed-tracing",
719+
"en/rum/best-practices/alert-noise-reduction"
719720
]
720721
},
721722
{

‎en/rum/best-practices/alert-noise-reduction.mdx‎

Lines changed: 183 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,183 @@
1+
---
2+
title: "Too Many RUM Alerts? Start Here"
3+
sidebarTitle: "RUM Alert Noise Reduction"
4+
description: "Reduce unnecessary alert noise and focus on what matters through data filtering, alert grading, and Flashduty integration."
5+
---
6+
7+
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.
8+
9+
This guide covers the core principles and typical scenario configurations to help you quickly reduce unnecessary alert noise.
10+
11+
## Alert Processing Pipeline
12+
13+
RUM alerts pass through four layers from Error generation to human notification:
14+
15+
| Layer | Configuration Location | Core Function |
16+
|-------|------------------------|---------------|
17+
| ① Data Filtering | RUM App → Alert Settings | Exclude unwanted Errors at the source, reducing unnecessary Issues |
18+
| ② Alert Grading | RUM App → Alert Settings | Set Issue priority based on Error attributes |
19+
| ③ Alert Processing | Flashduty Integration → Alert Pipeline | Adjust priority, drop/suppress based on Issue dimensions |
20+
| ④ Alert Dispatch | Flashduty Channel | Route to teams, notify responders |
21+
22+
We recommend configuring **from top to bottom**: first filter noise, then grade alerts, and finally fine-tune on the Flashduty side.
23+
24+
## Step 1: Filter Noise Data
25+
26+
Before configuring alert grading, start by cleaning up the data source. Common noise sources include:
27+
28+
<AccordionGroup>
29+
<Accordion title="Third-party script errors">
30+
Errors from browser extensions or third-party ad/analytics scripts are unrelated to your business and should be excluded:
31+
32+
- Error Stack contains `chrome-extension://`
33+
- Error Stack contains `moz-extension://`
34+
- Error Stack contains `cdn.third-party.com`
35+
</Accordion>
36+
<Accordion title="Known harmless errors">
37+
Some errors occur frequently but don't affect user experience:
38+
39+
- Error Message contains `ResizeObserver loop`
40+
- Error Message contains `Script error`
41+
</Accordion>
42+
<Accordion title="Non-production environment errors">
43+
If you only care about production alerts, filter out other environments:
44+
45+
- Environment not contains `production`
46+
</Accordion>
47+
</AccordionGroup>
48+
49+
<Tip>
50+
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.
51+
</Tip>
52+
53+
## Step 2: Configure Alert Grading
54+
55+
After filtering noise, use alert grading rules to differentiate the importance of different errors.
56+
57+
### Grading Strategy Recommendations
58+
59+
| Priority | Use Cases | Expected Response Time |
60+
|----------|-----------|------------------------|
61+
| **P0 (Critical)** | Core business disruption, VIP users affected, production crashes | Immediate response |
62+
| **P1 (Warning)** | Important feature errors, critical page errors | Same-day resolution |
63+
| **P2 (Info)** | Non-critical feature errors, low-impact issues | Scheduled resolution |
64+
65+
### Recommended Rule Configuration
66+
67+
Here are recommended rules ranked by business priority from high to low:
68+
69+
<Steps>
70+
<Step title="Production crashes → P0">
71+
A crash means the application is completely unavailable, requiring the highest priority response.
72+
73+
- Condition: Environment contains `production`, AND Is Crash contains `true`
74+
- Alert level: P0
75+
</Step>
76+
<Step title="VIP user errors → P0">
77+
VIP user experience is directly tied to business value.
78+
79+
- Condition: User ID contains `vip` (or match via custom field `context.user.level` contains `vip`)
80+
- Alert level: P0
81+
</Step>
82+
<Step title="Critical page errors → P1">
83+
Errors on payment, login, and checkout pages need priority handling.
84+
85+
- Condition: Page URL contains `/payment`
86+
- Alert level: P1
87+
88+
You can create separate rules for each critical page, or use multiple match values in a single rule.
89+
</Step>
90+
<Step title="Other errors → P2 (default)">
91+
Errors not matching any rule are automatically classified as P2 and handled through standard processes. No additional configuration needed.
92+
</Step>
93+
</Steps>
94+
95+
<Tip>
96+
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.
97+
</Tip>
98+
99+
## Step 3: Fine-Tune in Flashduty
100+
101+
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](/en/on-call/integration/alert-integration/alert-pipelines).
102+
103+
| Processing Scenario | Configuration |
104+
|---------------------|---------------|
105+
| Suppress repeated alerts | Same `alert_key` alerts only once within 1 hour |
106+
| Custom alert title | Template example: `[RUM] [{{Labels.env}}] {{Labels.error_type}} - {{Labels.view_url}}` |
107+
| Downgrade low-impact errors | When `labels.affected_users` < 5, update severity to Info |
108+
109+
## Typical Scenario Configurations
110+
111+
<Tabs>
112+
<Tab title="E-commerce">
113+
E-commerce apps focus on the transaction flow, so alert configuration should center on payment and ordering.
114+
115+
| Layer | Configuration |
116+
|-------|---------------|
117+
| Data Filtering | Exclude: third-party ad script errors, `ResizeObserver loop` |
118+
| Alert Grading | P0: payment page errors, crashes; P1: product detail/cart errors |
119+
| Alert Processing | Suppression window: 30 min; title template includes page path |
120+
| Alert Dispatch | P0 → SMS + phone call, P1 → IM notification |
121+
</Tab>
122+
<Tab title="SaaS Application">
123+
SaaS apps need to monitor experience differences across tenants.
124+
125+
| Layer | Configuration |
126+
|-------|---------------|
127+
| Data Filtering | Exclude: browser extension errors, non-production environments |
128+
| Alert Grading | P0: enterprise tenant errors (via `context.tenant.plan`); P1: core feature page errors |
129+
| Alert Processing | Title template includes tenant info; downgrade low-impact alerts |
130+
| Alert Dispatch | Assign to different channels by team |
131+
</Tab>
132+
<Tab title="Content Website">
133+
Content websites have relatively relaxed availability requirements, focusing on loading and rendering issues.
134+
135+
| Layer | Configuration |
136+
|-------|---------------|
137+
| Data Filtering | Exclude: third-party script errors, `Script error` |
138+
| Alert Grading | P0: crashes; P1: homepage/search page errors |
139+
| Alert Processing | Suppression window: 1 hour; downgrade alerts with affected users < 10 |
140+
| Alert Dispatch | P0 → IM notification, P1/P2 → email notification |
141+
</Tab>
142+
</Tabs>
143+
144+
## FAQ
145+
146+
<AccordionGroup>
147+
<Accordion title="What's the difference between data filtering and Flashduty alert dropping?">
148+
| Comparison | RUM Data Filtering | Flashduty Alert Drop |
149+
|------------|-------------------|---------------------|
150+
| Timing | Before Error aggregation into Issue | After Issue is delivered as alert |
151+
| Data Retention | Error data retained, viewable in Explorer | Issue data retained |
152+
| Impact Scope | Filtered Errors don't participate in Issue aggregation or alerting | Issue exists, just no alert notification |
153+
| Use Case | Long-term exclusion of noise data | Flexible alert control |
154+
</Accordion>
155+
<Accordion title="How do alert grading rules work with Flashduty Pipeline?">
156+
They complement each other, serving different dimensions:
157+
158+
- **RUM Alert Grading**: Based on individual Error attributes (user, page, environment, etc.), suitable for quick determination at the source
159+
- **Flashduty Pipeline**: Based on overall Issue information (affected user count, error count, etc.), suitable for more comprehensive assessment
160+
161+
We recommend setting base priority on the RUM side and making supplementary adjustments on the Flashduty side.
162+
</Accordion>
163+
<Accordion title="Will the default alert behavior change?">
164+
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.
165+
</Accordion>
166+
</AccordionGroup>
167+
168+
## Further Reading
169+
170+
<CardGroup cols={2}>
171+
<Card title="Issue Alerts" icon="bell" href="/en/rum/error-tracking/issue-alerts">
172+
Complete configuration guide for alert triggers, custom grading, and data filtering
173+
</Card>
174+
<Card title="Alert Pipeline" icon="filter" href="/en/on-call/integration/alert-integration/alert-pipelines">
175+
Clean, transform, and filter alerts at the integration layer
176+
</Card>
177+
<Card title="Noise Reduction" icon="volume-slash" href="/en/on-call/channel/noise-reduction">
178+
Aggregate and suppress alerts at the channel level
179+
</Card>
180+
<Card title="Escalation Rules" icon="route" href="/en/on-call/channel/escalation-rule">
181+
Configure escalation rules to route alerts to the right responders
182+
</Card>
183+
</CardGroup>

0 commit comments

Comments
 (0)