docs: comprehensive coverage audit fixes across all modules

docs.json

@@ -218,7 +218,9 @@
                       "zh/on-call/integration/instant-messaging/wecom",
                       "zh/on-call/integration/instant-messaging/dingtalk",
                       "zh/on-call/integration/instant-messaging/slack",
-                      "zh/on-call/integration/instant-messaging/microsoft-teams"
+                      "zh/on-call/integration/instant-messaging/microsoft-teams",
+                      "zh/on-call/integration/instant-messaging/telegram",
+                      "zh/on-call/integration/instant-messaging/zoom"
                     ]
                   },
                   {
@@ -622,7 +624,9 @@
                       "en/on-call/integration/instant-messaging/wecom",
                       "en/on-call/integration/instant-messaging/dingtalk",
                       "en/on-call/integration/instant-messaging/slack",
-                      "en/on-call/integration/instant-messaging/microsoft-teams"
+                      "en/on-call/integration/instant-messaging/microsoft-teams",
+                      "en/on-call/integration/instant-messaging/telegram",
+                      "en/on-call/integration/instant-messaging/zoom"
                     ]
                   },
                   {

en/monitors/engine/engine.mdx

@@ -75,6 +75,13 @@ API Keys are used for authentication between the alert engine and the SaaS. You
 | **Rename** | Click the Key name to edit and rename it |
 | **Delete** | Delete unused API Keys; requires the API Key delete permission |
 
+The management panel also displays the current status of each API Key:
+
+| Status | Description |
+|--------|-------------|
+| **Enabled** (green icon) | The API Key is active; engine instances can use it to communicate with the SaaS |
+| **Disabled** (yellow icon) | The API Key has been disabled; engine instances using it will be unable to communicate with the SaaS |
+
 <Warning>
 After deleting an API Key, all engine instances using that Key will be unable to communicate with the SaaS. Ensure you have switched related engines to another valid API Key before deletion.
 </Warning>

en/monitors/faq/faq.mdx

@@ -23,11 +23,18 @@ On the alert rules list page, there is a **Debug Log Switch** that you can enabl
 <Accordion title="What information does the overview dashboard display?">
 **Menu Entry**: Overview
 
-The overview page provides a global view of alert rules, including:
-
-- **Rule Statistics**: Displays the total number of alert rules and the distribution across statuses
-- **Channel Distribution**: Shows the number of associated alert rules per channel
-- **Problem List**: Displays currently triggered alert events, helping you quickly identify active issues
+The overview page provides a global view of alert rules, consisting of the following cards:
+
+| Card | Description |
+|------|-------------|
+| **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>
+The overview page checks whether you have installed an alert engine. If not, a prompt guides you to the alert engine page to complete installation.
+</Tip>
 </Accordion>
 
 <Accordion title="How do I quickly clone an alert rule?">

en/on-call/channel/create-edit.mdx

@@ -51,6 +51,9 @@ Proper planning can significantly improve operational efficiency.
     - **Auto-close after incident trigger**: Timer starts from when the incident is first triggered, suitable for alerts without automatic recovery
     - **Auto-close after alerts stop merging**: Timer starts from the last alert merge, suitable for scenarios with alert grouping enabled
   </Step>
+  <Step title="Configure Close with Alerts (Optional)">
+    Enabled by default. When enabled, incidents automatically close when all associated alerts recover. When disabled, alert recovery does not auto-close the incident — you need to close it manually or rely on the auto-close timeout policy.
+  </Step>
   <Step title="Enable Outlier Incident Detection (Optional)">
     When enabled, incident lists and notification content will include an "Outlier Incident" indicator for quick identification. [Learn more](/en/on-call/incident/outlier-incidents)
   </Step>
@@ -128,6 +131,7 @@ Go to Channel Details → **Basic Settings** to modify:
 - Channel name, description
 - Management team
 - Auto-close timeout policy
+- Close with alerts toggle
 
 ### Disabling and Deleting
 

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

@@ -69,7 +69,7 @@ Determines how users are reached.
   <Tab title="Group Chat (Reach Groups)">
     Send to instant messaging groups, with support for @ mentioning relevant personnel.
 
-    - **IM App Groups**: Supports Feishu/Lark, Dingtalk, WeCom groups, requires completing [IM Integration](/en/on-call/integration/instant-messaging/lark) first
+    - **IM App Groups**: Supports Feishu/Lark, Dingtalk, WeCom, Slack, and Microsoft Teams groups, requires completing [IM Integration](/en/on-call/integration/instant-messaging/lark) first
     - **Group Bots**: Supports Feishu/Lark, Dingtalk, WeCom, Telegram, Zoom, and other Webhook bots. Telegram requires configuring a Webhook notification address and Chat IDs, Zoom requires configuring a Webhook address and Verify Token, and supports enabling @ mention functionality. See [Notification Channel Configuration](/en/on-call/configuration/notifications)
   </Tab>
 </Tabs>

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

@@ -100,6 +100,7 @@ Flashduty On-call provides two grouping modes:
 | Configuration | Description |
 | :------- | :----------------------------------- |
 | **Grouping Window** | Only group alerts within the time window, alerts outside the window trigger new incidents |
+| **Window Type** | **Tumbling** (default): Fixed timer starts from incident creation, stops grouping when the window duration is reached. **Sliding**: Timer resets each time a new alert merges in, the window recalculates from the last merge |
 | **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 |
 | **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) |
 
