Merge pull request #37 from flashcatcloud/doc-review/2026-03-31-102639

docs: fix 30 documentation findings from cross-module audit

Author: ysyneu

en/developer/overview.mdx

@@ -36,7 +36,7 @@ Visit the [API documentation](https://developer-en.flashcat.cloud/en/flashduty/o
 
 ## MCP Server
 
-The Flashduty MCP Server implements the [Model Context Protocol](https://modelcontextprotocol.io/), providing AI tools with 16 tools across 6 functional modules:
+The Flashduty MCP Server implements the [Model Context Protocol](https://modelcontextprotocol.io/), providing AI tools with 18 tools across 6 functional modules:
 
 | Module | Tools | Capabilities |
 |--------|-------|-------------|

en/monitors/alert-rules/active-alerts.mdx

@@ -4,7 +4,7 @@ description: "View all currently firing alerts to quickly understand your system
 keywords: ["active alerts", "alert rule", "alert list", "severity", "labels"]
 ---
 
-The active alerts page provides a consolidated view of all currently firing alerts, helping you quickly understand the overall alert status of your system. You can filter and browse by severity, folder, alert rule, labels, and more.
+The active alerts page provides a consolidated view of all currently firing alerts, helping you quickly understand the overall alert status of your system. You can filter and browse by severity, title, labels, and more.
 
 <Note>
 The active alerts feature requires monit-edge version >= v0.36.0. Please ensure you have upgraded to this version or later. If you have not installed it yet, go to the [alert engine management](/en/monitors/engine/engine) page to complete the deployment.
@@ -20,18 +20,22 @@ The active alerts list displays currently firing alerts in a table format. Defau
 |--------|-------------|
 | **Severity** | The severity level of the alert: Critical, Warning, or Info |
 | **Title** | The title of the alert event |
-| **Alert rule** | The name of the alert rule that produced this alert |
-| **Labels** | Label information carried by the alert, such as job, instance, etc. |
-| **Last triggered** | The most recent time this alert was triggered |
+| **Job** | The job label value carried by the alert |
+| **Instance** | The instance label value carried by the alert |
+| **Last updated** | The most recent time this alert was updated |
+| **Hash** | The unique identifier hash of the alert |
+| **Extra labels** | Other additional label information carried by the alert |
 
 ## Filtering and searching
 
 The conditions bar at the top of the page helps you quickly locate the alerts you care about:
 
 - **Severity**: Filter by Critical, Warning, or Info
-- **Folder**: Filter by the folder that the alert rule belongs to
-- **Alert rule**: Filter by a specific alert rule
-- **Labels**: Filter by alert label key-value pairs
+- **Title**: Filter by the title of the alert event
+- **Hash**: Filter by the unique identifier hash of the alert
+- **Job**: Filter by the job label value
+- **Instance**: Filter by the instance label value
+- **Extra labels**: Filter by other additional labels
 
 All filter conditions use an "AND" relationship — only alerts matching all conditions are displayed.
 

en/monitors/faq/faq.mdx

@@ -29,7 +29,6 @@ The overview page provides a global view of alert rules, consisting of the follo
 |------|-------------|
 | **Alert rule total trend** | An area chart showing how the total number of alert rules changes over time. The x-axis represents dates and the y-axis represents rule count, helping you track overall growth or reduction trends |
 | **Alert rules by channel** | A pie chart showing the distribution of alert rules across channels. The top 10 channels are displayed by default; the remainder are aggregated as "Others." You can click to expand and view all details |
-| **Triggered rules by top-level group** | Shows the health status of alert rules by top-level group. Each group displays as a card with a "normal/total" ratio and progress bar. Green indicates all normal; red indicates rules currently triggered. Click a card to jump to that group's rule list |
 | **System event list** | Displays system events generated by the alert engine (such as engine disconnection, configuration anomalies, etc.), with pagination and delete support, helping you promptly discover and address infrastructure-level issues |
 
 <Tip>

en/monitors/quickstart/quickstart.mdx

@@ -95,6 +95,10 @@ If you need stable rule bindings that are unaffected by data source renames, pre
 
 Configure how to query data sources and how to evaluate alert conditions. Please read the usage instructions on the right side of **Query Detection Method** on the page.
 
+| Config Item | Description |
+|--------|------|
+| **Query Offset** | Sets the query time offset (in seconds) to handle data source ingestion lag. For example, setting it to 60 shifts the query window back by 60 seconds, ensuring data has been fully written before querying |
+
 ### Detection Frequency and Effective Time
 
 ![Detection frequency & effective time](https://docs-cdn.flashcat.cloud/imges/mon/0980d71a653985a1706243fc6795685e.png)

en/on-call/channel/escalation-rule.mdx

@@ -20,6 +20,8 @@ src="https://download.flashcat.cloud/flashduty/video/escalate-rule.mp4"
 
 An escalation rule contains four core elements. The system matches rules from top to bottom, **stopping after the first successful match**.
 
+You can enable or disable individual escalation rules. Disabled rules are skipped during matching and will not trigger notifications. You can also copy an escalation rule to the current channel or another channel to quickly reuse existing configurations.
+
 ### 1. Trigger Conditions
 
 Determines which incidents trigger the current rule.
@@ -88,8 +90,8 @@ In each escalation level, you can enable the **Loop Notification** feature. When
 
 **Escalation Conditions**:
 
-- **Timeout without acknowledgment**: No one acknowledges within N minutes after incident trigger
-- **Timeout without closure**: Incident not resolved within N minutes after trigger
+- **Not closed**: Incident not closed within N minutes after trigger
+- **Not closed and not acknowledged**: Incident neither closed nor acknowledged within N minutes after trigger
 
 The minimum escalation timeout is 1 minute.
 

en/on-call/channel/noise-reduction.mdx

@@ -104,7 +104,7 @@ Flashduty On-call provides two grouping modes:
 | **Aggregation Window** | Optional toggle. When disabled, new alerts continue merging into the incident until the incident is closed. When enabled, alerts within the window are merged; alerts arriving after the window expires are grouped into a new incident |
 | **Window Timing Start** | Only configurable when the aggregation window is enabled. **Incident trigger** (default): Fixed timer starts from incident creation, stops grouping when the window duration is reached. **Alert merges into incident**: Timer resets each time a new alert merges in, the window recalculates from the last merge |
 | **Window Duration** | Only configurable when the aggregation window is enabled. Set the duration of the aggregation window |
-| **Alert Storm Warning** | When merged alert count reaches the configured threshold, the system records an alert storm event in the incident timeline and triggers a warning notification, prompting urgent handling |
+| **Alert Storm Warning** | When merged alert count reaches a configured threshold, the system records an alert storm event in the incident timeline and triggers a warning notification, prompting urgent handling. You can configure up to 5 thresholds, each ranging from 2 to 10,000 |
 | **Strict Grouping** | When enabled, empty label values are treated as different; when disabled, empty values are treated as the same (not supported for intelligent grouping) |
 
 <Tabs>
@@ -234,6 +234,7 @@ Define which alerts should be silenced, supports multiple condition combinations
 | **Severity** | Match by alert level | Only silence `Info` level |
 | **Title** | Match by alert title keywords | Title contains "Planned Maintenance" |
 | **Description** | Match by alert description content | Description contains "restart" |
+| **Integration** | Match by alert integration source | Only silence alerts from a specific integration |
 | **Labels** | Match by label key-value pairs | `host=db-master-01` |
 
 **Combination Logic**:

en/on-call/incident/search-view-incident.mdx

@@ -137,7 +137,7 @@ The incident details page supports one-click AI summary generation to help you q
 - **Impacts**: Key affected resources such as services, systems, environments, and instances
 - **Actions**: Immediately actionable investigation and remediation steps (up to 3)
 
-You can choose from different AI models (default is DeepSeek V3) and regenerate as needed. The generated summary supports real-time streaming output and can be saved as the incident description.
+You can choose from different AI models (default is DeepSeek V3; DeepSeek R1 is also available for deep thinking and reasoning capabilities) and regenerate as needed. The generated summary supports real-time streaming output and can be saved as the incident description.
 
 <Tip>
 AI Summary is only available for incidents automatically triggered by alerts. Manually created incidents do not support this feature.

en/on-call/integration/alert-integration/alert-pipelines.mdx

@@ -114,6 +114,10 @@ Pipeline's inhibition feature is similar to channel inhibit rules, both supporti
 When an entire datacenter loses network, all alerts from that datacenter (regardless of business line) should be inhibited. Configuring one rule at the integration layer is much more efficient than configuring separately in dozens of channels.
 </Tip>
 
+<Note>
+Inhibition only matches source alerts that have been active within the last 10 minutes (600 seconds). If a source alert was triggered more than 10 minutes ago and has not been updated since, it will not be used for inhibition matching. Ensure your source alerts remain active within this time window.
+</Note>
+
 ## Reference Historical Data
 
 When editing alert processing rules, the right side of the page provides a **Related Alerts** panel showing historical alert data ingested through the current integration. You can write processing rules while referencing actual alert content, ensuring that condition expressions and action configurations meet expectations.

en/on-call/integration/instant-messaging/microsoft-teams.mdx

@@ -121,7 +121,20 @@ In the Chat, @Flashduty and send command `linkChat {ID} {ChatName}`, then click
 </Step>
 </Steps>
 
-## 4. Link User
+## 4. Notification Card Actions
+
+When incident notifications are pushed to Microsoft Teams, the notification cards support the following interactive actions, allowing you to respond to incidents directly in Teams without switching to the Flashduty console:
+
+- **Acknowledge**: Mark that you have started handling the incident
+- **Resolve**: Mark the incident as resolved and close it
+- **Snooze**: Temporarily suspend the incident and receive a reminder after a specified time
+- **Custom Actions**: Trigger your pre-configured custom actions (such as restarting services, rolling back changes, etc.)
+
+<Note>
+War room functionality is not currently supported for Microsoft Teams. If you need to use the war room feature, consider using Slack, Feishu/Lark, Dingtalk, or WeCom integration instead.
+</Note>
+
+## 5. Link User
 
 <Steps>
 <Step title="Find App">
@@ -147,7 +160,7 @@ Copy and send command `linkUser {}` to the chat, then click **Link Now**.
 </Step>
 </Steps>
 
-## 5. FAQ
+## 6. FAQ
 
 <AccordionGroup>
 <Accordion title="Team or individual not receiving messages?">

en/on-call/integration/instant-messaging/slack.mdx

@@ -33,21 +33,6 @@ After completing the previous steps, in the Flashduty On-call integration config
 To enable AI-generated post-mortem with war room chat history, the app requires additional `channels:history` permission. For existing Slack integrations, you need to manually re-authorize to grant this permission.
 </Note>
 
-## 3. FAQ
-<Warning>
-Only one IM integration can have War Room enabled at a time. If you've already enabled War Room in another IM integration (such as Dingtalk, Feishu/Lark, or WeCom), you need to disable it there first before enabling it in the current Slack integration.
-</Warning>
-
-### Permission verification and re-authorization
-
-When enabling War Room, the system automatically verifies whether the current Slack app has all the permissions required for War Room. If missing permissions are detected, a warning message appears on the page with a **Re-authorize** link.
-
-Click the **Re-authorize** link to be redirected to the Slack authorization page, which requests the additional permissions needed for War Room functionality (including channel management, message read/write, user info reading, etc.). After completing authorization, the page automatically returns to Flashduty, and you can then enable War Room normally.
-
-<Tip>
-If your Slack integration was authorized before the War Room feature was released, you will typically need to re-authorize on first use to add the new permissions. Re-authorization does not affect your existing integration configuration or user associations.
-</Tip>
-
 ## 3. Linked Users
 
 In the **Linked Users** tab of the integration detail page, you can view the linking status between team members and Slack accounts, and quickly complete batch linking.
@@ -75,6 +60,13 @@ The system can only push Slack message notifications after members complete link
 ## 4. FAQ
 
 <AccordionGroup>
+<Accordion title="War Room considerations?">
+- Only one IM integration can have War Room enabled at a time. If you have already enabled War Room in another IM integration (such as Dingtalk, Feishu/Lark, or WeCom), you need to disable it there first before enabling it in the current Slack integration
+- When enabling War Room, the system automatically verifies whether the current Slack app has all required permissions. If missing permissions are detected, a warning message appears on the page with a **Re-authorize** link
+- Click the **Re-authorize** link to be redirected to the Slack authorization page, which requests additional permissions needed for War Room functionality (including channel management, message read/write, user info reading, etc.). After completing authorization, the page automatically returns to Flashduty
+- If your Slack integration was authorized before the War Room feature was released, you will typically need to re-authorize on first use to add the new permissions. Re-authorization does not affect your existing integration configuration or user associations
+</Accordion>
+
 <Accordion title="Escalation rule group chat list doesn't have the desired private channel?">
 - Ensure the [**Install App**](#install-app) step completed successfully without errors
 - Go to the relevant Slack channel, execute `/invite @Flashduty` command