ysyneu · Oct 22, 2026 · Oct 22, 2026 · Oct 22, 2026
diff --git a/docs.json b/docs.json
@@ -3010,6 +3010,14 @@
     {
       "source": "/webhook/history/list",
       "destination": "/zh/api-reference/on-call/integrations/webhook-history-list"
+    },
+    {
+      "source": "/zh/rum/error-tracking/erro-reporting/web",
+      "destination": "/zh/rum/error-tracking/error-reporting/web"
+    },
+    {
+      "source": "/en/rum/error-tracking/erro-reporting/web",
+      "destination": "/en/rum/error-tracking/error-reporting/web"
     }
   ],
   "navigation": {

diff --git a/en/monitors/alert-rules/investigation-entries.mdx b/en/monitors/alert-rules/investigation-entries.mdx
@@ -27,7 +27,7 @@ A rule can hold many investigation entries. Each entry has three parts: the entr
 | Entry type | Button | Jumps to | Notes |
 |---------|------|--------|------|
 | **Dashboard entry** | Add dashboard entry | The dashboard viewer | Can target the whole dashboard, a tab, a section or a panel, and sets the values of that dashboard's template variables |
-| **Query entry** | Add query entry | The Query Workbench | Stores one editable initial query (query type + query + query parameters) and optionally the data source it runs on |
+| **Query entry** | Add query entry | The Query Workbench | Stores one editable initial query (query type + query + minimum step + query parameters) and optionally the data source it runs on |
 
 Neither type supports runbooks, tickets or arbitrary URLs.
 
@@ -83,7 +83,8 @@ Time range semantics:
 | **Data source** | Defaults to `Alert event datasource` (the query is written against the rule's data source type); you can also pick a specific data source. When the rule's data source type is not queryable in the workbench, the `Alert event datasource` option is disabled and labelled `Alert event datasource (not supported for this rule type)`, so the entry must name a data source explicitly. **Changing the data source resets the query**, because the query language changed |
 | **Query type** | Only shown for data sources with more than one query type (Prometheus: Graph only / Raw only; Loki: Range / Instant; VictoriaLogs: Raw logs / Instant stats / Range stats). Prometheus "Graph + Raw" is not offered here because it is two executions and cannot be stored as one query. SQL-type data sources, SLS and Tencent CLS each have a single query mode and therefore no such row |
 | **Initial query** | The query editor, with the same syntax and completion as the Query Workbench. The whole expression is rendered as a Go template and inserted **verbatim — no automatic quoting or escaping** |
-| **Query parameters** | The data source's named parameters, per data source type (Limit, Direction, Min step (s), the SLS project / logstore, the Tencent CLS region / topic / syntax). Parameter values are **not templated**; a `{{` is rejected (`query args do not support templates`) |
+| **Minimum step** | Only for Prometheus / Loki when **Query type** is a range query; in seconds, minimum 1. It is the lower bound on the query step: the backend still derives the step from `max_data_points` but never goes below this value. Leave it empty for no lower bound |
+| **Query parameters** | The data source's named parameters, per data source type (Limit, Direction, the SLS project / logstore, the Tencent CLS region / topic / syntax). Parameter values are **not templated**; a `{{` is rejected (`query args do not support templates`) |
 
 With the event data source selected, a rule type that the workbench does not support shows `Choose a datasource type under "Datasource and query" first, or pick a datasource for this entry`; an explicitly selected data source that was deleted or that you cannot use shows `The selected datasource is unavailable`. The data source's real type, permissions and provider-specific restrictions are re-checked by the workbench as the current user when the entry is opened or run.
 

diff --git a/en/monitors/alert-rules/sls.mdx b/en/monitors/alert-rules/sls.mdx
@@ -70,7 +70,14 @@ See [Alert recovery](/en/monitors/quickstart/quickstart#alert-recovery) for the
 
 This mode is used to monitor scenarios where "data is expected but actually missing".
 
-SLS does not support per-series no-data detection. Only "**Alert when all queries return no data**" is available; "Alert if previously found data is now missing" is not supported.
+SLS offers two no-data conditions; enable either one, or both as you need:
+
+| Condition | Fires when | Recovery |
+|------|----------|----------|
+| **Alert if previously found data is now missing** | Evaluated per series: that series returned data before and is missing now | Choose **Close automatically when data reappears**, **Close automatically after data recovers or the timeout elapses** (fill in **Auto-close time**, in seconds, minimum 1), or **Manual close only** |
+| **Alert when all queries return no data** | All queries return empty results for N consecutive checks, where N comes from the **Trigger condition** shared by the tab | Fixed to **recover automatically once any query returns data again**; not configurable |
+
+Among log-service data sources only Tencent Cloud CLS lacks the per-series condition; see [Tencent Cloud CLS](/en/monitors/alert-rules/tencent-cls).
 
 ### Configuration
 
@@ -79,16 +86,7 @@ SLS does not support per-series no-data detection. Only "**Alert when all querie
      ```sql
      * | SELECT host, max(__time__) as last_seen GROUP BY host
      ```
-2. **Evaluation Rules**: The alert fires when all queries return empty results for N consecutive checks. N comes from the **Trigger condition** shared by the tab.
-
-### Existing rules with per-series detection enabled
-
-If an existing SLS rule has per-series no-data detection enabled, opening its edit page turns that condition off automatically; the change takes effect when you save. The rule does not change unless you open the edit page.
-
-- If the rule has other enabled conditions (threshold evaluation, data exists), you can save directly.
-- If this was its only condition, enable at least one condition before saving.
-
-Switch to "Alert when all queries return no data" and make sure at least one condition is enabled before saving.
+2. **Evaluation Rules**: Enable a condition from the table above. With "Alert when all queries return no data", N comes from the **Trigger condition** shared by the tab; with "Alert if previously found data is now missing", each series is evaluated on its own and you can also set the recovery mode from the table.
 
 ### Recovery logic
 

diff --git a/en/monitors/folders/folders.mdx b/en/monitors/folders/folders.mdx
@@ -35,6 +35,7 @@ You can move alert rules to a different folder. The rules themselves do not chan
 
 - **One rule**: choose **Move** in the `⋮` menu at the end of its row.
 - **Several rules**: select them, then click **Move** above the list.
+- **On the rule's edit page**: **Group** in block 1 is a dropdown; pick the target group and save to move the rule there.
 
 Both open the **Move to another folder** dialog:
 

diff --git a/en/monitors/quickstart/quickstart.mdx b/en/monitors/quickstart/quickstart.mdx
@@ -70,7 +70,7 @@ The create / edit alert rule page is one form with six sections, from top to bot
 
 | Config Item | Description |
 |--------|------|
-| **Group** | The group path of the rule (for example, "Default / Database Alerts"). If the group has been deleted or you cannot access it, go back to the rule list and pick a group again |
+| **Group** | The group path of the rule (for example, "Default / Database Alerts"). When you edit an existing rule this row is a dropdown listing, by full path, the groups you can write to: pick one and save to move the rule there. If the group has been deleted or you cannot access it, the row is not editable — go back to the rule list and pick a group again |
 | **Rule Name** | Name of the alert rule; does not support variable references (fixed names facilitate filtering and grouping operations). It must be unique within its group; imports, edits, and moves fail if the target group already contains that name |
 | **Additional Labels** | Similar to `labels` in Prometheus; attached to all alert events for filtering, routing, and inhibition. See below for value syntax |
 
@@ -214,15 +214,15 @@ The repeat notification maximum count and interval, and the match and recovery c
 
 ### Event configuration
 
-Event Configuration covers **Custom Fields & Related Queries** (collapsed by default), the notes description, and repeat notification settings.
+Event configuration runs from the channel through the notes description and repeat notification settings to two flat subsections, custom fields and related queries.
 
 | Config Item | Description |
 |--------|------|
-| **Custom Fields** | Similar to `annotations` in Prometheus; can attach dashboard URLs, SOP URLs, and so on |
-| **Related Query** | Not used for threshold evaluation, but can be included in notes as variable references (for example, attach log samples) |
-| **Notes Description** | Unstructured text field; supports variable references to help responders quickly locate issues |
 | **Channel** | Specify a channel in Flashduty On-call; if not specified, delivery follows integration routing rules |
+| **Notes Description** | Unstructured text field; supports variable references to help responders quickly locate issues |
 | **Repeat Notification** | Continues notifying when alert is not recovered; configurable interval and maximum count (default 10000) |
+| **Custom Fields** | Similar to `annotations` in Prometheus; can attach dashboard URLs, SOP URLs, and so on. Click `+` next to the heading and fill in **Field name** and **Field value** in the dialog; the fields you add are listed as `key=value` tags — click a tag to edit it, click the × on it to delete it, and a field name cannot be empty or repeated |
+| **Related Query** | A separate subsection with its own add button; the result is not used for threshold evaluation, but can be referenced as a variable in the notes (for example, attach log samples) |
 
 <Note>
 The maximum notification count does not represent the number of message reminders end users receive. Because alert events generated by Monitors are delivered to On-call, they may be grouped and noise-reduced; the final send count depends on On-call configuration.

diff --git a/en/on-call/incident/search-view-incident.mdx b/en/on-call/incident/search-view-incident.mdx
@@ -172,7 +172,7 @@ Each entry is one row showing the entry-type icon (query or dashboard), the **pu
 - Hovering an entry opens a detail card with the full query expression (copyable), the named **variables** (filled in from the alert's labels; unresolved ones are highlighted in red), and the **time range** — the relative window on one line (for example "60 min before → 10 min after the alert") and the absolute start and end on the next. An **Open** button at the bottom opens the corresponding view in the Query Workbench or dashboard in a new tab
 - The number next to the heading is how many entries the snapshot holds; the **N with issues** badge counts the entries that render with a problem (query failed to render, dashboard variable unresolved, data source or dashboard deleted or unauthorized)
 - Only the first **3** entries show by default; the rest sit behind **N more**, which expands and collapses
-- Below the entries are the **Related alert rule** card (rule name plus data source, clickable through to the rule) and the rule's **Queries**: main queries are listed by `A` / `B` with the **value at trigger time**, hover for the full expression with a copy button, and a no-data alert is marked **No data** on the matching main query; related queries show the **result table at trigger time**
+- Below the entries are the **Related alert rule** card (rule name plus data source, clickable through to the rule) and the rule's **Queries**: main queries are listed by `A` / `B` with the **value at trigger time**, hover for the full expression with a copy button, and a no-data alert is marked **No data** on the matching main query; related queries show the **result at trigger time**: a result table for statistical queries, and for a VictoriaLogs / Loki related query whose query mode is **Raw** one log line per row with its fields laid out as `k=v` and the fields that do not fit collapsed into **+N fields**; the hover card shows at most 3 rows, and **View full data** next to its heading opens the query workbench with everything
 
 When the rule has no investigation entries configured, the block says "No investigation entries configured on the rule" and offers a **Configure** link. Other cases where entries cannot be shown:
 

diff --git a/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx b/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx
@@ -1,29 +1,29 @@
 ---
 title: "Chronosphere alert integration"
 sidebarTitle: "Chronosphere"
-description: "Receive Chronosphere alerts through Chronosphere's webhook notifier using a Flashduty Prometheus integration; with resolved notifications on, alerts close automatically."
+description: "Receive Chronosphere alerts through Chronosphere's webhook notifier using a Flashduty Prometheus Alertmanager integration; with resolved notifications on, alerts close automatically."
 keywords: ["alert integration", "Chronosphere", "webhook", "Prometheus", "Alertmanager", "observability"]
 ---
 
-Chronosphere's webhook notifier sends an HTTP POST to the URL you enter. The body is Prometheus Alertmanager JSON (`version` is `4`, with `status`, `alerts`, `fingerprint`, `labels`, `annotations`, `startsAt`, `endsAt`, plus an extra `notifier` field). The Flashduty [Prometheus integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate Chronosphere integration is needed: create a Prometheus integration in Flashduty and paste its push URL into Chronosphere.
+Chronosphere's webhook notifier sends an HTTP POST to the URL you enter. The body is Prometheus Alertmanager JSON (`version` is `4`, with `status`, `alerts`, `fingerprint`, `labels`, `annotations`, `startsAt`, `endsAt`, plus an extra `notifier` field). The Flashduty [Prometheus Alertmanager integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate Chronosphere integration is needed: create a Prometheus Alertmanager integration in Flashduty and paste its push URL into Chronosphere.
 
 <div className="hide">
 
 ## In Flashduty On-call
 
-Get an integration push URL in either of the two ways below. **Choose the Prometheus integration type** in both, not Chronosphere.
+Get an integration push URL in either of the two ways below. **Choose the Prometheus Alertmanager integration type** in both, not Chronosphere.
 
 ### Use a dedicated integration
 
 1. In the Flashduty console, go to **Channels** and open a channel
 2. Go to **Settings** → **Integrations** → **Dedicated integrations** and click **Add an integration**
-3. Select **Prometheus** and click **Save**
+3. Select **Prometheus Alertmanager** and click **Save**
 4. Open the generated integration card and copy the **Push URL**, in the form `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=<integration key>`
 
 ### Use a shared integration
 
 1. In the Flashduty console, go to **Integration Center → Alert Events**
-2. Select **Prometheus** and enter an integration name
+2. Select **Prometheus Alertmanager** and enter an integration name
 3. Configure the default route and select a channel. You can add more rules under **Routing** after creation
 4. Click **Save** and copy the generated **Push URL**
 
@@ -81,6 +81,6 @@ One notification can carry several alerts, and Flashduty handles each one separa
 
 ## Troubleshooting
 
-- **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not Prometheus
+- **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not Prometheus Alertmanager
 - **Alerts do not recover**: confirm the notifier has **Notify when resolved** selected (`send_resolved` is `true` in Terraform, `skip_resolved` is `false` in Chronoctl) and that the resolved notification's `fingerprint` matches the trigger
 - **No alerts arrive**: confirm a notification policy routes the relevant severities to this notifier, and that Chronosphere can reach `api.flashcat.cloud`
diff --git a/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx b/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx
@@ -1,29 +1,29 @@
 ---
 title: "CubeAPM alert integration"
 sidebarTitle: "CubeAPM"
-description: "Receive CubeAPM alerts through CubeAPM's webhook receiver using a Flashduty Prometheus integration; alerts close automatically when they resolve."
+description: "Receive CubeAPM alerts through CubeAPM's webhook receiver using a Flashduty Prometheus Alertmanager integration; alerts close automatically when they resolve."
 keywords: ["alert integration", "CubeAPM", "webhook", "Prometheus", "Alertmanager", "observability"]
 ---
 
-CubeAPM can send alert notifications by HTTP POST to any webhook URL. The default JSON body is compatible with the Prometheus Alertmanager webhook format (`receiver`, `status`, `alerts`, `groupLabels`, `commonLabels`, `commonAnnotations`, `externalURL`, and so on; each alert carries `status`, `labels`, `annotations`, `startsAt`, `endsAt`, `generatorURL`, `fingerprint`, plus CubeAPM's own `cubeImageURL` and `cubeSampleLog`). The Flashduty [Prometheus integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate CubeAPM integration is needed: create a Prometheus integration in Flashduty and paste its push URL into CubeAPM.
+CubeAPM can send alert notifications by HTTP POST to any webhook URL. The default JSON body is compatible with the Prometheus Alertmanager webhook format (`receiver`, `status`, `alerts`, `groupLabels`, `commonLabels`, `commonAnnotations`, `externalURL`, and so on; each alert carries `status`, `labels`, `annotations`, `startsAt`, `endsAt`, `generatorURL`, `fingerprint`, plus CubeAPM's own `cubeImageURL` and `cubeSampleLog`). The Flashduty [Prometheus Alertmanager integration](/en/on-call/integration/alert-integration/alert-sources/prometheus) accepts this format, so no separate CubeAPM integration is needed: create a Prometheus Alertmanager integration in Flashduty and paste its push URL into CubeAPM.
 
 <div className="hide">
 
 ## In Flashduty On-call
 
-Get an integration push URL in either of the two ways below. **Choose the Prometheus integration type** in both, not CubeAPM.
+Get an integration push URL in either of the two ways below. **Choose the Prometheus Alertmanager integration type** in both, not CubeAPM.
 
 ### Use a dedicated integration
 
 1. In the Flashduty console, go to **Channels** and open a channel
 2. Go to **Settings** → **Integrations** → **Dedicated integrations** and click **Add an integration**
-3. Select **Prometheus** and click **Save**
+3. Select **Prometheus Alertmanager** and click **Save**
 4. Open the generated integration card and copy the **Push URL**, in the form `https://api.flashcat.cloud/event/push/alert/prometheus?integration_key=<integration key>`
 
 ### Use a shared integration
 
 1. In the Flashduty console, go to **Integration Center → Alert Events**
-2. Select **Prometheus** and enter an integration name
+2. Select **Prometheus Alertmanager** and enter an integration name
 3. Configure the default route and select a channel. You can add more rules under **Routing** after creation
 4. Click **Save** and copy the generated **Push URL**
 
@@ -69,6 +69,6 @@ One notification can carry several alerts, and Flashduty handles each one separa
 
 ## Troubleshooting
 
-- **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not Prometheus
+- **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not Prometheus Alertmanager
 - **Alerts do not resolve**: confirm that every alert in a customized Payload has `status` and `fingerprint`, and that the recovery notification carries the same `fingerprint` as the trigger
 - **No alerts arrive**: confirm CubeAPM can reach `api.flashcat.cloud` and that the alert rule uses this webhook receiver