@@ -178,10 +179,22 @@ Go to Channel Details → Noise Reduction → **Flapping Detection**:
 
 | Option | Behavior |
 | :-------- | :--------------- |
-| **Off** | Don't detect flapping status (default) |
+| **Off** | Don't detect flapping status |
 | **Alert Only** | Mark flapping status, continue notifications per policy |
 | **Alert Then Silence** | Mark flapping status, no more notifications after first alert |
 
+<Note>
+  Flapping detection is enabled by default for new channels (Alert Only mode).
+</Note>
+
+### Configurable Parameters
+
+| Parameter | Description | Default | Range |
+| :--- | :--- | :--- | :--- |
+| **State changes** (max_changes) | Number of alert state changes within the observation window to trigger flapping detection | 4 | 2–100 |
+| **Observation window** (in_mins) | Time window for counting state changes | 60 minutes | 1–1440 minutes |
+| **Mute duration** (mute_mins) | Duration to mute notifications after flapping is detected (only applies in "Alert Then Silence" mode) | 120 minutes | 0–1440 minutes |
+
 <Tip>
   "Same incident" refers to incidents with the same Alert Key, typically using the alert ID pushed from the upstream system as a unique identifier.
 </Tip>
@@ -314,8 +327,8 @@ When a new alert meets conditions, and there's an **active incident** (not close
     Up to 5000, mainly to ensure console rendering performance. Due to backend concurrent processing, actual count may slightly exceed this limit.
   </Accordion>
   <Accordion title="What's the maximum number of events a single alert can be associated with?" icon="circle-question">
-    - **Rule-based Grouping**: No limit, maximum grouping window is 24 hours. After 24 hours from alert trigger, new events create new incidents
-    - **Intelligent Grouping**: No limit, maximum grouping window is 30 days. After 30 days from alert trigger, new events create new incidents
+    - **Rule-based Grouping**: No limit, default maximum grouping window is 24 hours. After 24 hours from alert trigger, new events create new incidents
+    - **Intelligent Grouping**: No limit, default maximum grouping window is 24 hours, with certain subscription plans supporting extension up to 30 days. After exceeding the window, new events create new incidents
   </Accordion>
 </AccordionGroup>
 

en/on-call/configuration/personal-settings.mdx

@@ -73,12 +73,39 @@ APP Keys are used for API request authentication.
 
 ---
 
+### Download the app
+
 | Platform | Download Method |
 | --- | --- |
 | **iOS** | Search "Flashduty" in App Store |
