docs: doc-review 2026-10-14 — investigation entries, alert-aggregation rework, label panel, dashboard and RUM drift

docs.json

@@ -3855,7 +3855,8 @@
                   "zh/monitors/alert-rules/tencent-cls",
                   "zh/monitors/alert-rules/victorialogs",
                   "zh/monitors/alert-rules/query-result-fields",
-                  "zh/monitors/alert-rules/description-template"
+                  "zh/monitors/alert-rules/description-template",
+                  "zh/monitors/alert-rules/investigation-entries"
                 ]
               },
               {
@@ -5605,7 +5606,8 @@
                   "en/monitors/alert-rules/tencent-cls",
                   "en/monitors/alert-rules/victorialogs",
                   "en/monitors/alert-rules/query-result-fields",
-                  "en/monitors/alert-rules/description-template"
+                  "en/monitors/alert-rules/description-template",
+                  "en/monitors/alert-rules/investigation-entries"
                 ]
               },
               {

en/ai-sre/im.mdx

@@ -76,13 +76,13 @@ Once the bot has your message, it first puts an emoji reaction on **the message
 
 | Platform | Emoji pool (one picked at random) |
 | --- | --- |
-| Slack | eyes, thinking_face, hourglass_flowing_sand, mag, zap |
-| Lark / Feishu | Typing, THINKING, Get, OnIt |
-| DingTalk | Platform built-in emotions: 思考, 收到, Get |
+| Slack | eyes, hourglass_flowing_sand |
+| Lark / Feishu | Typing, OneSecond |
+| DingTalk | Platform built-in emotions: 专注, 忙疯了 |
 
 On Slack this sits alongside a native "is working on it" status, which the bot also shows.
 
-The reaction is removed once the answer is delivered. A single failed removal, such as a platform hiccup or rate limit, doesn't leave the emoji on the message forever. The next successful delivery retries the removal with **the exact emoji that was added**, so stuck receipts eventually clear.
+The reaction is removed once the answer is delivered. A single failed removal, such as a platform hiccup or rate limit, doesn't leave the emoji on the message forever. The next successful delivery retries the removal with **the exact emoji that was added**, so stuck receipts eventually clear. Receipts added before per-message bookkeeping have no record of which emoji was used; those are retried with the platform's fixed fallback value (eyes on Slack, Typing on Feishu, 思考 on DingTalk).
 
 WeCom has no emoji API, so its "processing" receipt is a placeholder message, such as a random "On it…". The task checklist card and the final answer then replace it in place.
 

en/changelog/changelog.mdx

@@ -4,6 +4,39 @@ description: "This page documents important updates and feature releases for Fla
 keywords: ["Changelog", "Product Release", "Feature Updates", "Flashduty", "Version History"]
 ---
 
+<Update label="2026-10-14" description="🧭 Investigation entries open the exact dashboard or query from an alert, alert-grouping rework, label-panel redesign, weekly and monthly scheduled notifications, dashboard global search">
+
+### Investigation entries: from an alert straight to a dashboard or the Query Workbench
+
+The alert-rule form gains a **sixth** block, **Investigation entries**: a rule can carry up to **20** jump targets, each one either an **Add dashboard entry** (pick a dashboard, set **Open at** to the whole dashboard / a tab / a group / a panel, and fill the dashboard variables' **variable values**) or an **Add query entry** (data source + query type + query statements + query parameters; leave the data source empty to use the alert event's own data source). Each entry takes a **purpose** (one line saying what it helps confirm) and a **time range** (how many minutes before and after the alert; both must be non-negative and their sum must be greater than 0), and entries can be dragged into a display order. Variable values render as Go templates whose context is only `$labels` (the alert's raw data labels, without rule-appended labels) and `$datasource` (the event data source's id / name / type / address); the query is rendered verbatim, never auto-quoted or escaped, and query parameters are not templated at all. **Preview link** then picks a live alert of the rule so you can try the jump before relying on it.
+
+Once the configuration is in effect, the right column of an incident or alert produced by a Monit alert rule shows an **Investigation Entries** block after **Attributes**: the entries come from the event's snapshot (the first 3 by default, the rest behind "N more"), each with its purpose, data source, variables and query time range, followed by the **alert rule** with its **main / related queries** — the values at trigger time, the results and the full expression. The same entries also appear behind the **Investigate** popover on every related-alert row and in the Monit active-alert detail drawer. The block is built from the event snapshot rather than the rule's current configuration, so editing a rule does not change the entries of alerts it already produced, and alerts accepted before the configuration took effect show none at all. Self-hosted deployments should note the version requirement: saving a rule that carries entries requires **every** registered monit-edge in the clusters of the data sources the rule matches to be `v0.75.3` or later, and saving is rejected otherwise; when a snapshot fails to render, the panel says why in place (rule deleted / Edge upgrade required / invalid configuration / content over 8KB). See [Alert rules · Investigation entries](/en/monitors/alert-rules/investigation-entries) and [Search and view incidents](/en/on-call/incident/search-view-incident).
+
+### Alert grouping: a three-way choice, configurable while you create the channel
+
+Alert grouping turns from an on/off switch with two modes into three mutually exclusive cards — **Intelligent grouping** / **Rule-based grouping** / **No grouping** — each with a one-line description and the currently effective one flagged **Default**: intelligent grouping "decides by how similar the titles, descriptions and label content are", rule-based grouping means "alerts with the same field values join one incident, with an explicit and previewable result", and no grouping means "one incident per alert, never joining an existing one". Availability now follows the plan: **Intelligent grouping** needs Professional or higher (selectable by default on-premises), **Rule-based grouping** needs Standard or higher, and Free gets **No grouping** only; a card out of reach is greyed out with the tooltip "your current subscription does not support this grouping method".
+
+The create-channel wizard gains a **fourth** step, **Alert Grouping**, so a new channel is grouped from the moment it exists: the method is preselected per plan (Professional and on-premises → Intelligent grouping, Standard → Rule-based grouping, Free → No grouping), and you can adjust the **Grouping fields** (rule-based) or the **Information used for matching** (intelligent), the **Grouping duration** (**Until the incident closes** / **Fixed 60 minutes**), and, under **Advanced**, **Strict mode**, **Information used for matching** and **Storm warning**. Rule-based grouping's two sub-options are renamed to **Use one rule for all alerts** / **Use different rules for different alerts**, and the fallback dimension becomes **When no rule matches**: group by the default fields below, and leave them empty to disable grouping. A new channel also enables flapping detection in **Alert Only** mode by default, with a 60-minute window and 4 state changes. See [Noise reduction](/en/on-call/channel/noise-reduction) and [Create and manage](/en/on-call/channel/create-edit).
+
+### Label panel redesign: system labels tucked away, links moved to the top
+
+The label panel on incident and alert details renders differently. **Hide Meta Label** becomes **Hide system labels** / **Show system labels** (with an eye icon) and recognises system labels per source, collapsed by default: a Monit alert treats only the `__alert_rule_` / `__entity_alert_` prefixes as system labels, while other sources keep the `__...__` sandwich plus the `__alert_rule_` / `__entity_alert_` / `__flashduty_` prefixes. While collapsed, a dashed hint at the bottom of the list reads "N system labels collapsed (first few keys…)"; expanding it shows a separate **System Labels** section (excluded from drag sorting), and the count next to the title is now the total number of labels.
+
+Labels whose value is an http(s) link and not an image no longer stay in the list — they move into a **Related Links** button bar above it, the button name mapped from the key (View source / Runbook / Silence / Open dashboard / Open panel / View query / View logs / View alert / View rule / Alert history), with unlisted keys falling back to "key · domain". Label values gain four renderings: an image link shows a thumbnail (click to open the full image), `arn:...` shows the resource segment with service and region, timestamps are formatted in the account time zone with an "x ago" suffix, and query keys (promql / logql / query / sql and similar) render as a monospace code block. Hovering a system label's value opens a hover card that translates machine labels — alert rule id, folder, data source, event type — into plain words with a link to jump. The old per-label **Explore** icon is gone: to open the query an alert fired with, use the system label's hover card, the **Investigation Entries** block on the right of the detail page, or the **Investigate** popover on a related-alert row. See [What is an incident](/en/on-call/incident/what-is-incident#incident-labels) and [Search and view incidents](/en/on-call/incident/search-view-incident).
+
+### Scheduled Notification: daily, weekly or monthly
+
+**Scheduled Notification** on a rotation is no longer daily-only: the cycle is **Daily / Weekly / Every month**, weekly multi-selects weekdays and monthly multi-selects the day of the month (1–31), and the notification still goes out at HH:MM on the chosen days in the schedule's time zone. A month without the chosen day (pick the 31st and meet a 30-day month) simply sends nothing that month, and a weekly or monthly cycle needs at least one day selected before it can be saved. See [Schedule](/en/on-call/configuration/schedule).
+
+### Dashboards: global search, panel query mode and template checks
+
+The dashboard list page gains a **Global search** at the top right: it searches dashboards across every folder the account can read (permission is filtered server-side), matches title or description, takes several keywords separated by spaces, labels each result with its folder path so duplicate titles can be told apart, shows 20 per page and offers a retry on failure. Its search state lives only inside the dialog — it neither affects the list page's "search the current folder" nor is written into the page address.
+
+In the panel editor's query **Options**, a Loki **table** or **stat** panel now lets you choose the **Query mode** yourself: **Range** computes point by point along the step to draw a trend, **Instant** computes a single value over the whole time range (`[$__auto]` takes the whole range) — table defaults to instant and stat to range. Loki time series stay fixed at range, and Loki instant does not accept a **min step**. Query-type template variables now get a form shaped by the data source: MySQL writes SQL, Loki fills a stream selector plus a label name, and other data sources use the Prometheus label form. The query is now pre-checked in the editor for the three patterns the backend refuses on save — a multi-select or "all" variable inside an exact matcher, a reference to an undefined variable, and a built-in variable unavailable for the current data source and query mode — and the exact-matcher one comes with a one-click **Switch to regex match**. **Preview candidates** now runs with the current variable selections and the panel's time range, so the preview matches what the dashboard actually renders. See [Dashboards](/en/monitors/dashboards/dashboards).
+
+</Update>
+
+
 <Update label="2026-10-13" description="🤖 AI SRE automations gain a war room created trigger, alert-rule related and recovery queries accept Go templates">
 
 ### AI SRE automations gain a War room created trigger

en/developer/go-sdk.mdx

@@ -278,7 +278,7 @@ zero := inc.StartTime.IsZero()        // whether it's the unset sentinel
 <Note>
 `AlertRuleV2`'s `investigation_targets` (the same return type of `AlertRules.ReadInfoV2` / `WriteCreateV2` / `WriteUpdateV2`) changed shape as well, so callers still sending the old fields have to migrate:
 
-- The field itself is `[]InvestigationTarget`, at most 20 entries with no duplicates; on the update endpoint it is presence-based — omitting it keeps the saved configuration, sending `[]` clears it. Each entry may carry an optional `purpose`: one-sentence plain text saying what the entry helps confirm (≤512 bytes; literal text, not a template, and not part of alert identity).
+- The field itself is `[]InvestigationTarget`, at most 20 entries with no duplicates, and the serialized list must not exceed **32 KiB** (`MaxInvestigationTargetsBytes = 32 * 1024`; exceeding it returns `investigation_targets must not exceed 32768 bytes`). On the update endpoint it is presence-based — omitting it keeps the saved configuration, sending `[]` clears it. Each entry may carry an optional `purpose`: one-sentence plain text saying what the entry helps confirm (**do not put line breaks in it**; the server validates ≤512 bytes and requires valid UTF-8 with no control characters, while the console caps the input at 200 characters, so the API accepts somewhat more than the console, but 200 CJK characters can already exceed 512 bytes). `purpose` is literal text, not a template, and is not part of alert identity or de-duplication.
 - Each entry is a **closed tagged union**, and `Kind` decides which sub-object you supply. `dashboard` (opens a dashboard panel) requires `Dashboard`, and `query` (opens an Explore query) requires `Query`. Supplying the other one, or an unknown field, is rejected.
 - `TimeRange` (`InvestigationTimeRange`: `BeforeSeconds` and `AfterSeconds`) is required on **every** saved entry — both directions are non-negative and at least one is greater than zero.
 - The `Dashboard` entry (`DashboardInvestigationTarget`) replaces the old `VariableBindings` (keyed by dashboard variable name, with values of `{source: event_label, key: label name}`) with `Variables`: a `map[string]string` keyed by variable name whose values are literal, and may reference event labels through `{{ }}` templates (the old `InvestigationVariableBinding` type is gone). `DashboardID` and `Variables` are required and `TargetID` is optional; `DashboardID` and `TargetID` must both be canonical UUIDv7 values.

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

@@ -60,6 +60,7 @@ When you add a label-type column, the corresponding label filter automatically a
 Each row has a **View details** entry, the eye icon at the end of the row. It opens the active alert detail drawer, which has the following sections:
 
 - **Alert overview**: current status (active), severity, active duration, and notification count
+- **Investigation entries**: the [investigation entries](/en/monitors/alert-rules/investigation-entries) snapshot of the rule that produced this alert, one row each, clickable through to the dashboard or the Query Workbench. This block renders the **snapshot taken when the alert was produced**, not the rule's current configuration: editing the rule afterwards does not change what an already-accepted alert shows, and an alert produced before the configuration took effect shows `This alert has no investigation links. Select an alert generated after the configuration took effect.` Entries whose snapshot failed to render (a variable that failed to render, a query that failed to render and was therefore not run, or a whole event with no snapshot) are still listed, but carry a red `Entry error` label and give no link
 - **Time information**: first fired, last evaluated, last notified, and last updated
 - **Rule & source**: alert rule, check mode (Threshold / Data exists / No data), data source name, data source type, instance type, and query Ref
 - **Current values**: a snapshot of the query result values that triggered the alert