@@ -47,12 +47,12 @@ You need the Owner, Admin, Network admin, or IT admin role in the tailnet.
 
 <Step title="Select events">
 
-Select the following events (or select the whole **Device misconfiguration** category):
+Select the following events. The two IP forwarding events make up the **Device Misconfigurations** category, so you can select that category instead; the others are in the **Tailnet Management** category:
 
 | Event | Effect |
 | :--- | :--- |
 | `nodeKeyExpiringInOneDay` | The node key expires in less than one day; opens an alert |
-| `nodeKeyExpired` | The node key has expired; raises the same alert to Critical |
+| `nodeKeyExpired` | The node key has expired; opens a Critical alert under the same Alert Key |
 | `nodeNeedsApproval` | A device is waiting for approval; opens an alert |
 | `nodeApproved` | The device was approved; recovers the approval alert |
 | `nodeNeedsSignature` | With Tailnet Lock enabled, a device is waiting for a signature; opens an alert |
@@ -108,7 +108,7 @@ Every alert also has the label `source=tailscale` and a `check` label (`key_expi
 Flashduty builds the Alert Key from the object (the device's `nodeID` or the user's `user`) and the check (`check`):
 
 - `nodeNeedsApproval` and `nodeApproved` for one device land on the same alert, which recovers when the device is approved
-- `nodeKeyExpiringInOneDay` and `nodeKeyExpired` for one device land on the same alert, which becomes Critical when the key expires
+- `nodeKeyExpiringInOneDay` and `nodeKeyExpired` for one device share an Alert Key. When the key expires, Flashduty opens a new Critical alert and keeps the earlier Warning alert open; `nodeDeleted` closes both
 - Different checks on one device (for example key expiry and pending approval) create separate alerts
 - Tailscale retries a failed delivery hourly for up to 24 hours; retried events merge into the original alert instead of creating duplicates
 
 
@@ -39,7 +39,7 @@ The steps below need an Uptrends user who can manage **Integrations** and **Aler
 
 Go to **Alerting → Integrations** and click **+** (in the new menu: **Configure → Alerting channels → +**), select **Uptrends integration**, click **Choose...**, then:
 
-1. Set **Name** to a name of your choice, for example `Flashduty`
+1. Set **Integration name** to a name of your choice, for example `Flashduty`
 2. For **ApiUrl**, select **Specify value here** and enter the full push URL, including `?integration_key=...`
 
 </Step>
@@ -81,11 +81,11 @@ By default, Uptrends sends **Error**, **Reminder**, and **Ok** messages with the
 
 </Step>
 
-<Step title="Send a test message">
+<Step title="Send a test alert">
 
-On the **Customizations** tab, click **Send test message**, select the **OK alert** type, and confirm that the response status code is `200`. Then click **Save**.
+Click **Send test alert** at the bottom of the page, pick any **Alert type** (**Error alert**, **OK alert** or **Reminder alert**), click **Start test**, and confirm that the result shows `200 OK`. Then click **Save**.
 
-Uptrends fills the monitor and alert data of a test message with fictitious values. An OK test message has no matching active alert, so it creates no alert in Flashduty. A test sent with the **Error alert** type creates a test alert, which you need to close manually in Flashduty.
+Uptrends fills a test alert with fictitious monitor and alert data. Flashduty recognizes test alerts of every type, answers `200`, and creates no alert.
 
 </Step>
 
@@ -141,7 +141,7 @@ Empty fields are not written as labels.
 ## Troubleshooting
 ---
 
-- **The test message fails**: Make sure **ApiUrl** is the full push URL, including the `integration_key` parameter, and that **Method** is `POST`
+- **The test alert fails**: Make sure **ApiUrl** is the full push URL, including the `integration_key` parameter, and that **Method** is `POST`
 - **Flashduty reports that the body is not valid JSON**: Make sure the request body matches the template and the text fields use `@JsonEncode`
 - **No alert is sent**: Make sure the alert definition of the monitor has the integration checked in an **Escalation level**. The **Messages** tab of the alert details in Uptrends shows the request Uptrends sent and the response from Flashduty
 - **The alert does not recover**: Make sure Ok messages use the same template and that `incident_key` in the template is `{{@incident.key}}`
 
@@ -47,12 +47,12 @@ keywords: ["告警集成", "Tailscale", "tailnet", "节点密钥过期", "设备
 
 <Step title="选择事件">
 
-选择下列事件（也可以直接勾选 **Device misconfiguration** 分类）：
+选择下列事件。两个 IP 转发事件组成 **Device Misconfigurations** 分类，可以直接勾选该分类；其余事件在 **Tailnet Management** 分类中：
 
 | 事件 | 作用 |
 | :--- | :--- |
 | `nodeKeyExpiringInOneDay` | 节点密钥将在一天内过期，打开告警 |
-| `nodeKeyExpired` | 节点密钥已过期，把同一告警升级为 Critical |
+| `nodeKeyExpired` | 节点密钥已过期，以同一 Alert Key 打开 Critical 告警 |
 | `nodeNeedsApproval` | 设备等待审批，打开告警 |
 | `nodeApproved` | 设备已批准，关闭审批告警 |
 | `nodeNeedsSignature` | 启用 Tailnet Lock 后设备等待签名，打开告警 |
@@ -108,7 +108,7 @@ Tailscale 每次推送一个 JSON 数组，一个数组可包含多个事件。F
 Flashduty 用对象（设备的 `nodeID` 或用户的 `user`）和检查项（`check`）一起生成 Alert Key：
 
 - 同一台设备的 `nodeNeedsApproval` 和 `nodeApproved` 落在同一条告警上，批准后告警关闭
-- 同一台设备的 `nodeKeyExpiringInOneDay` 和 `nodeKeyExpired` 落在同一条告警上，密钥过期时告警升级为 Critical
+- 同一台设备的 `nodeKeyExpiringInOneDay` 和 `nodeKeyExpired` 使用同一个 Alert Key。密钥过期时 Flashduty 会新建一条 Critical 告警，原 Warning 告警保持触发；`nodeDeleted` 会同时关闭这两条告警
 - 同一台设备的不同检查项（例如密钥过期和等待审批）各生成一条告警
 - Tailscale 投递失败后每小时重试一次，最多 24 小时；重试的事件合并到原告警，不会生成重复告警
 
 
@@ -39,7 +39,7 @@ Uptrends 通过**自定义集成**（Uptrends integration）推送告警：监
 
 进入 **Alerting → Integrations**，点击 **+**（新版菜单为 **Configure → Alerting channels → +**），选择 **Uptrends integration**，点击 **Choose...**，然后：
 
-1. **Name** 填写自定义名称，例如 `Flashduty`
+1. **Integration name** 填写自定义名称，例如 `Flashduty`
 2. **ApiUrl** 选择 **Specify value here**，填入完整的推送地址，包含 `?integration_key=...`
 
 </Step>
@@ -81,11 +81,11 @@ Uptrends 默认用同一个请求发送 **Error**、**Reminder** 和 **Ok** 三
 
 </Step>
 
-<Step title="发送测试消息">
+<Step title="发送测试告警">
 
-在 **Customizations** 标签页点击 **Send test message**，消息类型选择 **OK alert**，确认返回状态码为 `200`，然后点击 **Save**。
+点击页面底部的 **Send test alert**，**Alert type** 任选一种（**Error alert**、**OK alert** 或 **Reminder alert**），点击 **Start test**，确认结果显示 `200 OK`，然后点击 **Save**。
 
-测试消息中的监控和告警数据是 Uptrends 生成的虚构值。OK 类型的测试消息找不到对应的活动告警，不会在 Flashduty 中生成告警；选择 **Error alert** 发送测试会生成一条测试告警，需要在 Flashduty 中手动关闭。
+测试告警中的监控和告警数据是 Uptrends 生成的虚构值。Flashduty 能识别所有类型的测试告警，返回 `200`，不生成告警。
 
 </Step>
 
@@ -141,7 +141,7 @@ Uptrends 的告警没有等级，所有告警默认为 **Critical**。如需其
 ## 排查问题
 ---
 
-- **测试消息返回失败**：确认 **ApiUrl** 是完整的推送地址，包含 `integration_key` 参数，且 **Method** 为 `POST`
+- **测试告警返回失败**：确认 **ApiUrl** 是完整的推送地址，包含 `integration_key` 参数，且 **Method** 为 `POST`
 - **Flashduty 提示请求体不是合法 JSON**：确认请求体与模板一致，文本字段使用了 `@JsonEncode`
 - **告警没有发出**：确认监控使用的告警定义在某个 **Escalation level** 中勾选了该集成；可以在告警详情的 **Messages** 标签页查看 Uptrends 发出的请求和 Flashduty 的响应
 - **告警没有恢复**：确认 Ok 消息使用了同一个模板，且模板中的 `incident_key` 为 `{{@incident.key}}`