-| **Android** | Download from major app stores (Harmony OS not currently supported) |
+| **Android** | Available on major app stores including Xiaomi, Huawei, Honor, OPPO, and vivo — search "Flashduty" to download (Harmony OS not currently supported) |
+
+If your phone brand is not listed above, you can click **Download here** on the APP management page to get an installation package QR code. Scan it with your phone to download.
+
+### Device binding
+
+After installing the app, you need to bind your mobile device to your Flashduty account to receive push notifications.
+
+<Steps>
+<Step title="Go to APP management page">
+Navigate to **Personal Center → Flashduty APP**.
+</Step>
+<Step title="Scan QR code to bind device">
+The page displays a QR code. Open the Flashduty APP, tap the "Scan to Login" button, and scan the QR code on the page to complete device binding.
+</Step>
+</Steps>
+
+Once bound, the page displays a list of linked devices, including device name, OS version, and device identifier. To unbind a device, hover over the device card and click the **Unbind** button.
+
+<Note>
+- Binding a device does not automatically enable notifications — the actual notification method depends on your escalation rule settings
+- After unbinding a device, it will no longer receive push notifications
+- The QR code has an expiration time; the page automatically refreshes to generate a new QR code when it expires
+</Note>
+
+### Push notifications
 
-After downloading, select a login method to complete account linking. We recommend enabling system notification permissions and allowing urgent incident notifications in Do Not Disturb mode.
+The Flashduty APP supports free push notifications for alerts, ensuring critical alerts reach you instantly. You can acknowledge, resolve, and escalate alerts anytime, anywhere from your mobile device. We recommend enabling system notification permissions and allowing urgent incident notifications in Do Not Disturb mode to avoid missing important alerts.
 
 ## FAQ
 

en/on-call/incident/handle-update-incident.mdx

@@ -95,7 +95,11 @@ You can view each person's assignment time and acknowledgment time in the consol
 
 ## Snooze
 
-After acknowledging an incident, responders may need time to investigate and handle it. **Snooze** can temporarily stop the incident from escalating per the expected escalation rule. After acknowledging, you can set a snooze duration such as 2 hours, 4 hours, 12 hours, or a custom expiration time within 24 hours.
+After acknowledging an incident, responders may need time to investigate and handle it. **Snooze** can temporarily stop the incident from escalating per the expected escalation rule. After acknowledging, you can choose from preset durations (default: 2 hours, 4 hours, 12 hours) or set a custom expiration time within 24 hours.
+
+<Tip>
+Account administrators can customize the 3 snooze preset durations in **Account Settings** (in minutes, each value must be greater than 0 and no more than 24 hours). Changes take effect for all members.
+</Tip>
 
 <Warning>
 If you've snoozed and the snooze time has passed but you still haven't resolved the incident, the system automatically reverts the incident to **Triggered** status and re-initiates assignment notifications.

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

@@ -78,7 +78,7 @@ Incident details is the main entry point for investigating incidents, displaying
 | :---: | :--- | :--- |
 | 1 | Key Information | Incident title, severity, processing progress, ID number |
 | 2 | Action Area | Various high-frequency action buttons; more actions include custom actions and low-frequency buttons; War Room creation requires enabling [War Room](/en/on-call/advanced/war-room) in IM integration |
-| 3 | Details | Incident description, label info; AI Summary can quickly extract incident details and output in three dimensions: event overview, impact scope, and actionable measures; labels support drag-to-sort and JSON view display |
+| 3 | Details | Incident description, label info, and AI Summary (see below for details); labels support drag-to-sort and JSON view display |
 | 4 | Associated Alerts | All [grouped](/en/on-call/channel/noise-reduction) alerts associated with the incident, supports filtering by progress and view switching |
 | 5 | Comprehensive Info | Shows incident attributes, processing status, [images](https://developer.flashcat.cloud/api-344943718), and responder info |
 | 6 | Custom Fields | Custom field configuration area |
@@ -104,10 +104,28 @@ The change event list displays the following information:
 
 You can adjust the query scope through the filter at the top, including time range and change source. Expand any row to view a timeline visualization of that change event, allowing comparison with the incident trigger time.
 
+### AI Summary
+
+The incident details page supports one-click AI summary generation to help you quickly understand the full picture of an incident. Click the **AI Summary** button in the details area, and the system will automatically generate a structured summary based on the incident's associated alerts (up to 20), including:
+
+- **Summary**: A one-sentence description of what happened
+- **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.
+
+<Tip>
+AI Summary is only available for incidents automatically triggered by alerts. Manually created incidents do not support this feature.
+</Tip>
+
 ### Images
 
 When alerts associated with the incident include image information reported via API, the incident details right panel displays an **Images** section. You can click image thumbnails to preview them, and hover to view the Alt description and source links.
 
+### Linked External Tickets
+
+If you have configured ticket integrations such as Jira, ServiceNow, or ServiceDesk Plus, the comprehensive info area in the incident details right panel displays linked external ticket information. You can click directly to navigate to the corresponding external ticket system and view details.
+
 ## FAQ
 
 <AccordionGroup>

en/on-call/incident/what-is-incident.mdx

@@ -123,7 +123,7 @@ Flashduty On-call supports dedicated and shared integration modes:
 Flashduty On-call provides a custom event standard, allowing you to report alerts via standard protocol, suitable for any non-integrated monitoring system. For details, read [Custom Alert Events](https://developer.flashcat.cloud/api-110655782).
 
 <Warning>
-To ensure system stability, Flashduty On-call has a **200qps** rate limit for API reporting. Exceeding this limit will reject reports.
+To ensure system stability, Flashduty On-call enforces rate limits per integration (**100 requests/second**, **1000 requests/minute**). Exceeding these limits returns a `429` status code — please wait and retry. See [Integrate Data - Rate Limits](/en/on-call/channel/integrate-data#rate-limits) for details.
 </Warning>
 
 <Warning>

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

@@ -16,9 +16,25 @@ description: "Cleanse, format, and preprocess data at the alert ingestion source
 
 */}
 
+## Processing Order
+
+After an alert event enters Flashduty, it passes through three stages in sequence:
+
+| Stage | Description |
+| :--- | :--- |
+| **① Label Enhancement (Enrich)** | Dynamically generate or modify alert labels, such as querying CMDB via API to supplement business information |
+| **② Alert Processing (Pipeline)** | Cleanse, transform, and filter alert data (the feature described in this document) |
+| **③ Route Distribution (Route)** | Distribute events to corresponding channels based on alert attributes |
+
+Since label enhancement runs before Pipeline, Pipeline match conditions **can reference labels added or modified during the enrichment stage**.
+
+<Note>
+Recovery events (event_status is Ok) bypass the alert processing Pipeline entirely and go directly into the alert merge flow. Therefore, discard, inhibition, rewrite, and other rules configured in Pipeline do not apply to recovery events.
+</Note>
+
 ## How It Works
 
-Pipeline sits between **Alert Ingestion** and **Route Distribution**. Its execution logic is as follows:
+Pipeline sits between **Label Enhancement** and **Route Distribution**. Its execution logic is as follows:
 
 1. **Chain Processing**: You can configure multiple processing rules that execute sequentially **from top to bottom**
 2. **Input/Output**: The result of a previous rule (e.g., modified title) can serve as input for the next rule
@@ -85,12 +101,14 @@ Discard directly before data storage, leaving no records. This is similar to "Ex
 
 ### Alert Inhibition
 
-Pipeline's inhibition feature is **exactly the same** as channel inhibition rules, both supporting dependency-based inhibition based on source incident, target incident, and correlation conditions.
+Pipeline's inhibition feature is similar to channel inhibit rules, both supporting dependency-based inhibition based on source alert, target alert, and correlation conditions. Note that Pipeline inhibition only matches source alerts **within the same integration**, while channel inhibition matches across all alerts in the channel.
 
 | Comparison | Pipeline Inhibition | Channel Inhibition |
 | :--- | :--- | :--- |
 | Effective Layer | Integration layer | Channel layer |
-| Use Case | **Global** inhibition logic, like inhibiting all alerts from a datacenter after network outage | Inhibition rules for specific channels |
+| Match Scope | Only matches active alerts within the same integration | Matches all active alerts within the channel |
+| Use Case | **Global** inhibition logic, like inhibiting all alerts from a datacenter after network outage | Inhibit rules for specific channels |
+| Plan Requirement | Requires Standard plan or above | Requires Standard plan or above |
 
 <Tip>
 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.