From f33c34fbe606990dafa43bf82cfcf8e1901ebcf6 Mon Sep 17 00:00:00 2001 From: bowen <86307842+debidong@users.noreply.github.com> Date: Fri, 9 Oct 2026 16:02:03 +0800 Subject: [PATCH 01/61] docs: fix typos, heading levels and misspelled URLs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - prometheus: api.flascat.cloud -> api.flashcat.cloud, Promtheus, bold spacing, 测->侧 - fix skipped heading levels (h2->h4) in RUM analytics, cli, blueking/keep/elastalert2 - servicedesk-plus-sync: h6 notes -> - rename zh/stsatuspage -> zh/statuspage, rum/error-tracking/erro-reporting -> error-reporting (zh/en), update links and add redirects --- docs.json | 38 ++++++++++++------- en/developer/cli.mdx | 2 +- .../alert-sources/blueking.mdx | 4 +- .../alert-integration/alert-sources/keep.mdx | 4 +- .../webhooks/servicedesk-plus-sync.mdx | 8 +++- en/rum/analytics/miniprogram.mdx | 16 ++++---- en/rum/analytics/native.mdx | 24 ++++++------ .../android.mdx | 0 .../ios.mdx | 0 .../web.mdx | 0 en/rum/error-tracking/overview.mdx | 2 +- en/rum/sdk/android/advanced-config.mdx | 2 +- en/rum/sdk/ios/sdk-integration.mdx | 2 +- .../scripts/build-docs-bundle.test.mjs | 2 +- zh/developer/cli.mdx | 2 +- .../alert-sources/blueking.mdx | 4 +- .../alert-sources/elastalert2.mdx | 4 +- .../alert-integration/alert-sources/keep.mdx | 4 +- .../alert-sources/prometheus.mdx | 8 ++-- .../webhooks/servicedesk-plus-sync.mdx | 8 +++- zh/rum/analytics/miniprogram.mdx | 16 ++++---- zh/rum/analytics/native.mdx | 24 ++++++------ .../android.mdx | 0 .../ios.mdx | 0 .../web.mdx | 0 zh/rum/error-tracking/overview.mdx | 2 +- zh/rum/sdk/android/advanced-config.mdx | 2 +- zh/rum/sdk/ios/advanced-config.mdx | 2 +- zh/rum/sdk/ios/sdk-integration.mdx | 2 +- zh/{stsatuspage.mdx => statuspage.mdx} | 0 30 files changed, 101 insertions(+), 81 deletions(-) rename en/rum/error-tracking/{erro-reporting => error-reporting}/android.mdx (100%) rename en/rum/error-tracking/{erro-reporting => error-reporting}/ios.mdx (100%) rename en/rum/error-tracking/{erro-reporting => error-reporting}/web.mdx (100%) rename zh/rum/error-tracking/{erro-reporting => error-reporting}/android.mdx (100%) rename zh/rum/error-tracking/{erro-reporting => error-reporting}/ios.mdx (100%) rename zh/rum/error-tracking/{erro-reporting => error-reporting}/web.mdx (100%) rename zh/{stsatuspage.mdx => statuspage.mdx} (100%) diff --git a/docs.json b/docs.json index 373594a4..af08d756 100644 --- a/docs.json +++ b/docs.json @@ -429,7 +429,7 @@ }, { "source": "/en/flashduty/rum/android-error-event", - "destination": "/en/rum/error-tracking/erro-reporting/android" + "destination": "/en/rum/error-tracking/error-reporting/android" }, { "source": "/en/flashduty/rum/android-sdk-integration", @@ -497,11 +497,11 @@ }, { "source": "/en/flashduty/rum/ios-error-event", - "destination": "/en/rum/error-tracking/erro-reporting/ios" + "destination": "/en/rum/error-tracking/error-reporting/ios" }, { "source": "/en/flashduty/rum/ios-error-tracking", - "destination": "/en/rum/error-tracking/erro-reporting/ios" + "destination": "/en/rum/error-tracking/error-reporting/ios" }, { "source": "/en/flashduty/rum/ios-sdk-integration", @@ -601,7 +601,7 @@ }, { "source": "/en/flashduty/rum/web-error-event", - "destination": "/en/rum/error-tracking/erro-reporting/web" + "destination": "/en/rum/error-tracking/error-reporting/web" }, { "source": "/en/flashduty/rum/web-sdk-integration", @@ -1089,7 +1089,7 @@ }, { "source": "/zh/flashduty/rum/android-error-event", - "destination": "/zh/rum/error-tracking/erro-reporting/android" + "destination": "/zh/rum/error-tracking/error-reporting/android" }, { "source": "/zh/flashduty/rum/android-sdk-integration", @@ -1153,7 +1153,7 @@ }, { "source": "/zh/flashduty/rum/ios-error-event", - "destination": "/zh/rum/error-tracking/erro-reporting/ios" + "destination": "/zh/rum/error-tracking/error-reporting/ios" }, { "source": "/zh/flashduty/rum/ios-sdk-integration", @@ -2926,6 +2926,18 @@ { "source": "/webhook/history/list", "destination": "/zh/api-reference/on-call/integrations/webhook-history-list" + }, + { + "source": "/zh/stsatuspage", + "destination": "/zh/statuspage" + }, + { + "source": "/zh/rum/error-tracking/erro-reporting/:slug*", + "destination": "/zh/rum/error-tracking/error-reporting/:slug*" + }, + { + "source": "/en/rum/error-tracking/erro-reporting/:slug*", + "destination": "/en/rum/error-tracking/error-reporting/:slug*" } ], "navigation": { @@ -2956,7 +2968,7 @@ "icon": "house", "pages": [ "zh/home", - "zh/stsatuspage" + "zh/statuspage" ] }, { @@ -3711,9 +3723,9 @@ { "group": "异常上报", "pages": [ - "zh/rum/error-tracking/erro-reporting/web", - "zh/rum/error-tracking/erro-reporting/android", - "zh/rum/error-tracking/erro-reporting/ios" + "zh/rum/error-tracking/error-reporting/web", + "zh/rum/error-tracking/error-reporting/android", + "zh/rum/error-tracking/error-reporting/ios" ] }, "zh/rum/error-tracking/error-viewing", @@ -5393,9 +5405,9 @@ { "group": "Error Reporting", "pages": [ - "en/rum/error-tracking/erro-reporting/web", - "en/rum/error-tracking/erro-reporting/android", - "en/rum/error-tracking/erro-reporting/ios" + "en/rum/error-tracking/error-reporting/web", + "en/rum/error-tracking/error-reporting/android", + "en/rum/error-tracking/error-reporting/ios" ] }, "en/rum/error-tracking/error-viewing", diff --git a/en/developer/cli.mdx b/en/developer/cli.mdx index 86aa0283..f82b7a59 100644 --- a/en/developer/cli.mdx +++ b/en/developer/cli.mdx @@ -870,7 +870,7 @@ Table view with no column truncation — useful for copy-paste or wide terminals -#### Generated-command output bound +### Generated-command output bound Generated commands (the ones covering the OpenAPI through the code generator, such as `safari session-list`, `monit datasource-list`, `safari a2a-agent-list`) apply a 16 KiB bound to **list-shaped** responses in `json`/`toon` mode. The reduction has three tiers, plus a machine-readable marker: diff --git a/en/on-call/integration/alert-integration/alert-sources/blueking.mdx b/en/on-call/integration/alert-integration/alert-sources/blueking.mdx index dc3ce403..cdc80059 100644 --- a/en/on-call/integration/alert-integration/alert-sources/blueking.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/blueking.mdx @@ -48,7 +48,7 @@ The following content has been verified on `BlueKing V6/7 versions`. V5 and belo BlueKing alert policies can trigger `Action Plans`, which can integrate with external systems for complex functionalities. First, create an Action Plan and configure the Flashduty callback URL, then edit the alert policy to associate actions with this plan, enabling automatic alert changes to be pushed to Flashduty. Here are the specific steps: -#### Step 1: Create Action Plan +### Step 1: Create Action Plan
@@ -67,7 +67,7 @@ BlueKing alert policies can trigger `Action Plans`, which can integrate with ext 5. Save the plan to complete creation.
-#### Step 2: Edit Alert Policy +### Step 2: Edit Alert Policy
diff --git a/en/on-call/integration/alert-integration/alert-sources/keep.mdx b/en/on-call/integration/alert-integration/alert-sources/keep.mdx index 4afc7abe..8d67112e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/keep.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/keep.mdx @@ -11,7 +11,7 @@ Push alert events to Flashduty through Keep's Flashduty Provider to achieve auto You can obtain an integration key through either of these 2 methods: -#### Using Dedicated Integration +### Using Dedicated Integration Choose this method when you don't need to route alert events to different channels - it's simpler. @@ -25,7 +25,7 @@ Choose this method when you don't need to route alert events to different channe -#### Using Shared Integration +### Using Shared Integration Choose this method when you need to route alerts to different channels based on the alert event's payload information. diff --git a/en/on-call/integration/webhooks/servicedesk-plus-sync.mdx b/en/on-call/integration/webhooks/servicedesk-plus-sync.mdx index f8625488..3b6942ba 100644 --- a/en/on-call/integration/webhooks/servicedesk-plus-sync.mdx +++ b/en/on-call/integration/webhooks/servicedesk-plus-sync.mdx @@ -29,7 +29,9 @@ Select the corresponding Developer Console address based on your ServiceDesk Plu ![2025-09-24-14-59-28](https://docs-cdn.flashcat.cloud/images/png/793fa15bd6e919e81fd3baaaab591275.png) ![2025-09-24-15-00-56](https://docs-cdn.flashcat.cloud/images/png/3b1b9d7a9c4bcc93ddf4cd73e47713f5.png) -###### Note: The Code is only valid for 10 minutes and can only be used once. After obtaining the Code, please complete [Integration Authorization](#integration-authorization) within the validity period. + +The Code is only valid for 10 minutes and can only be used once. After obtaining the Code, please complete [Integration Authorization](#integration-authorization) within the validity period. + ### In Flashduty On-call #### Step 2: Integration Authorization @@ -44,7 +46,9 @@ Select the corresponding API Endpoint and Accounts Server URL based on your Serv 1. Login to ServiceDesk Plus console, click `Generate API Key` in Personal Center. 2. Select **Never Expire** for `Token Expiration`, copy the generated **Token** for later use, and complete [Integration Authorization](#private-deployment-authorization). -###### Note: The user generating the API key needs relevant permissions such as create/update requests, get template/priority/custom field lists. Insufficient permissions will prevent completing integration configuration—we recommend using an admin role. + +The user generating the API key needs relevant permissions such as create/update requests, get template/priority/custom field lists. Insufficient permissions will prevent completing integration configuration—we recommend using an admin role. + ### In Flashduty On-call #### Step 2: Integration Authorization diff --git a/en/rum/analytics/miniprogram.mdx b/en/rum/analytics/miniprogram.mdx index e570bd5b..461bc464 100644 --- a/en/rum/analytics/miniprogram.mdx +++ b/en/rum/analytics/miniprogram.mdx @@ -13,13 +13,13 @@ The Insights dashboard includes 2 core analysis dimensions: **Overview** and **P The Overview tab focuses on the core multi-dimensional metrics of your Mini Program, helping you quickly assess overall health. -#### Traffic and Sessions +### Traffic and Sessions - **UV**: Number of unique visitors after deduplication. Combined with the trend chart, this reveals user activity patterns. - **Sessions**: Total number of sessions in which the Mini Program was opened. Click the card to drill into the session list. - **User Access Trend**: Time-series chart showing UV and Session changes over time, helping you identify traffic peaks and unusual fluctuations. -#### Core Metrics +### Core Metrics - **error_count**: Monitors the total number of error events and their time-series trend, surfacing anomaly spikes early. - **Session Error Rate**: Percentage of sessions that contain at least one error, reflecting overall Mini Program stability. @@ -28,7 +28,7 @@ The Overview tab focuses on the core multi-dimensional metrics of your Mini Prog - **setDataCount (avg)**: Average number of `setData` calls per page view. A high call rate increases communication overhead between the JS thread and the render thread. - **setDataDuration P75**: The P75 percentile of a single `setData` call's duration. -#### Session Analysis +### Session Analysis - **Average Session Duration**: Total session duration divided by session count, used to assess user stickiness and engagement depth. The accompanying time-series chart helps identify behavioral shifts among active users. @@ -36,7 +36,7 @@ The Overview tab focuses on the core multi-dimensional metrics of your Mini Prog The Performance Analysis tab provides end-to-end monitoring of the core experience metrics: launch, page rendering, and `setData`. -#### Core Performance Metrics +### Core Performance Metrics Five key performance metric cards are displayed at the top. Click any card to switch the trend chart and sample distribution below to that metric: @@ -50,7 +50,7 @@ Five key performance metric cards are displayed at the top. Click any card to sw Each card displays a health-status badge (good / warning / poor) in the top-left corner, calculated against built-in thresholds. -#### Trend Analysis +### Trend Analysis The trend chart below supports a **Trend Mode** selector that breaks down the current metric by different dimensions: @@ -66,11 +66,11 @@ The trend chart below supports a **Trend Mode** selector that breaks down the cu Switch to **By Version** during a gradual rollout to validate release quality. Switch to **By Loading Type** to observe cold-start (`initial_load`) and warm-start (`route_change`) durations independently. -#### Sample Distribution +### Sample Distribution The sample distribution bar chart shows the count of samples falling into each time bucket for the current metric, surfacing long-tail behavior. For example, when viewing App Launch Time, the distribution clearly shows how many users launch within 1s, 1-2s, more than 2s, and so on. -#### Per-Page Performance Detail +### Per-Page Performance Detail A per-page table breaks down performance metrics by view name, helping you identify pages with slow loading or excessive `setData` calls: @@ -88,7 +88,7 @@ A per-page table breaks down performance metrics by view name, helping you ident Click any row to drill into the detailed analysis view for that page. -#### Loading Type Trends +### Loading Type Trends Two charts at the bottom compare cold start (`initial_load`) and warm start (`route_change`): diff --git a/en/rum/analytics/native.mdx b/en/rum/analytics/native.mdx index 76f2ffdd..3c28ba52 100644 --- a/en/rum/analytics/native.mdx +++ b/en/rum/analytics/native.mdx @@ -42,7 +42,7 @@ The Overview module focuses on core metrics across multiple dimensions for mobil The Performance Analysis module focuses on full-chain monitoring of core experience metrics including app startup, page rendering, and interaction smoothness. -#### Core Performance Metrics +### Core Performance Metrics The top section displays P75 percentile values for four key performance metrics: @@ -52,12 +52,12 @@ The top section displays P75 percentile values for four key performance metrics: - **Memory Usage (P75)**: Monitor the P75 percentile of app memory usage to detect memory leaks or abnormal growth early. - **JS Thread Frame Rate (P75)**: Monitor the P75 percentile of the React Native JS thread's frame rate (FPS). Compared with the native frame rate, it reflects jank caused by business JavaScript more directly (re-renders, synchronous work on the bridge). Reported only by the React Native SDK. -#### App Startup Time Analysis +### App Startup Time Analysis - **Startup Time Trend Chart**: Shows how app startup time changes over time, helping you evaluate optimization effectiveness and detect performance regressions. - **Sample Distribution Histogram**: Statistics of startup duration distribution by time intervals (e.g., 0.9425s-0.9642s, 1.1162s-1.1379s), providing insights into real user startup experience distribution and identifying long-tail performance issues. -#### View Performance Details +### View Performance Details Performance metrics by view name (Page/Activity/ViewController): @@ -68,7 +68,7 @@ Performance metrics by view name (Page/Activity/ViewController): - **CPU Usage**: Statistics of CPU utilization for each view to optimize compute-intensive pages. - **Memory Usage**: Monitor memory usage for each view to detect memory leak risks. -#### Smoothness Analysis +### Smoothness Analysis App smoothness metrics by view name: @@ -91,7 +91,7 @@ If you disabled long-task collection to reduce event volume, raising the thresho **Slow Frame Share is not comparable across platforms.** The numerator is slow-frame time on both, but the denominator differs: Android divides by total frame render time, iOS by view duration. The same user experience usually scores much higher on Android, because a static screen produces almost no frames — a small denominator — while the first frame is by definition a slow one. Compare values within a single platform over time. -#### Memory Analysis +### Memory Analysis Memory usage details by view name: @@ -107,21 +107,21 @@ Memory usage details by view name: The Error Analysis module provides comprehensive error monitoring and diagnosis capabilities. -#### Core Stability Metrics +### Core Stability Metrics - **Crash Count**: Monitor total crash occurrences and trends to detect abnormal spikes early. Crashes force app termination and severely impact user experience. - **Crash-free Rate**: Track the percentage of crash-free sessions to evaluate overall app stability. Industry standard recommends maintaining crash-free rate above 99.5%. - **ANR Rate**: Statistics of Android Application Not Responding occurrence rate. ANR indicates the app's main thread has been blocked for more than 5 seconds, causing users to see the "App Not Responding" dialog. - **Unresponsive Time Rate**: Seconds the main thread was unresponsive per hour of view time (seconds/hour), averaged by view time and counted only over views the SDK finished measuring. **This card is shown for iOS and Flutter apps only**; Android-only apps show the ANR Rate above instead. See "How to reduce unresponsive time rate?" below. -#### Error Statistics +### Error Statistics - **Error Count**: Shows total error count and time-series trends to understand overall app health changes. - **Error Type Distribution Trend Chart**: Stacked bar chart showing distribution changes of crash errors (crash_count) and non-crash errors (non_crash_count) over time, quickly identifying abnormal periods and error type change trends. - **Crash Errors (crash_count)**: Severe errors causing forced app termination - **Non-crash Errors (non_crash_count)**: Caught exceptions where the app can continue running but functionality may be affected -#### Page Crash Ranking (Top 10) +### Page Crash Ranking (Top 10) Lists pages or view controllers with the most crashes, each record containing: @@ -132,7 +132,7 @@ Lists pages or view controllers with the most crashes, each record containing: This ranking helps you prioritize the most impactful page crash issues. -#### Top Issues (Top 10) +### Top Issues (Top 10) Shows ranking of issues affecting the most users. Each Issue is an aggregated collection of errors containing: @@ -143,17 +143,17 @@ Shows ranking of issues affecting the most users. Each Issue is an aggregated co **Note**: An Issue may aggregate multiple errors with the same root cause. For Issue aggregation strategy, see [Error Grouping](/en/rum/error-tracking/error-aggregation). -#### Error Type Distribution +### Error Type Distribution - **Error Type Proportion (Pie Chart)**: Shows proportion of different error types (e.g., ReferenceError, java.lang.RuntimeException, etc.) to quickly identify main error sources. - **Error Type Distribution Trend (Stacked Bar Chart)**: Monitor changes in each error type over time to detect new error types or abnormal growth of certain errors. -#### Version Crash Distribution +### Version Crash Distribution - **Version Crash Distribution (Pie Chart)**: Statistics of crash distribution across different app versions to identify high-risk versions. - **Version Crash Distribution Trend (Stacked Bar Chart)**: Monitor crash changes across versions over time to evaluate new version quality and perform hotfixes or rollbacks when necessary. -#### System Version Error Distribution +### System Version Error Distribution - **System Version Error Distribution (Pie Chart)**: Statistics of error distribution across different OS versions (e.g., Android 11, Android 12, iOS 15, etc.) to identify system compatibility issues. - **System Version Error Trend (Stacked Bar Chart)**: Monitor error changes across system versions over time to support system compatibility optimization. diff --git a/en/rum/error-tracking/erro-reporting/android.mdx b/en/rum/error-tracking/error-reporting/android.mdx similarity index 100% rename from en/rum/error-tracking/erro-reporting/android.mdx rename to en/rum/error-tracking/error-reporting/android.mdx diff --git a/en/rum/error-tracking/erro-reporting/ios.mdx b/en/rum/error-tracking/error-reporting/ios.mdx similarity index 100% rename from en/rum/error-tracking/erro-reporting/ios.mdx rename to en/rum/error-tracking/error-reporting/ios.mdx diff --git a/en/rum/error-tracking/erro-reporting/web.mdx b/en/rum/error-tracking/error-reporting/web.mdx similarity index 100% rename from en/rum/error-tracking/erro-reporting/web.mdx rename to en/rum/error-tracking/error-reporting/web.mdx diff --git a/en/rum/error-tracking/overview.mdx b/en/rum/error-tracking/overview.mdx index bc07f345..413a0721 100644 --- a/en/rum/error-tracking/overview.mdx +++ b/en/rum/error-tracking/overview.mdx @@ -112,7 +112,7 @@ After resolving a problem, you can transition the Issue status in the system and ## Next Steps - + Learn about error reporting rules and methods diff --git a/en/rum/sdk/android/advanced-config.mdx b/en/rum/sdk/android/advanced-config.mdx index 0b95ec23..2c136bee 100644 --- a/en/rum/sdk/android/advanced-config.mdx +++ b/en/rum/sdk/android/advanced-config.mdx @@ -214,7 +214,7 @@ GlobalRumMonitor.get().addError( -For more error reporting details, see [Android Error Reporting](/en/rum/error-tracking/erro-reporting/android). +For more error reporting details, see [Android Error Reporting](/en/rum/error-tracking/error-reporting/android). ### Custom Timing diff --git a/en/rum/sdk/ios/sdk-integration.mdx b/en/rum/sdk/ios/sdk-integration.mdx index ffb67cee..facbe77d 100644 --- a/en/rum/sdk/ios/sdk-integration.mdx +++ b/en/rum/sdk/ios/sdk-integration.mdx @@ -390,7 +390,7 @@ All error information is displayed in the console's RUM Explorer, including erro -For detailed error reporting configuration, see [iOS Error Reporting](/en/rum/error-tracking/erro-reporting/ios). +For detailed error reporting configuration, see [iOS Error Reporting](/en/rum/error-tracking/error-reporting/ios). ### Track Background Events diff --git a/integration-docs/scripts/build-docs-bundle.test.mjs b/integration-docs/scripts/build-docs-bundle.test.mjs index 358efb5b..0f7c5112 100644 --- a/integration-docs/scripts/build-docs-bundle.test.mjs +++ b/integration-docs/scripts/build-docs-bundle.test.mjs @@ -41,7 +41,7 @@ test('derivePublicUrl prefers frontmatter url, else derives from the path', () = 'https://docs.flashduty.com/zh/on-call/integration/instant-messaging/lark' ); assert.equal( - derivePublicUrl('zh/stsatuspage.mdx', { url: 'https://status.flashcat.cloud' }), + derivePublicUrl('zh/statuspage.mdx', { url: 'https://status.flashcat.cloud' }), 'https://status.flashcat.cloud' ); }); diff --git a/zh/developer/cli.mdx b/zh/developer/cli.mdx index 0eab27c3..530830fe 100644 --- a/zh/developer/cli.mdx +++ b/zh/developer/cli.mdx @@ -870,7 +870,7 @@ TOON 不能直接用 `jq` 解析；需要管道给 `jq` 时请改用 `--json`。 -#### 生成命令的输出上限 +### 生成命令的输出上限 由 OpenAPI 代码生成提供覆盖的生成命令（如 `safari session-list`、`monit datasource-list`、`safari a2a-agent-list` 等），其 `json` / `toon` 输出对**列表形态**的响应按 16 KiB 上限处理。缩减分三级，另外会有一个机读标记： diff --git a/zh/on-call/integration/alert-integration/alert-sources/blueking.mdx b/zh/on-call/integration/alert-integration/alert-sources/blueking.mdx index d347e740..32f4c201 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/blueking.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/blueking.mdx @@ -51,7 +51,7 @@ keywords: ["告警集成", "蓝鲸智云集成", "监控告警", "数据接入"] 蓝鲸告警策略可以触发`处理套餐`，处理套餐可与周边系统打通，来完成复杂功能。我们首先创建一个处理套餐，配置 Flashduty 的回调地址，然后编辑告警策略，关联动作到该处理套餐，实现告警变更自动推送到 Flashduty。具体步骤如下： -#### 步骤 1、创建处理套餐 +### 步骤 1、创建处理套餐
@@ -70,7 +70,7 @@ keywords: ["告警集成", "蓝鲸智云集成", "监控告警", "数据接入"] 5. 保存套餐，完成创建。
-#### 步骤 2、编辑告警策略 +### 步骤 2、编辑告警策略
diff --git a/zh/on-call/integration/alert-integration/alert-sources/elastalert2.mdx b/zh/on-call/integration/alert-integration/alert-sources/elastalert2.mdx index fb414cee..e8e88c47 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/elastalert2.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/elastalert2.mdx @@ -10,7 +10,7 @@ keywords: ["告警集成", "ElastAlert2 告警集成指引", "监控告警", " 您可通过以下2种方式，获取一个集成秘钥，任选其一即可。 -#### 使用专属集成 +### 使用专属集成 当您不需要将告警事件路由到不同的协作空间，优先选择此方式，更简单。 @@ -25,7 +25,7 @@ keywords: ["告警集成", "ElastAlert2 告警集成指引", "监控告警", " -#### 使用共享集成 +### 使用共享集成 当您需要根据告警事件的 Payload 信息，将告警路由到不同的协作空间，优先选择此方式。 diff --git a/zh/on-call/integration/alert-integration/alert-sources/keep.mdx b/zh/on-call/integration/alert-integration/alert-sources/keep.mdx index bde41516..175047f3 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/keep.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/keep.mdx @@ -10,7 +10,7 @@ keywords: ["告警集成", "Keep 告警集成指引", "监控告警", "数据接 您可通过以下2种方式，获取一个集成秘钥，任选其一即可。 -#### 使用专属集成 +### 使用专属集成 当您不需要将告警事件路由到不同的协作空间，优先选择此方式，更简单。 @@ -25,7 +25,7 @@ keywords: ["告警集成", "Keep 告警集成指引", "监控告警", "数据接 -#### 使用共享集成 +### 使用共享集成 当您需要根据告警事件的 Payload 信息，将告警路由到不同的协作空间，优先选择此方式。 diff --git a/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx b/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx index 8b9f23e4..50f6f483 100644 --- a/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx +++ b/zh/on-call/integration/alert-integration/alert-sources/prometheus.mdx @@ -13,7 +13,7 @@ keywords: ["告警集成", "Prometheus", "监控告警", "数据接入"] ### 在 AlertManager - 您必须拥有修改 AlertManager 配置文件的权限。 -- 您的 AlertManager server 必须能够访问域名 api.flascat.cloud，将告警推送到外网。 +- 您的 AlertManager server 必须能够访问域名 api.flashcat.cloud，将告警推送到外网。 ## 支持版本 --- @@ -50,7 +50,7 @@ keywords: ["告警集成", "Prometheus", "监控告警", "数据接入"] 1. 进入 Flashduty 控制台，选择 **集成中心=>告警事件**，进入集成选择页面。 - 2. 选择 ** Prometheus** 集成： + 2. 选择 **Prometheus** 集成： - **集成名称**：为当前集成定义一个名称。 3. 配置默认路由，并选择对应的协作空间（集成创建后可以前往 `路由` 进行更多路由规则的配置）。 4. 点击 **保存** 后，复制当前页面的新生成的 **推送地址** 备用。 @@ -166,7 +166,7 @@ VMP 的 `alertname` 标签是告警规则的 UUID，默认生成的告警标题 系统依次提取告警事件标签中的 `severity`、`priority`和 `level`，对应值将作为 Prometheus 自身的告警等级。如果都没有提取到，再读取 VMP 的 `internal_label_alert_level` 标签：`P0` 对应 Critical，`P1` 对应 Warning，`P2` 对应 Info。仍未提取到时，系统自动设置 Prometheus 告警等级为 `Warning`。 -Promtheus 到 Flashduty On-call 告警等级映射关系： +Prometheus 到 Flashduty On-call 告警等级映射关系： | Prometheus | Flashduty | 状态 | | ------------ | -------- | ---- | @@ -192,7 +192,7 @@ Promtheus 到 Flashduty On-call 告警等级映射关系： #### 在 AlertManager - 1. 首先确认 AlertManager 测是否产生了新的告警。如没有产生新告警，请继续等待新告警触发后重新验证。 + 1. 首先确认 AlertManager 侧是否产生了新的告警。如没有产生新告警，请继续等待新告警触发后重新验证。 2. 打开 AlertManager 配置文件，如果您设置了子路由，请确保您的路由设置正确（比如前边的路由设置了 continue，AlertManager 会跳过匹配后续子路由。我们推荐您永远仅设置一个默认路由到 Flashduty On-call）。同时验证，目标回调地址是否和集成推送地址完全匹配。如果不匹配，请修改 **告警规则**后重新验证。 3. 如果匹配，请继续确认 AlertManager 实例可以访问外网 api.flashcat.cloud 域名。如果不可以，您首先需要为其开通外网，或单独针对 Flashduty On-call 的域名开通外网访问。 4. 如果网络无问题，您需要继续排查 AlertManager，查找是否存在相关的错误日志。 diff --git a/zh/on-call/integration/webhooks/servicedesk-plus-sync.mdx b/zh/on-call/integration/webhooks/servicedesk-plus-sync.mdx index 34e738f9..1a51c9f0 100644 --- a/zh/on-call/integration/webhooks/servicedesk-plus-sync.mdx +++ b/zh/on-call/integration/webhooks/servicedesk-plus-sync.mdx @@ -30,7 +30,9 @@ keywords: ["ServiceDesk Plus", "工单同步", "Webhook", "ITSM", "故障关联" ![2025-09-24-14-59-28](https://docs-cdn.flashcat.cloud/images/png/793fa15bd6e919e81fd3baaaab591275.png) ![2025-09-24-15-00-56](https://docs-cdn.flashcat.cloud/images/png/3b1b9d7a9c4bcc93ddf4cd73e47713f5.png) -###### 注意：Code 的有效期只有 10 分钟且只能使用一次，所以在获取到 Code 后，请在有效期内尽快完成[集成授权](#集成授权) + +Code 的有效期只有 10 分钟且只能使用一次，所以在获取到 Code 后，请在有效期内尽快完成[集成授权](#集成授权) + ### 在 Flashduty On-call #### 步骤2 集成授权 @@ -45,7 +47,9 @@ keywords: ["ServiceDesk Plus", "工单同步", "Webhook", "ITSM", "故障关联" 1. 登录 ServiceDesk Plus 控制台，在个人中心点击 `生成 API 密钥`。 2. `令牌过期时间` 选择 **永不过期**，将生成的 **Token** 复制备用，并完成[集成授权](#私有化版本集成授权)。 -###### 注意：生成 API 密钥的用户需要具备相关权限，比如创建/更新请求、获取模版/优先级/自定义字段列表等权限，如果权限不足，会导致无法完成集成配置，建议使用管理员角色生成。 + +生成 API 密钥的用户需要具备相关权限，比如创建/更新请求、获取模版/优先级/自定义字段列表等权限，如果权限不足，会导致无法完成集成配置，建议使用管理员角色生成。 + ### 在 Flashduty On-call #### 步骤2 集成授权 diff --git a/zh/rum/analytics/miniprogram.mdx b/zh/rum/analytics/miniprogram.mdx index 39bd7b07..4ade1158 100644 --- a/zh/rum/analytics/miniprogram.mdx +++ b/zh/rum/analytics/miniprogram.mdx @@ -14,13 +14,13 @@ Flashduty 微信小程序 RUM 分析看板提供开箱即用的可视化仪表 概览模块聚焦于小程序多维度的核心指标，帮助您快速把握整体健康状况。 -#### 流量与会话 +### 流量与会话 - **UV**：去重后的独立访客数。结合趋势图可洞察用户活跃规律。 - **会话数**：小程序被打开使用的会话总数，点击卡片可下钻查看具体会话列表。 - **用户访问趋势**：以时序图同时展示 UV 与 Session 的变化趋势，识别访问高峰与异常波动。 -#### 核心指标 +### 核心指标 - **错误数（error_count）**：监控小程序错误事件的总数与时序趋势，及时发现异常峰值。 - **会话错误率（session error rate）**：发生错误的会话占总会话的比例，反映小程序整体稳定性。 @@ -29,7 +29,7 @@ Flashduty 微信小程序 RUM 分析看板提供开箱即用的可视化仪表 - **setData 调用次数（setDataCount 平均值）**：监控页面平均每次访问的 `setData` 调用次数。过高的调用频次会增加 JS 与渲染线程的通信开销。 - **setData 耗时 P75（setDataDuration P75）**：监控单次 `setData` 调用耗时的 P75 分位值。 -#### 会话分析 +### 会话分析 - **平均会话时长**：会话总时长除以会话总数，评估用户粘性与使用深度。结合时序图可识别活跃用户行为变化。 @@ -37,7 +37,7 @@ Flashduty 微信小程序 RUM 分析看板提供开箱即用的可视化仪表 性能分析模块专注于小程序启动、页面渲染、`setData` 等核心体验指标的全链路监控。 -#### 核心性能指标 +### 核心性能指标 顶部展示 5 个关键性能指标卡片，点击任一卡片可切换下方趋势图与样本分布的统计维度： @@ -51,7 +51,7 @@ Flashduty 微信小程序 RUM 分析看板提供开箱即用的可视化仪表 每个卡片左上角显示健康状态徽标（良好 / 中等 / 差），基于内置阈值评估当前指标。 -#### 趋势分析 +### 趋势分析 下方的趋势图支持选择 **趋势模式**，按不同维度展开当前指标： @@ -67,11 +67,11 @@ Flashduty 微信小程序 RUM 分析看板提供开箱即用的可视化仪表 切换 **按版本** 时可对比新版本灰度阶段的性能数据，验证发版质量；切换 **按加载类型** 时可单独观察冷启动（`initial_load`）和热启动（`route_change`）的耗时差异。 -#### 样本分布 +### 样本分布 样本分布柱状图按时间区间统计当前指标的样本数量分布，识别长尾问题。例如观察应用启动时长时，分布图能清晰展示有多少用户的启动耗时落在 1s 以内、1-2s、2s 以上等区间。 -#### 页面性能明细 +### 页面性能明细 按页面（视图名称）统计各项性能指标，识别加载缓慢或 `setData` 过于频繁的页面： @@ -89,7 +89,7 @@ Flashduty 微信小程序 RUM 分析看板提供开箱即用的可视化仪表 点击表格中的任一行可跳转到该页面的详细分析视图。 -#### 启动类型趋势 +### 启动类型趋势 底部两张图分别展示冷启动（`initial_load`）与热启动（`route_change`）的对比情况： diff --git a/zh/rum/analytics/native.mdx b/zh/rum/analytics/native.mdx index d2609f80..b0779c7b 100644 --- a/zh/rum/analytics/native.mdx +++ b/zh/rum/analytics/native.mdx @@ -43,7 +43,7 @@ Native 看板适用于 Android、iOS、HarmonyOS、Flutter 和 React Native 应 性能分析模块专注于应用启动、页面渲染、交互流畅度等核心体验指标的全链路监控。 -#### 核心性能指标 +### 核心性能指标 顶部展示四个关键性能指标的 P75 分位值： @@ -53,12 +53,12 @@ Native 看板适用于 Android、iOS、HarmonyOS、Flutter 和 React Native 应 - **内存使用（P75）**：监控应用内存占用的 P75 分位数，及时发现内存泄漏或异常增长。 - **JS 线程帧率（P75）**：监控 React Native JS 线程帧率的 P75 分位数（FPS）。相比原生帧率，它更直接反映业务 JavaScript 造成的卡顿（重渲染、桥上的同步工作）。仅 React Native SDK 上报。 -#### APP 启动时间分析 +### APP 启动时间分析 - **启动时间趋势图**：展示应用启动时间随时间的变化趋势，帮助您评估启动优化效果，及时发现性能退化。 - **样本分布柱状图**：按时间区间统计启动耗时的分布情况（如 0.9425s-0.9642s、1.1162s-1.1379s 等），了解用户真实启动体验的分布特征，识别性能长尾问题。 -#### 视图性能明细 +### 视图性能明细 按视图名称（页面/Activity/ViewController）统计各项性能指标： @@ -69,7 +69,7 @@ Native 看板适用于 Android、iOS、HarmonyOS、Flutter 和 React Native 应 - **CPU 消耗**：统计各视图的 CPU 占用情况，优化计算密集型页面。 - **内存使用**：监控各视图的内存占用，发现内存泄漏风险。 -#### 流畅度分析 +### 流畅度分析 按视图名称统计应用流畅度相关指标： @@ -92,7 +92,7 @@ Native 看板适用于 Android、iOS、HarmonyOS、Flutter 和 React Native 应 **慢帧占比不能跨平台横比。** 分子都是慢帧耗时，但分母不同：Android 除以渲染总耗时，iOS 除以视图停留时长。同一种用户体验在 Android 上的数值通常明显更高，因为静止界面几乎不产生帧，分母很小，而首帧本身又必然是慢帧。请在同一平台内部做纵向对比。 -#### 内存分析 +### 内存分析 按视图名称统计内存使用详情： @@ -108,21 +108,21 @@ Native 看板适用于 Android、iOS、HarmonyOS、Flutter 和 React Native 应 异常分析模块为您提供全方位的错误监控与诊断能力。 -#### 核心稳定性指标 +### 核心稳定性指标 - **崩溃次数**：监控应用崩溃的发生总数和趋势，及时发现异常峰值。崩溃会导致应用强制退出，严重影响用户体验。 - **无崩溃率**：跟踪无崩溃会话占比，评估应用整体稳定性表现。行业标准建议无崩溃率应保持在 99.5% 以上。 - **ANR 率**：统计 Android 应用无响应（Application Not Responding）的发生比例。ANR 表示应用主线程被阻塞超过 5 秒，用户会看到"应用无响应"对话框。 - **无响应时长率**：每小时视图时长内主线程处于无响应状态的秒数（秒/小时），按视图时长加权平均，且仅统计 SDK 已完成测量的视图。**该卡片只在 iOS 和 Flutter 应用中展示**，纯 Android 应用对应展示的是上方的 ANR 率。详见下方「如何降低无响应时长率？」。 -#### 错误数据统计 +### 错误数据统计 - **错误数**：展示错误总数和时序趋势，了解应用健康状况的整体变化。 - **错误类型分布趋势图**：通过堆叠柱状图展示崩溃错误（crash_count）与非崩溃错误（non_crash_count）随时间的分布变化，快速识别异常时段和错误类型变化趋势。 - **崩溃错误（crash_count）**：导致应用强制退出的严重错误 - **非崩溃错误（non_crash_count）**：被捕获的异常，应用可继续运行但功能可能受影响 -#### 页面 Crash 排行（Top10） +### 页面 Crash 排行（Top10） 列出崩溃次数最多的页面或视图控制器，每条记录包含： @@ -133,7 +133,7 @@ Native 看板适用于 Android、iOS、HarmonyOS、Flutter 和 React Native 应 此排行帮助您优先处理影响最大的页面崩溃问题。 -#### 热门 Issue（Top10） +### 热门 Issue（Top10） 展示影响用户最多的问题排行，每个 Issue 是经过聚合的错误集合，包含： @@ -144,17 +144,17 @@ Native 看板适用于 Android、iOS、HarmonyOS、Flutter 和 React Native 应 **注意**：一个 Issue 可能聚合了多次相同根因的错误。关于 Issue 聚合策略，可查看[异常聚合](https://docs.flashduty.com/zh/flashduty/rum/error-grouping)。 -#### 错误类型分布 +### 错误类型分布 - **错误类型占比（饼图）**：展示不同错误类型的占比（如 ReferenceError、java.lang.RuntimeException 等），快速识别主要错误来源。 - **错误类型分布趋势（堆叠柱状图）**：监控各错误类型随时间的变化趋势，及时发现新增错误类型或某类错误的异常增长。 -#### 版本 Crash 分布 +### 版本 Crash 分布 - **版本 Crash 分布（饼图）**：统计不同应用版本的崩溃分布情况，识别高风险版本。 - **版本 Crash 分布趋势（堆叠柱状图）**：监控各版本崩溃随时间的变化，评估新版本质量，必要时进行热修复或回滚。 -#### 系统版本异常分布 +### 系统版本异常分布 - **系统版本异常分布（饼图）**：统计不同操作系统版本（如 Android 11、Android 12、iOS 15 等）的异常分布情况，识别系统兼容性问题。 - **系统版本异常趋势（堆叠柱状图）**：监控各系统版本异常随时间的变化，为系统兼容性优化提供数据支撑。 diff --git a/zh/rum/error-tracking/erro-reporting/android.mdx b/zh/rum/error-tracking/error-reporting/android.mdx similarity index 100% rename from zh/rum/error-tracking/erro-reporting/android.mdx rename to zh/rum/error-tracking/error-reporting/android.mdx diff --git a/zh/rum/error-tracking/erro-reporting/ios.mdx b/zh/rum/error-tracking/error-reporting/ios.mdx similarity index 100% rename from zh/rum/error-tracking/erro-reporting/ios.mdx rename to zh/rum/error-tracking/error-reporting/ios.mdx diff --git a/zh/rum/error-tracking/erro-reporting/web.mdx b/zh/rum/error-tracking/error-reporting/web.mdx similarity index 100% rename from zh/rum/error-tracking/erro-reporting/web.mdx rename to zh/rum/error-tracking/error-reporting/web.mdx diff --git a/zh/rum/error-tracking/overview.mdx b/zh/rum/error-tracking/overview.mdx index 4387d0a5..9e6451fe 100644 --- a/zh/rum/error-tracking/overview.mdx +++ b/zh/rum/error-tracking/overview.mdx @@ -113,7 +113,7 @@ Flashduty RUM 的异常追踪分为两个关键阶段：**问题发现** 和 ** ## 下一步 - + 了解异常上报规则和方式 diff --git a/zh/rum/sdk/android/advanced-config.mdx b/zh/rum/sdk/android/advanced-config.mdx index 20d15873..e504d2db 100644 --- a/zh/rum/sdk/android/advanced-config.mdx +++ b/zh/rum/sdk/android/advanced-config.mdx @@ -214,7 +214,7 @@ GlobalRumMonitor.get().addError( -更多错误上报详情，请参阅 [Android 异常上报](/zh/rum/error-tracking/erro-reporting/android)。 +更多错误上报详情，请参阅 [Android 异常上报](/zh/rum/error-tracking/error-reporting/android)。 ### 自定义计时 diff --git a/zh/rum/sdk/ios/advanced-config.mdx b/zh/rum/sdk/ios/advanced-config.mdx index 3cfe2ae4..4b3f9bba 100644 --- a/zh/rum/sdk/ios/advanced-config.mdx +++ b/zh/rum/sdk/ios/advanced-config.mdx @@ -206,7 +206,7 @@ RUMMonitor.shared().addError( -更多错误上报详情，请参阅 [iOS 异常上报](/zh/rum/error-tracking/erro-reporting/ios)。 +更多错误上报详情，请参阅 [iOS 异常上报](/zh/rum/error-tracking/error-reporting/ios)。 ## 追踪自定义全局属性 diff --git a/zh/rum/sdk/ios/sdk-integration.mdx b/zh/rum/sdk/ios/sdk-integration.mdx index aeed6790..d1c650db 100644 --- a/zh/rum/sdk/ios/sdk-integration.mdx +++ b/zh/rum/sdk/ios/sdk-integration.mdx @@ -390,7 +390,7 @@ RUMMonitor.shared().addError( -详细的异常上报配置请参阅 [iOS 异常上报](/zh/rum/error-tracking/erro-reporting/ios)。 +详细的异常上报配置请参阅 [iOS 异常上报](/zh/rum/error-tracking/error-reporting/ios)。 ### 追踪后台事件 diff --git a/zh/stsatuspage.mdx b/zh/statuspage.mdx similarity index 100% rename from zh/stsatuspage.mdx rename to zh/statuspage.mdx From 9a120c75856023d4b090c0030c77038e03a145f2 Mon Sep 17 00:00:00 2001 From: bowen <86307842+debidong@users.noreply.github.com> Date: Fri, 9 Oct 2026 16:02:20 +0800 Subject: [PATCH 02/61] docs: remove horizontal rules placed directly under headings A '---' right under a heading detaches the heading from its content (proximity) and was used inconsistently. 4302 rules in 744 zh/en pages. --- en/ai-sre/agents.mdx | 14 ------------ en/ai-sre/apps.mdx | 18 --------------- en/ai-sre/artifacts.mdx | 16 -------------- en/ai-sre/automations.mdx | 14 ------------ en/ai-sre/context.mdx | 6 ----- en/ai-sre/environments.mdx | 18 --------------- en/ai-sre/im.mdx | 22 ------------------- en/ai-sre/init.mdx | 16 -------------- en/ai-sre/insight.mdx | 12 ---------- en/ai-sre/knowledge.mdx | 14 ------------ en/ai-sre/mcp.mdx | 14 ------------ en/ai-sre/memory.mdx | 14 ------------ en/ai-sre/overview.mdx | 14 ------------ en/ai-sre/quickstart.mdx | 10 --------- en/ai-sre/sandbox.mdx | 10 --------- en/ai-sre/sessions.mdx | 22 ------------------- en/ai-sre/skills.mdx | 12 ---------- en/compliance/service-sla.mdx | 4 ---- en/compliance/terms-of-service.mdx | 2 -- en/compliance/user-agreement.mdx | 13 ----------- en/developer/go-sdk.mdx | 20 ----------------- en/developer/mcp-server.mdx | 12 ---------- en/on-call/comparison/vs-opsgenie.mdx | 14 ------------ en/on-call/comparison/vs-pagerduty.mdx | 14 ------------ .../configuration/filter-conditions.mdx | 6 ----- en/on-call/configuration/notifications.mdx | 10 --------- .../configuration/personal-settings.mdx | 14 ------------ en/on-call/configuration/schedule.mdx | 22 ------------------- en/on-call/configuration/service-calendar.mdx | 12 ---------- .../alert-sources/aikido.mdx | 5 ----- .../alert-sources/airbrake.mdx | 6 ----- .../alert-sources/alertsite.mdx | 6 ----- .../alert-sources/aliyun-arms.mdx | 3 --- .../alert-sources/aliyun-cm-event.mdx | 3 --- .../alert-sources/aliyun-cm-metrics.mdx | 3 --- .../alert-sources/aliyun-dataworks-op.mdx | 7 ------ .../alert-sources/aliyun-prometheus.mdx | 3 --- .../alert-sources/aliyun-sls.mdx | 4 ---- .../alert-sources/amazon-inspector.mdx | 5 ----- .../alert-sources/apcupsd.mdx | 4 ---- .../alert-sources/apimetrics.mdx | 7 ------ .../alert-sources/appdynamics.mdx | 2 -- .../alert-sources/appsignal.mdx | 8 ------- .../alert-sources/argocd.mdx | 7 ------ .../alert-sources/atatus.mdx | 7 ------ .../alert-integration/alert-sources/auth0.mdx | 7 ------ .../alert-integration/alert-sources/auvik.mdx | 6 ----- .../alert-sources/aws-cloudwatch.mdx | 7 ------ .../alert-sources/aws-eventbridge.mdx | 7 ------ .../alert-sources/aws-health.mdx | 7 ------ .../alert-sources/aws-security-hub.mdx | 5 ----- .../alert-integration/alert-sources/axiom.mdx | 6 ----- .../alert-sources/azure-monitor.mdx | 9 -------- .../alert-sources/azure-service-health.mdx | 6 ----- .../alert-sources/baidu-bcm.mdx | 3 --- .../alert-sources/bgpalerter.mdx | 6 ----- .../alert-sources/bigpanda.mdx | 7 ------ .../alert-sources/bitdefender.mdx | 9 -------- .../alert-sources/bleemeo.mdx | 7 ------ .../alert-sources/blueking.mdx | 3 --- .../alert-sources/blumira.mdx | 6 ----- .../alert-sources/bugsnag.mdx | 6 ----- .../alert-sources/calibre.mdx | 7 ------ .../alert-sources/canarytokens.mdx | 8 ------- .../alert-sources/catchpoint.mdx | 5 ----- .../alert-integration/alert-sources/cato.mdx | 6 ----- .../alert-sources/censys.mdx | 6 ----- .../alert-sources/centreon.mdx | 5 ----- .../alert-sources/cert-spotter.mdx | 7 ------ .../alert-sources/cfengine.mdx | 7 ------ .../alert-sources/check-point-smartevent.mdx | 5 ----- .../alert-sources/checkly.mdx | 6 ----- .../alert-sources/checkmk.mdx | 7 ------ .../alert-sources/chronosphere.mdx | 5 ----- .../alert-sources/circonus.mdx | 5 ----- .../alert-sources/cloudamqp.mdx | 7 ------ .../alert-sources/cloudflare.mdx | 2 -- .../alert-sources/clustercontrol.mdx | 7 ------ .../alert-sources/consul.mdx | 8 ------- .../alert-sources/contrast.mdx | 6 ----- .../alert-sources/coralogix.mdx | 6 ----- .../alert-sources/coroot.mdx | 6 ----- .../alert-sources/cronicle.mdx | 7 ------ .../alert-sources/cronitor.mdx | 7 ------ .../alert-sources/crowdsec.mdx | 7 ------ .../alert-sources/crowdstrike-logscale.mdx | 7 ------ .../alert-sources/crowdstrike.mdx | 6 ----- .../alert-integration/alert-sources/ctyun.mdx | 2 -- .../alert-sources/cubeapm.mdx | 5 ----- .../alert-integration/alert-sources/dash0.mdx | 5 ----- .../alert-sources/datadog.mdx | 6 ----- .../alert-sources/datto-rmm.mdx | 6 ----- .../alert-sources/db-pull.mdx | 4 ---- .../alert-sources/dbmarlin.mdx | 6 ----- .../alert-sources/dead-mans-snitch.mdx | 7 ------ .../alert-sources/dependency-track.mdx | 7 ------ .../alert-sources/dingtalk-alert.mdx | 3 --- .../alert-integration/alert-sources/dkron.mdx | 6 ----- .../alert-sources/dolphinscheduler.mdx | 8 ------- .../alert-sources/domotz.mdx | 7 ------ .../alert-sources/dotcom-monitor.mdx | 7 ------ .../alert-sources/duplicati.mdx | 5 ----- .../alert-sources/dynatrace.mdx | 3 --- .../alert-sources/ecloud-cm.mdx | 6 ----- .../alert-sources/edge-delta.mdx | 7 ------ .../alert-sources/elastalert2.mdx | 2 -- .../alert-sources/elastic.mdx | 8 ------- .../alert-integration/alert-sources/email.mdx | 2 -- .../alert-integration/alert-sources/emqx.mdx | 4 ---- .../alert-sources/extrahop.mdx | 7 ------ .../alert-sources/fail2ban.mdx | 5 ----- .../alert-integration/alert-sources/falco.mdx | 8 ------- .../alert-sources/fastnetmon.mdx | 7 ------ .../alert-sources/firebase-crashlytics.mdx | 6 ----- .../alert-sources/firefly.mdx | 6 ----- .../alert-sources/fivetran.mdx | 6 ----- .../alert-sources/flashcat.mdx | 7 ------ .../alert-integration/alert-sources/fleet.mdx | 7 ------ .../alert-sources/flowmon-ads.mdx | 4 ---- .../alert-sources/flowtriq.mdx | 7 ------ .../alert-sources/fluxcd.mdx | 7 ------ .../alert-sources/formant.mdx | 7 ------ .../alert-sources/fortimonitor.mdx | 7 ------ .../alert-sources/fortisiem.mdx | 6 ----- .../alert-integration/alert-sources/gatus.mdx | 5 ----- .../gcp-personalized-service-health.mdx | 5 ----- .../alert-sources/ghost-inspector.mdx | 6 ----- .../alert-sources/gitguardian.mdx | 6 ----- .../alert-sources/github.mdx | 8 ------- .../alert-sources/gitlab.mdx | 7 ------ .../alert-sources/google-cloud-monitoring.mdx | 2 -- .../alert-sources/google-scc.mdx | 5 ----- .../alert-sources/grafana.mdx | 3 --- .../alert-sources/graylog.mdx | 2 -- .../alert-sources/guance.mdx | 2 -- .../alert-sources/hackerone.mdx | 6 ----- .../alert-sources/harness.mdx | 7 ------ .../alert-sources/healthchecks-io.mdx | 7 ------ .../alert-sources/hertzbeat.mdx | 7 ------ .../alert-sources/hetrixtools.mdx | 6 ----- .../alert-sources/honeybadger.mdx | 6 ----- .../alert-sources/honeycomb.mdx | 6 ----- .../alert-sources/hookdeck.mdx | 6 ----- .../alert-sources/hosted-graphite.mdx | 7 ------ .../alert-sources/http-pull.mdx | 4 ---- .../alert-sources/huawei-apm.mdx | 2 -- .../alert-sources/huawei-ces.mdx | 3 --- .../alert-sources/huawei-lts.mdx | 2 -- .../alert-integration/alert-sources/hund.mdx | 7 ------ .../alert-sources/hyperdx.mdx | 6 ----- .../alert-sources/hyperping.mdx | 7 ------ .../alert-sources/ibm-qradar.mdx | 5 ----- .../alert-sources/icinga.mdx | 7 ------ .../alert-sources/imperva.mdx | 6 ----- .../alert-sources/infisical.mdx | 5 ----- .../alert-sources/influxdata.mdx | 2 -- .../alert-sources/insightidr.mdx | 8 ------- .../alert-sources/instana.mdx | 6 ----- .../alert-sources/instatus.mdx | 7 ------ .../alert-sources/intersight.mdx | 8 ------- .../alert-sources/jdcloud.mdx | 3 --- .../alert-sources/jfrog-xray.mdx | 7 ------ .../alert-sources/jiankongbao.mdx | 2 -- .../alert-sources/jumpcloud.mdx | 6 ----- .../alert-sources/juniper-mist.mdx | 6 ----- .../alert-sources/kapacitor.mdx | 5 ----- .../alert-integration/alert-sources/keep.mdx | 1 - .../alert-integration/alert-sources/kener.mdx | 6 ----- .../alert-sources/kentik.mdx | 6 ----- .../alert-sources/komodor.mdx | 7 ------ .../alert-sources/kscloud-monitor.mdx | 3 --- .../alert-sources/kuvasz.mdx | 7 ------ .../alert-sources/lacework.mdx | 5 ----- .../alert-sources/langsmith.mdx | 6 ----- .../alert-sources/lark-alert.mdx | 3 --- .../alert-integration/alert-sources/last9.mdx | 5 ----- .../alert-integration/alert-sources/level.mdx | 6 ----- .../alert-sources/librenms.mdx | 7 ------ .../alert-sources/limacharlie.mdx | 7 ------ .../alert-sources/loadster.mdx | 7 ------ .../alert-sources/loggly.mdx | 6 ----- .../alert-sources/logicmonitor.mdx | 7 ------ .../alert-sources/logpoint.mdx | 6 ----- .../alert-sources/logrocket.mdx | 6 ----- .../alert-sources/logz-io.mdx | 6 ----- .../alert-sources/mackerel.mdx | 6 ----- .../alert-sources/meraki.mdx | 2 -- .../alert-sources/metoro.mdx | 5 ----- .../alert-integration/alert-sources/mezmo.mdx | 6 ----- .../microsoft-defender-for-cloud.mdx | 6 ----- .../alert-sources/microsoft-sentinel.mdx | 6 ----- .../alert-sources/moesif.mdx | 7 ------ .../alert-sources/mongodb-atlas.mdx | 6 ----- .../alert-sources/monitive.mdx | 7 ------ .../alert-sources/monte-carlo.mdx | 6 ----- .../alert-sources/nagios.mdx | 3 --- .../alert-sources/netbeez.mdx | 7 ------ .../alert-sources/netdata.mdx | 7 ------ .../alert-sources/new-relic.mdx | 5 ----- .../alert-integration/alert-sources/nobl9.mdx | 7 ------ .../alert-sources/nodeping.mdx | 7 ------ .../alert-integration/alert-sources/ns1.mdx | 6 ----- .../alert-sources/ntopng.mdx | 6 ----- .../alert-integration/alert-sources/nut.mdx | 4 ---- .../alert-integration/alert-sources/obkio.mdx | 6 ----- .../alert-sources/observium.mdx | 7 ------ .../alert-sources/oceanbase.mdx | 2 -- .../alert-sources/oci-monitoring.mdx | 6 ----- .../alert-integration/alert-sources/odown.mdx | 8 ------- .../alert-sources/ofelia.mdx | 6 ----- .../alert-sources/ohdear.mdx | 7 ------ .../alert-integration/alert-sources/okta.mdx | 8 ------- .../alert-sources/open-falcon.mdx | 3 --- .../alert-sources/opennms.mdx | 7 ------ .../alert-sources/openobserve.mdx | 7 ------ .../alert-sources/opensearch.mdx | 6 ----- .../alert-sources/openstatus.mdx | 6 ----- .../alert-sources/opmanager.mdx | 2 -- .../alert-sources/opnsense.mdx | 5 ----- .../alert-sources/opsgenie.mdx | 9 -------- .../alert-sources/opsview.mdx | 4 ---- .../alert-integration/alert-sources/ossec.mdx | 5 ----- .../alert-sources/pagerduty.mdx | 2 -- .../alert-sources/pandora-fms.mdx | 7 ------ .../alert-sources/panther.mdx | 5 ----- .../alert-sources/papertrail.mdx | 6 ----- .../alert-sources/peekaping.mdx | 6 ----- .../alert-sources/pgdash.mdx | 6 ----- .../alert-integration/alert-sources/phare.mdx | 5 ----- .../alert-sources/pingdom.mdx | 6 ----- .../alert-sources/postman.mdx | 6 ----- .../alert-sources/powerjob.mdx | 8 ------- .../alert-sources/projectdiscovery.mdx | 9 -------- .../alert-sources/prometheus.mdx | 5 ----- .../alert-integration/alert-sources/prtg.mdx | 7 ------ .../alert-sources/pulsetic.mdx | 7 ------ .../alert-sources/pulseway.mdx | 6 ----- .../alert-sources/raritan-px.mdx | 4 ---- .../alert-sources/raygun.mdx | 6 ----- .../alert-sources/rbltracker.mdx | 8 ------- .../alert-sources/red-hat-openshift.mdx | 5 ----- .../alert-sources/redash.mdx | 6 ----- .../alert-sources/redgate-sql-monitor.mdx | 6 ----- .../alert-sources/rizhiyi.mdx | 4 ---- .../alert-sources/robotalp.mdx | 5 ----- .../alert-sources/robusta.mdx | 6 ----- .../alert-sources/rollbar.mdx | 6 ----- .../alert-sources/searchstax.mdx | 7 ------ .../alert-sources/securityscorecard.mdx | 7 ------ .../alert-sources/sematext.mdx | 6 ----- .../alert-sources/semgrep.mdx | 7 ------ .../alert-integration/alert-sources/sensu.mdx | 7 ------ .../alert-sources/sentry.mdx | 2 -- .../alert-sources/sevone.mdx | 7 ------ .../alert-sources/signoz.mdx | 5 ----- .../alert-sources/simple-observability.mdx | 7 ------ .../alert-sources/site24x7.mdx | 6 ----- .../alert-sources/skywalking.mdx | 2 -- .../alert-integration/alert-sources/snyk.mdx | 6 ----- .../alert-sources/solarwinds-orion.mdx | 7 ------ .../alert-sources/solarwinds.mdx | 2 -- .../alert-sources/sonarqube.mdx | 6 ----- .../alert-sources/split-io.mdx | 7 ------ .../alert-sources/splunk-observability.mdx | 6 ----- .../alert-sources/splunk.mdx | 2 -- .../alert-sources/stackrox.mdx | 6 ----- .../alert-sources/standard-alert.mdx | 6 ----- .../alert-sources/statuscake.mdx | 7 ------ .../alert-sources/statusgator.mdx | 8 ------- .../alert-sources/statuspage.mdx | 7 ------ .../alert-sources/statuspal.mdx | 7 ------ .../alert-sources/stripe.mdx | 7 ------ .../alert-sources/sublime.mdx | 8 ------- .../alert-sources/sumo-logic.mdx | 5 ----- .../alert-sources/suricata.mdx | 8 ------- .../alert-sources/sysdig.mdx | 6 ----- .../alert-sources/tactical-rmm.mdx | 7 ------ .../alert-sources/tailscale.mdx | 7 ------ .../alert-sources/tencent-cls.mdx | 3 --- .../alert-sources/tencent-cm.mdx | 3 --- .../alert-sources/tencent-css.mdx | 7 ------ .../alert-sources/tencent-eventbridge.mdx | 3 --- .../alert-sources/thinkst-canary.mdx | 8 ------- .../alert-sources/thousandeyes.mdx | 6 ----- .../alert-sources/tideways.mdx | 7 ------ .../alert-sources/tracee.mdx | 6 ----- .../alert-sources/trigger-dev.mdx | 7 ------ .../alert-sources/trivy-operator.mdx | 6 ----- .../alert-sources/twilio.mdx | 7 ------ .../alert-sources/twingate.mdx | 7 ------ .../alert-sources/ucloud-cloudwatch.mdx | 3 --- .../alert-sources/updown.mdx | 8 ------- .../alert-sources/upguard.mdx | 8 ------- .../alert-sources/uptime-com.mdx | 6 ----- .../alert-sources/uptime-kuma.mdx | 3 --- .../alert-sources/uptimeobserver.mdx | 5 ----- .../alert-sources/uptimerobot.mdx | 6 ----- .../alert-sources/uptimia.mdx | 7 ------ .../alert-sources/uptrends.mdx | 7 ------ .../alert-sources/veeam-one.mdx | 5 ----- .../veeam-service-provider-console.mdx | 4 ---- .../alert-sources/veracode-sca.mdx | 7 ------ .../alert-integration/alert-sources/vigil.mdx | 6 ----- .../alert-sources/volcengine-cm-event.mdx | 2 -- .../alert-sources/volcengine-cm-metrics.mdx | 2 -- .../alert-sources/volcengine-dial.mdx | 2 -- .../alert-sources/volcengine-rtc.mdx | 2 -- .../alert-sources/volcengine-tls.mdx | 2 -- .../alert-integration/alert-sources/wazuh.mdx | 7 ------ .../alert-sources/wecom-alert.mdx | 2 -- .../alert-sources/whatap.mdx | 7 ------ .../alert-sources/whatsup-gold.mdx | 4 ---- .../alert-sources/wormly.mdx | 7 ------ .../alert-sources/xitoring.mdx | 7 ------ .../alert-sources/zabbix.mdx | 4 ---- .../alert-integration/alert-sources/zeek.mdx | 5 ----- .../alert-sources/zenoss.mdx | 6 ----- .../alert-sources/zilliz.mdx | 2 -- .../alert-sources/zstack.mdx | 2 -- .../integration/change-integration/apollo.mdx | 6 ----- .../change-integration/argo-rollouts.mdx | 6 ----- .../integration/change-integration/argocd.mdx | 6 ----- .../integration/change-integration/awx.mdx | 6 ----- .../change-integration/azure-devops.mdx | 6 ----- .../change-integration/bitbucket.mdx | 6 ----- .../change-integration/buildkite.mdx | 6 ----- .../change-integration/circleci.mdx | 6 ----- .../change-integration/coolify.mdx | 6 ----- .../integration/change-integration/env0.mdx | 6 ----- .../change-integration/expo-eas.mdx | 6 ----- .../change-integration/flagsmith.mdx | 6 ----- .../integration/change-integration/fluxcd.mdx | 6 ----- .../integration/change-integration/gitea.mdx | 6 ----- .../integration/change-integration/gitee.mdx | 6 ----- .../integration/change-integration/github.mdx | 6 ----- .../integration/change-integration/gitlab.mdx | 6 ----- .../change-integration/growthbook.mdx | 6 ----- .../change-integration/harness-fme.mdx | 6 ----- .../change-integration/hcp-terraform.mdx | 6 ----- .../integration/change-integration/heroku.mdx | 6 ----- .../change-integration/jenkins.mdx | 6 ----- .../change-integration/jfrog-artifactory.mdx | 6 ----- .../integration/change-integration/jira.mdx | 6 ----- .../change-integration/launchdarkly.mdx | 6 ----- .../change-integration/nautobot.mdx | 6 ----- .../integration/change-integration/netbox.mdx | 6 ----- .../change-integration/netlify.mdx | 6 ----- .../change-integration/octopus-deploy.mdx | 6 ----- .../integration/change-integration/pulumi.mdx | 6 ----- .../change-integration/railway.mdx | 6 ----- .../change-integration/rundeck.mdx | 6 ----- .../integration/change-integration/scalr.mdx | 6 ----- .../change-integration/semaphore.mdx | 6 ----- .../change-integration/teamcity.mdx | 6 ----- .../change-integration/unleash.mdx | 6 ----- .../integration/change-integration/vercel.mdx | 6 ----- .../change-integration/yunxiao-appstack.mdx | 6 ----- .../integration/change-integration/zadig.mdx | 6 ----- .../integration/instant-messaging/lark.mdx | 4 ---- .../integration/instant-messaging/wecom.mdx | 2 -- en/on-call/quickstart/faq.mdx | 10 --------- en/on-call/quickstart/mobile-app.mdx | 16 -------------- en/on-call/quickstart/quickstart.mdx | 14 ------------ en/on-call/statuspage/comparison.mdx | 14 ------------ en/openapi/pagination.mdx | 6 ----- en/openapi/rate-limits.mdx | 8 ------- en/platform/audit-log.mdx | 8 ------- en/platform/configure-sso.mdx | 20 ----------------- en/platform/organization-info.mdx | 12 ---------- en/platform/pricing.mdx | 12 ---------- en/platform/team-members.mdx | 10 --------- en/rum.mdx | 8 ------- zh/ai-sre/agents.mdx | 14 ------------ zh/ai-sre/apps.mdx | 18 --------------- zh/ai-sre/artifacts.mdx | 16 -------------- zh/ai-sre/automations.mdx | 14 ------------ zh/ai-sre/context.mdx | 6 ----- zh/ai-sre/environments.mdx | 18 --------------- zh/ai-sre/im.mdx | 22 ------------------- zh/ai-sre/init.mdx | 16 -------------- zh/ai-sre/insight.mdx | 12 ---------- zh/ai-sre/knowledge.mdx | 14 ------------ zh/ai-sre/mcp.mdx | 14 ------------ zh/ai-sre/memory.mdx | 14 ------------ zh/ai-sre/overview.mdx | 14 ------------ zh/ai-sre/quickstart.mdx | 10 --------- zh/ai-sre/sandbox.mdx | 10 --------- zh/ai-sre/sessions.mdx | 22 ------------------- zh/ai-sre/skills.mdx | 12 ---------- zh/compliance/service-sla.mdx | 4 ---- zh/compliance/terms-of-service.mdx | 2 -- zh/compliance/user-agreement.mdx | 13 ----------- zh/developer/go-sdk.mdx | 20 ----------------- zh/developer/mcp-server.mdx | 12 ---------- zh/on-call/comparison/vs-opsgenie.mdx | 14 ------------ zh/on-call/comparison/vs-pagerduty.mdx | 14 ------------ .../configuration/filter-conditions.mdx | 6 ----- zh/on-call/configuration/notifications.mdx | 10 --------- .../configuration/personal-settings.mdx | 14 ------------ zh/on-call/configuration/schedule.mdx | 22 ------------------- zh/on-call/configuration/service-calendar.mdx | 12 ---------- .../alert-sources/aikido.mdx | 5 ----- .../alert-sources/airbrake.mdx | 6 ----- .../alert-sources/alertsite.mdx | 6 ----- .../alert-sources/aliyun-arms.mdx | 3 --- .../alert-sources/aliyun-cm-event.mdx | 3 --- .../alert-sources/aliyun-cm-metrics.mdx | 3 --- .../alert-sources/aliyun-dataworks-op.mdx | 7 ------ .../alert-sources/aliyun-prometheus.mdx | 3 --- .../alert-sources/aliyun-sls.mdx | 4 ---- .../alert-sources/amazon-inspector.mdx | 5 ----- .../alert-sources/apcupsd.mdx | 4 ---- .../alert-sources/apimetrics.mdx | 7 ------ .../alert-sources/appdynamics.mdx | 2 -- .../alert-sources/appsignal.mdx | 8 ------- .../alert-sources/argocd.mdx | 7 ------ .../alert-sources/atatus.mdx | 7 ------ .../alert-integration/alert-sources/auth0.mdx | 7 ------ .../alert-integration/alert-sources/auvik.mdx | 6 ----- .../alert-sources/aws-cloudwatch.mdx | 7 ------ .../alert-sources/aws-eventbridge.mdx | 7 ------ .../alert-sources/aws-health.mdx | 7 ------ .../alert-sources/aws-security-hub.mdx | 5 ----- .../alert-integration/alert-sources/axiom.mdx | 6 ----- .../alert-sources/azure-monitor.mdx | 9 -------- .../alert-sources/azure-service-health.mdx | 6 ----- .../alert-sources/baidu-bcm.mdx | 3 --- .../alert-sources/bgpalerter.mdx | 6 ----- .../alert-sources/bigpanda.mdx | 7 ------ .../alert-sources/bitdefender.mdx | 9 -------- .../alert-sources/bleemeo.mdx | 7 ------ .../alert-sources/blueking.mdx | 3 --- .../alert-sources/blumira.mdx | 6 ----- .../alert-sources/bugsnag.mdx | 6 ----- .../alert-sources/calibre.mdx | 7 ------ .../alert-sources/canarytokens.mdx | 8 ------- .../alert-sources/catchpoint.mdx | 5 ----- .../alert-integration/alert-sources/cato.mdx | 6 ----- .../alert-sources/censys.mdx | 6 ----- .../alert-sources/centreon.mdx | 5 ----- .../alert-sources/cert-spotter.mdx | 7 ------ .../alert-sources/cfengine.mdx | 7 ------ .../alert-sources/check-point-smartevent.mdx | 5 ----- .../alert-sources/checkly.mdx | 6 ----- .../alert-sources/checkmk.mdx | 7 ------ .../alert-sources/chronosphere.mdx | 5 ----- .../alert-sources/circonus.mdx | 5 ----- .../alert-sources/cloudamqp.mdx | 7 ------ .../alert-sources/cloudflare.mdx | 2 -- .../alert-sources/clustercontrol.mdx | 7 ------ .../alert-sources/consul.mdx | 8 ------- .../alert-sources/contrast.mdx | 6 ----- .../alert-sources/coralogix.mdx | 6 ----- .../alert-sources/coroot.mdx | 6 ----- .../alert-sources/cronicle.mdx | 7 ------ .../alert-sources/cronitor.mdx | 7 ------ .../alert-sources/crowdsec.mdx | 7 ------ .../alert-sources/crowdstrike-logscale.mdx | 7 ------ .../alert-sources/crowdstrike.mdx | 6 ----- .../alert-integration/alert-sources/ctyun.mdx | 2 -- .../alert-sources/cubeapm.mdx | 5 ----- .../alert-integration/alert-sources/dash0.mdx | 5 ----- .../alert-sources/datadog.mdx | 6 ----- .../alert-sources/datto-rmm.mdx | 6 ----- .../alert-sources/db-pull.mdx | 4 ---- .../alert-sources/dbmarlin.mdx | 6 ----- .../alert-sources/dead-mans-snitch.mdx | 7 ------ .../alert-sources/dependency-track.mdx | 7 ------ .../alert-sources/dingtalk-alert.mdx | 3 --- .../alert-integration/alert-sources/dkron.mdx | 6 ----- .../alert-sources/dolphinscheduler.mdx | 8 ------- .../alert-sources/domotz.mdx | 7 ------ .../alert-sources/dotcom-monitor.mdx | 7 ------ .../alert-sources/duplicati.mdx | 5 ----- .../alert-sources/dynatrace.mdx | 2 -- .../alert-sources/ecloud-cm.mdx | 6 ----- .../alert-sources/edge-delta.mdx | 7 ------ .../alert-sources/elastalert2.mdx | 1 - .../alert-sources/elastic.mdx | 8 ------- .../alert-integration/alert-sources/email.mdx | 2 -- .../alert-integration/alert-sources/emqx.mdx | 4 ---- .../alert-sources/extrahop.mdx | 7 ------ .../alert-sources/fail2ban.mdx | 5 ----- .../alert-integration/alert-sources/falco.mdx | 8 ------- .../alert-sources/fastnetmon.mdx | 7 ------ .../alert-sources/firebase-crashlytics.mdx | 6 ----- .../alert-sources/firefly.mdx | 6 ----- .../alert-sources/fivetran.mdx | 6 ----- .../alert-sources/flashcat.mdx | 14 ------------ .../alert-integration/alert-sources/fleet.mdx | 7 ------ .../alert-sources/flowmon-ads.mdx | 4 ---- .../alert-sources/flowtriq.mdx | 7 ------ .../alert-sources/fluxcd.mdx | 7 ------ .../alert-sources/formant.mdx | 7 ------ .../alert-sources/fortimonitor.mdx | 7 ------ .../alert-sources/fortisiem.mdx | 6 ----- .../alert-integration/alert-sources/gatus.mdx | 5 ----- .../gcp-personalized-service-health.mdx | 5 ----- .../alert-sources/ghost-inspector.mdx | 6 ----- .../alert-sources/gitguardian.mdx | 6 ----- .../alert-sources/github.mdx | 8 ------- .../alert-sources/gitlab.mdx | 7 ------ .../alert-sources/google-cloud-monitoring.mdx | 2 -- .../alert-sources/google-scc.mdx | 5 ----- .../alert-sources/grafana.mdx | 3 --- .../alert-sources/graylog.mdx | 2 -- .../alert-sources/guance.mdx | 2 -- .../alert-sources/hackerone.mdx | 6 ----- .../alert-sources/harness.mdx | 7 ------ .../alert-sources/healthchecks-io.mdx | 7 ------ .../alert-sources/hertzbeat.mdx | 7 ------ .../alert-sources/hetrixtools.mdx | 6 ----- .../alert-sources/honeybadger.mdx | 6 ----- .../alert-sources/honeycomb.mdx | 6 ----- .../alert-sources/hookdeck.mdx | 6 ----- .../alert-sources/hosted-graphite.mdx | 7 ------ .../alert-sources/http-pull.mdx | 4 ---- .../alert-sources/huawei-apm.mdx | 2 -- .../alert-sources/huawei-ces.mdx | 3 --- .../alert-sources/huawei-lts.mdx | 2 -- .../alert-integration/alert-sources/hund.mdx | 7 ------ .../alert-sources/hyperdx.mdx | 6 ----- .../alert-sources/hyperping.mdx | 7 ------ .../alert-sources/ibm-qradar.mdx | 5 ----- .../alert-sources/icinga.mdx | 7 ------ .../alert-sources/imperva.mdx | 6 ----- .../alert-sources/infisical.mdx | 5 ----- .../alert-sources/influxdata.mdx | 2 -- .../alert-sources/insightidr.mdx | 8 ------- .../alert-sources/instana.mdx | 6 ----- .../alert-sources/instatus.mdx | 7 ------ .../alert-sources/intersight.mdx | 8 ------- .../alert-sources/jdcloud.mdx | 3 --- .../alert-sources/jfrog-xray.mdx | 7 ------ .../alert-sources/jiankongbao.mdx | 2 -- .../alert-sources/jumpcloud.mdx | 6 ----- .../alert-sources/juniper-mist.mdx | 6 ----- .../alert-sources/kapacitor.mdx | 5 ----- .../alert-integration/alert-sources/keep.mdx | 1 - .../alert-integration/alert-sources/kener.mdx | 6 ----- .../alert-sources/kentik.mdx | 6 ----- .../alert-sources/komodor.mdx | 7 ------ .../alert-sources/kscloud-monitor.mdx | 3 --- .../alert-sources/kuvasz.mdx | 7 ------ .../alert-sources/lacework.mdx | 5 ----- .../alert-sources/langsmith.mdx | 6 ----- .../alert-sources/lark-alert.mdx | 3 --- .../alert-integration/alert-sources/last9.mdx | 5 ----- .../alert-integration/alert-sources/level.mdx | 6 ----- .../alert-sources/librenms.mdx | 7 ------ .../alert-sources/limacharlie.mdx | 7 ------ .../alert-sources/loadster.mdx | 7 ------ .../alert-sources/loggly.mdx | 6 ----- .../alert-sources/logicmonitor.mdx | 7 ------ .../alert-sources/logpoint.mdx | 6 ----- .../alert-sources/logrocket.mdx | 6 ----- .../alert-sources/logz-io.mdx | 6 ----- .../alert-sources/mackerel.mdx | 6 ----- .../alert-sources/meraki.mdx | 2 -- .../alert-sources/metoro.mdx | 5 ----- .../alert-integration/alert-sources/mezmo.mdx | 6 ----- .../microsoft-defender-for-cloud.mdx | 6 ----- .../alert-sources/microsoft-sentinel.mdx | 6 ----- .../alert-sources/moesif.mdx | 7 ------ .../alert-sources/mongodb-atlas.mdx | 6 ----- .../alert-sources/monitive.mdx | 7 ------ .../alert-sources/monte-carlo.mdx | 6 ----- .../alert-sources/nagios.mdx | 3 --- .../alert-sources/netbeez.mdx | 7 ------ .../alert-sources/netdata.mdx | 7 ------ .../alert-sources/new-relic.mdx | 6 ----- .../alert-integration/alert-sources/nobl9.mdx | 7 ------ .../alert-sources/nodeping.mdx | 7 ------ .../alert-integration/alert-sources/ns1.mdx | 6 ----- .../alert-sources/ntopng.mdx | 6 ----- .../alert-integration/alert-sources/nut.mdx | 4 ---- .../alert-integration/alert-sources/obkio.mdx | 6 ----- .../alert-sources/observium.mdx | 7 ------ .../alert-sources/oceanbase.mdx | 3 --- .../alert-sources/oci-monitoring.mdx | 6 ----- .../alert-integration/alert-sources/odown.mdx | 8 ------- .../alert-sources/ofelia.mdx | 6 ----- .../alert-sources/ohdear.mdx | 7 ------ .../alert-integration/alert-sources/okta.mdx | 8 ------- .../alert-sources/open-falcon.mdx | 3 --- .../alert-sources/opennms.mdx | 7 ------ .../alert-sources/openobserve.mdx | 7 ------ .../alert-sources/opensearch.mdx | 6 ----- .../alert-sources/openstatus.mdx | 6 ----- .../alert-sources/opmanager.mdx | 2 -- .../alert-sources/opnsense.mdx | 5 ----- .../alert-sources/opsgenie.mdx | 9 -------- .../alert-sources/opsview.mdx | 4 ---- .../alert-integration/alert-sources/ossec.mdx | 5 ----- .../alert-sources/pagerduty.mdx | 2 -- .../alert-sources/pandora-fms.mdx | 7 ------ .../alert-sources/panther.mdx | 5 ----- .../alert-sources/papertrail.mdx | 6 ----- .../alert-sources/peekaping.mdx | 6 ----- .../alert-sources/pgdash.mdx | 6 ----- .../alert-integration/alert-sources/phare.mdx | 5 ----- .../alert-sources/pingdom.mdx | 6 ----- .../alert-sources/postman.mdx | 6 ----- .../alert-sources/powerjob.mdx | 8 ------- .../alert-sources/projectdiscovery.mdx | 9 -------- .../alert-sources/prometheus.mdx | 5 ----- .../alert-integration/alert-sources/prtg.mdx | 7 ------ .../alert-sources/pulsetic.mdx | 7 ------ .../alert-sources/pulseway.mdx | 6 ----- .../alert-sources/raritan-px.mdx | 4 ---- .../alert-sources/raygun.mdx | 6 ----- .../alert-sources/rbltracker.mdx | 8 ------- .../alert-sources/red-hat-openshift.mdx | 5 ----- .../alert-sources/redash.mdx | 6 ----- .../alert-sources/redgate-sql-monitor.mdx | 6 ----- .../alert-sources/rizhiyi.mdx | 4 ---- .../alert-sources/robotalp.mdx | 5 ----- .../alert-sources/robusta.mdx | 6 ----- .../alert-sources/rollbar.mdx | 6 ----- .../alert-sources/searchstax.mdx | 7 ------ .../alert-sources/securityscorecard.mdx | 7 ------ .../alert-sources/sematext.mdx | 6 ----- .../alert-sources/semgrep.mdx | 7 ------ .../alert-integration/alert-sources/sensu.mdx | 7 ------ .../alert-sources/sentry.mdx | 2 -- .../alert-sources/sevone.mdx | 7 ------ .../alert-sources/signoz.mdx | 5 ----- .../alert-sources/simple-observability.mdx | 7 ------ .../alert-sources/site24x7.mdx | 6 ----- .../alert-sources/skywalking.mdx | 2 -- .../alert-integration/alert-sources/snyk.mdx | 6 ----- .../alert-sources/solarwinds-orion.mdx | 7 ------ .../alert-sources/solarwinds.mdx | 2 -- .../alert-sources/sonarqube.mdx | 6 ----- .../alert-sources/split-io.mdx | 7 ------ .../alert-sources/splunk-observability.mdx | 6 ----- .../alert-sources/splunk.mdx | 2 -- .../alert-sources/stackrox.mdx | 6 ----- .../alert-sources/standard-alert.mdx | 6 ----- .../alert-sources/statuscake.mdx | 7 ------ .../alert-sources/statusgator.mdx | 8 ------- .../alert-sources/statuspage.mdx | 7 ------ .../alert-sources/statuspal.mdx | 7 ------ .../alert-sources/stripe.mdx | 7 ------ .../alert-sources/sublime.mdx | 8 ------- .../alert-sources/sumo-logic.mdx | 5 ----- .../alert-sources/suricata.mdx | 8 ------- .../alert-sources/sysdig.mdx | 6 ----- .../alert-sources/tactical-rmm.mdx | 7 ------ .../alert-sources/tailscale.mdx | 7 ------ .../alert-sources/tencent-cls.mdx | 3 --- .../alert-sources/tencent-cm.mdx | 3 --- .../alert-sources/tencent-css.mdx | 7 ------ .../alert-sources/tencent-eventbridge.mdx | 3 --- .../alert-sources/thinkst-canary.mdx | 8 ------- .../alert-sources/thousandeyes.mdx | 6 ----- .../alert-sources/tideways.mdx | 7 ------ .../alert-sources/tracee.mdx | 6 ----- .../alert-sources/trigger-dev.mdx | 7 ------ .../alert-sources/trivy-operator.mdx | 6 ----- .../alert-sources/twilio.mdx | 7 ------ .../alert-sources/twingate.mdx | 7 ------ .../alert-sources/ucloud-cloudwatch.mdx | 3 --- .../alert-sources/updown.mdx | 8 ------- .../alert-sources/upguard.mdx | 8 ------- .../alert-sources/uptime-com.mdx | 6 ----- .../alert-sources/uptime-kuma.mdx | 3 --- .../alert-sources/uptimeobserver.mdx | 5 ----- .../alert-sources/uptimerobot.mdx | 6 ----- .../alert-sources/uptimia.mdx | 7 ------ .../alert-sources/uptrends.mdx | 7 ------ .../alert-sources/veeam-one.mdx | 5 ----- .../veeam-service-provider-console.mdx | 4 ---- .../alert-sources/veracode-sca.mdx | 7 ------ .../alert-integration/alert-sources/vigil.mdx | 6 ----- .../alert-sources/volcengine-cm-event.mdx | 2 -- .../alert-sources/volcengine-cm-metrics.mdx | 2 -- .../alert-sources/volcengine-dial.mdx | 2 -- .../alert-sources/volcengine-rtc.mdx | 3 --- .../alert-sources/volcengine-tls.mdx | 2 -- .../alert-integration/alert-sources/wazuh.mdx | 7 ------ .../alert-sources/wecom-alert.mdx | 2 -- .../alert-sources/whatap.mdx | 7 ------ .../alert-sources/whatsup-gold.mdx | 4 ---- .../alert-sources/wormly.mdx | 7 ------ .../alert-sources/xitoring.mdx | 7 ------ .../alert-sources/zabbix.mdx | 2 -- .../alert-integration/alert-sources/zeek.mdx | 5 ----- .../alert-sources/zenoss.mdx | 6 ----- .../alert-sources/zilliz.mdx | 2 -- .../alert-sources/zstack.mdx | 2 -- .../integration/change-integration/apollo.mdx | 6 ----- .../change-integration/argo-rollouts.mdx | 6 ----- .../integration/change-integration/argocd.mdx | 6 ----- .../integration/change-integration/awx.mdx | 6 ----- .../change-integration/azure-devops.mdx | 6 ----- .../change-integration/bitbucket.mdx | 6 ----- .../change-integration/buildkite.mdx | 6 ----- .../change-integration/circleci.mdx | 6 ----- .../change-integration/coolify.mdx | 6 ----- .../integration/change-integration/env0.mdx | 6 ----- .../change-integration/expo-eas.mdx | 6 ----- .../change-integration/flagsmith.mdx | 6 ----- .../integration/change-integration/fluxcd.mdx | 6 ----- .../integration/change-integration/gitea.mdx | 6 ----- .../integration/change-integration/gitee.mdx | 6 ----- .../integration/change-integration/github.mdx | 6 ----- .../integration/change-integration/gitlab.mdx | 6 ----- .../change-integration/growthbook.mdx | 6 ----- .../change-integration/harness-fme.mdx | 6 ----- .../change-integration/hcp-terraform.mdx | 6 ----- .../integration/change-integration/heroku.mdx | 6 ----- .../change-integration/jenkins.mdx | 6 ----- .../change-integration/jfrog-artifactory.mdx | 6 ----- .../integration/change-integration/jira.mdx | 6 ----- .../change-integration/launchdarkly.mdx | 6 ----- .../change-integration/nautobot.mdx | 6 ----- .../integration/change-integration/netbox.mdx | 6 ----- .../change-integration/netlify.mdx | 6 ----- .../change-integration/octopus-deploy.mdx | 6 ----- .../integration/change-integration/pulumi.mdx | 6 ----- .../change-integration/railway.mdx | 6 ----- .../change-integration/rundeck.mdx | 6 ----- .../integration/change-integration/scalr.mdx | 6 ----- .../change-integration/semaphore.mdx | 6 ----- .../change-integration/teamcity.mdx | 6 ----- .../change-integration/unleash.mdx | 6 ----- .../integration/change-integration/vercel.mdx | 6 ----- .../change-integration/yunxiao-appstack.mdx | 6 ----- .../integration/change-integration/zadig.mdx | 6 ----- .../integration/instant-messaging/lark.mdx | 4 ---- .../integration/instant-messaging/wecom.mdx | 2 -- zh/on-call/quickstart/faq.mdx | 10 --------- zh/on-call/quickstart/mobile-app.mdx | 16 -------------- zh/on-call/quickstart/quickstart.mdx | 14 ------------ zh/on-call/statuspage/comparison.mdx | 14 ------------ zh/openapi/pagination.mdx | 6 ----- zh/openapi/rate-limits.mdx | 8 ------- zh/platform/audit-log.mdx | 8 ------- zh/platform/configure-sso.mdx | 20 ----------------- zh/platform/organization-info.mdx | 12 ---------- zh/platform/pricing.mdx | 12 ---------- zh/platform/team-members.mdx | 10 --------- zh/rum.mdx | 10 --------- 744 files changed, 4824 deletions(-) diff --git a/en/ai-sre/agents.mdx b/en/ai-sre/agents.mdx index 42a3d889..80db844c 100644 --- a/en/ai-sre/agents.mdx +++ b/en/ai-sre/agents.mdx @@ -11,8 +11,6 @@ sidebarTitle: Agent ## Overview ---- - **Agent** is the resource category that connects AI SRE to external agent ecosystems. The currently supported type is **A2A (Agent-to-Agent)** — a standard protocol that lets different agents call one another (more agent types may be added later). A2A works in two directions: @@ -38,8 +36,6 @@ The A2A agent list and management entry point are on the **Customize → Plugins ## Subagent ---- - A **Subagent** is a platform **built-in** task executor. During an investigation, AI SRE can **dispatch** a self-contained subtask to a Subagent that completes it independently — dispatch always goes through the single long-running tool `agent_dispatch`, rather than exposing a separate tool per Subagent. The platform ships several **bootstrap Subagents** that work out of the box: @@ -71,8 +67,6 @@ The platform ships several **bootstrap Subagents** that work out of the box: ## Registering an Outbound A2A Agent ---- - On the A2A Agents list page, click **Add A2A Agent** and fill in the form: | Field | Type | Default | Description | @@ -254,8 +248,6 @@ Use HTTPS for member authorization (OAuth 2.1) discovery whenever possible. Enab ## Inbound: Letting External Agents Call AI SRE ---- - Expand the "**Let External Agents Call Flashduty's AI SRE**" panel at the top of the A2A Agents page to get the **Agent Card** URL for this account's AI SRE: ``` @@ -286,8 +278,6 @@ When a session **enters via an incident route** (e.g., AI SRE is triggered from ## Creating and Managing ---- - The full lifecycle of A2A agents is managed on the **Customize → Plugins → Agents** page. @@ -310,8 +300,6 @@ The full lifecycle of A2A agents is managed on the **Customize → Plugins → A ## Scope ---- - A2A agents share the same **two-level scope** model as other resources (skills, Knowledge, MCP, environments), divided into account level and team level. In the console UI, the account-level option is labeled "**Shared**" / "**Shared scope**" — synonymous with account level (visible account-wide): | Scope | Visibility | @@ -327,8 +315,6 @@ A2A agents share the same **two-level scope** model as other resources (skills, ## Related Pages ---- - Observe A2A delegation task cards and their sub-session panels within a session. diff --git a/en/ai-sre/apps.mdx b/en/ai-sre/apps.mdx index 1049e34e..557443a1 100644 --- a/en/ai-sre/apps.mdx +++ b/en/ai-sre/apps.mdx @@ -11,16 +11,12 @@ sidebarTitle: Apps ## Overview ---- - **Apps** is where you manage **authorized external applications**. Each external application appears as a **card** — you authorize it, manage its installations, and enable / disable or revoke it right from its card. Apps includes **GitHub**, **GitLab**, and **Kubernetes Apps**. GitHub and GitLab authorize access to code repositories: AI SRE can read code, investigate changes / commits / PRs (MRs on GitLab), and, when asked, fix a bug or open a PR / MR or issue. A Kubernetes App connects a selected Kubernetes cluster to AI SRE and limits the agent to the configured namespaces and permission level. ## Main Scenario: Letting the Cloud Sandbox Reach Your Repositories ---- - AI SRE sessions run in a **Flashduty cloud sandbox** by default. The sandbox is a clean, isolated, ephemeral environment that **carries none of your git credentials** — which is exactly what an App solves. Once you authorize the GitHub App or the GitLab App, the agent inside the sandbox can clone your repositories, read diffs, and open PRs / MRs, **without you handing it any password or token**; its access is limited to the repositories you granted, with only the least privilege needed to do the work. **This is what both Apps are mainly for.** @@ -33,8 +29,6 @@ A RUM application can also record the repositories that build it (several may be ## Where to Find It ---- - Go to **AI SRE → Customize → Plugins → Apps**. The Plugins group in the Customize sidebar lists Overview / Apps / Skill / MCP / Agents in that order, and clicking **Customize** opens **Overview** by default. @@ -43,8 +37,6 @@ Viewing the Apps page requires the appropriate permission; without it, the entry ## Kubernetes Apps ---- - A Kubernetes App connects an in-cluster agent to AI SRE. After installation, AI SRE can query cluster information and use the available Kubernetes tools within the namespaces and permission boundaries you configure. ### Create and install @@ -97,8 +89,6 @@ You can edit the cluster name, scope, and namespace access from the Kubernetes A ## The GitHub App ---- - The following walks through **GitHub** first — authorization, installation management, and adjusting repository access; **GitLab** follows in the next section. ### Connecting a GitHub Organization @@ -154,8 +144,6 @@ The organization is already connected, but you want AI SRE to reach more of its ## The GitLab App ---- - The **GitLab** App connects a GitLab instance — **GitLab.com**, **JihuLab** (GitLab's China distribution, SaaS at jihulab.com or a private deployment), or any other **self-managed** instance of your own. The connection method is **exactly the same for all of them**: register an OAuth application on that instance first, then authorize. Once authorized, AI SRE can read code and investigate changes / MRs, and — when you ask — file an issue or open an MR, in the repositories you authorized. Just like GitHub, **you never paste a personal token**: once Flashduty gets an OAuth grant, it provisions a dedicated bot identity for your account to do the actual work. ### Connecting a GitLab Instance @@ -213,8 +201,6 @@ The GitLab card shows the connected instance's address and status. ## How AI SRE Works Inside a Repository ---- - After authorization, you need no extra configuration. When you ask AI SRE to work on a task in a repository during a session, it works like an engineer joining the project — understand first, then change, then verify. This behavior is governed by the built-in `github` Skill and `gitlab` Skill respectively. **Typical actions** @@ -235,16 +221,12 @@ If the agent reports it cannot access a repository in a cloud session, it usuall ## Permissions & Scope ---- - **Authorize** and **revoke / disconnect** are **account-level** operations for both the GitHub App and the GitLab App. **The account is the only security boundary**; the team here is just an ownership / audit tag: any account member with the corresponding permission can authorize, revoke / disconnect, or enable / disable the whole App; when a session needs a repository, it obtains access from the account's currently active installation. Members of an account share one authorization — consistent with AI SRE's "usage = account-level, ownership = team tag" model for other resources. The two Apps' scope models differ slightly: the **GitHub App** lets the same account install multiple organizations, each enabled / revoked independently; the **GitLab App** lets an account connect **only one** GitLab instance **at a time** — switching to a different instance requires disconnecting the current one first. ## Related Pages ---- - Connect external tools and data sources via the Model Context Protocol. diff --git a/en/ai-sre/artifacts.mdx b/en/ai-sre/artifacts.mdx index 0b732859..2a0a2be8 100644 --- a/en/ai-sre/artifacts.mdx +++ b/en/ai-sre/artifacts.mdx @@ -11,8 +11,6 @@ sidebarTitle: Artifacts ## Overview ---- - An artifact is a file AI SRE produces in a session with the `present_files` tool and then publishes to the artifact gallery. There are two publish paths, and they accept different types: - **The agent's `publish_artifact` tool**: publishes HTML / Markdown documents only (`.html` `.htm` `.md` `.markdown`) — a self-contained report or page, most typically the operational insight report generated by typing `/insight` in a session. Every other type is rejected with `unsupported_format`. @@ -39,8 +37,6 @@ The artifact gallery has no entry point for manually uploading or creating files ## List Page ---- - ### Search and scope filter - **Search box**: fuzzy-search published artifacts by title; the query fires automatically 300ms after you stop typing. @@ -109,8 +105,6 @@ Separately, any file shown in a session with `present_files` also has a "Publish ## Card Actions ---- - The "More actions" menu on each card offers: | Action | Notes | @@ -124,8 +118,6 @@ The "More actions" menu on each card offers: ## Detail Page ---- - The detail page route is `/ai-sre/artifacts/:artifactId`. The top toolbar offers: - **Title**: if you have edit permission, click the title to edit it inline (no separate form) — press Enter to save, Esc to cancel; @@ -149,8 +141,6 @@ On a phone the detail page degrades to a **read-only reader**: the title is no l ## Share an artifact ---- - The **Share** button in the detail page toolbar opens the share panel. **Manage permission** at the top lists who can manage sharing for this artifact (the creator is labeled "Owner"; team artifacts also list team members). **Visibility** below offers two modes: | Mode | Who can open it | Content | @@ -188,8 +178,6 @@ Artifacts larger than **16 MiB** can't generate a public link — you'll see a n ## Update a published artifact ---- - Republishing the same file does **not** silently overwrite a published artifact. When the agent updates one with `publish_artifact`, it must pass both the artifact's `artifact_id` and the `if_revision` returned by the previous publication (an opaque revision fingerprint shaped like `rev_…`): | Case | Result envelope | Outcome | @@ -210,8 +198,6 @@ A few more details: ## Permissions ---- - Whether an artifact is editable (rename, change scope, delete) is determined by the `can_edit` field returned by the backend. Any one of the following grants management access: | Condition | Notes | @@ -228,8 +214,6 @@ This differs from the automation rule permission model: the account Owner / admi ## Related Pages ---- - Learn how sessions surface files with the present_files tool — the source of every published artifact. diff --git a/en/ai-sre/automations.mdx b/en/ai-sre/automations.mdx index 644ffa5b..6795ffc6 100644 --- a/en/ai-sre/automations.mdx +++ b/en/ai-sre/automations.mdx @@ -11,8 +11,6 @@ sidebarTitle: Automations ## Overview ---- - An automation lets AI SRE run a **hidden session** on a cadence you set. The session does not appear in the session list in the left sidebar of the console; instead it runs in the background, driven by a fixed **task prompt**, to have the agent complete its work and produce results such as routine inspections, operational insights, or incident post-mortems. Each automation is a **rule**. A rule carries at least one trigger: @@ -31,8 +29,6 @@ Every run produced by an automation is, at its core, still an AI SRE session — ## Creating an Automation ---- - The page header offers two creation entry points: an outline-style **Create via chat** button that jumps to the chat page with a prefilled prompt — "Let's create an automation task. First explain how automation tasks work. Then ask me questions to figure out what task I need to schedule and when it should run." — letting the agent work out the task content and trigger through conversation, skipping the form; and a primary-style **Create** button that opens a start panel with two entry points: @@ -48,8 +44,6 @@ Either entry point leads to the same configuration form. ## Configuration Fields ---- - The configuration form has the following fields: | Field | Required | Notes | @@ -65,8 +59,6 @@ For **Environment**, "Auto" has the backend pick the best available environment ## Triggers ---- - A rule must have **at least one trigger** configured. The current console form exposes **Schedule**, **Call via API**, and **On-call incident** in the "Triggers" section, and all three can be enabled at the same time. ### Schedule (cron) @@ -199,8 +191,6 @@ The similarity comparison depends on the account's AIOps capability and on a Pro ## Run History ---- - Every rule keeps its run history. Clicking anywhere on the rule row (there is no dedicated history icon) opens the rule's detail page at `/ai-sre/automations/:ruleId`: the left column shows "Configuration" and the right column shows "Run History", side by side. The right column has its own **Run now** button at the top, so you can trigger a run directly from the detail page. Run history is shown as a table with these columns: @@ -258,8 +248,6 @@ Run history is embedded in the rule's detail page, and opening the detail page i ## Management and Permissions ---- - ### Enable / Disable, Edit, and Delete Each rule offers a set of actions in the **Actions** column: @@ -298,8 +286,6 @@ The account is the only security perimeter at runtime; the team is an ownership ## Related Pages ---- - Learn how a session holds one complete conversation — every run produced by an automation is, at its core, a hidden session. diff --git a/en/ai-sre/context.mdx b/en/ai-sre/context.mdx index aa475732..fb992fe4 100644 --- a/en/ai-sre/context.mdx +++ b/en/ai-sre/context.mdx @@ -11,8 +11,6 @@ sidebarTitle: Learn about Context ## What context is ---- - Context is the material AI SRE can reuse across troubleshooting sessions. It has two parts, each with its own page under the **Context** group of the **AI SRE → Customize** sidebar. - **[Knowledge](/en/ai-sre/knowledge)** is maintained by people. It describes how this environment runs: a guide named `DUTY.md`, plus runbooks, service lists, and similar files. A session reads the guide first and opens the other files when it needs them. Entry: **AI SRE → Customize → Context → Knowledge**. @@ -22,8 +20,6 @@ Both pages have an input box at the bottom: write what to change, and the consol ## Three scopes ---- - Both kinds of material are organized by scope, but they support different scopes. | Scope | Memory | Knowledge | @@ -36,8 +32,6 @@ Personal scope has no knowledge. Shared scope has no memory. ## Read next ---- - How the guide, runbooks, and files are organized, and how the assistant reads them in a session. diff --git a/en/ai-sre/environments.mdx b/en/ai-sre/environments.mdx index b0b8904e..8eaa9b6d 100644 --- a/en/ai-sre/environments.mdx +++ b/en/ai-sre/environments.mdx @@ -11,8 +11,6 @@ sidebarTitle: Environments ## Overview ---- - An **Environment** is where AI SRE agents actually execute actions. Every tool call the agent makes, including running commands, reading and writing files, running Skills, and connecting to MCP services, happens inside an Environment. AI SRE provides two types of Environments: @@ -36,8 +34,6 @@ The console record is called an **Environment**. The process running on your mac ## Cloud sandbox ---- - The cloud Sandbox is a temporary execution container managed by Flashduty. It is best for quick starts, demos, and investigations that do not need access to your private network. You do not install a process or maintain a machine. Use the cloud Sandbox when: @@ -55,8 +51,6 @@ For lifecycle, egress boundaries, and session-selection details, see [Sandbox](/ ## Cloud environment templates ---- - A cloud environment template is a reusable, predefined configuration for the Flashduty-managed cloud Sandbox: egress policy, environment variables, and a setup script. If a session's cloud Sandbox has no template bound, it starts with the system default configuration; once a template is bound, new Sandboxes start with that template's configuration. Go to **AI SRE → Customize → Environments → Cloud** to view, create, edit, or delete cloud environment templates. @@ -99,8 +93,6 @@ Cloud environment templates only configure egress, environment variables, and th ## BYOC Runner ---- - A BYOC (Bring Your Own Compute) Runner is a `flashduty-runner` process that you deploy on your own machine. It keeps a persistent WebSocket connection to AI SRE. When it receives work, it runs commands, reads and writes files, executes Skills, and connects to MCP services that are reachable from that machine. The value of BYOC Runner comes from where execution happens: @@ -295,8 +287,6 @@ Uninstall commands are also in the setup guide, and differ by installation metho ## Permission Configuration ---- - By default, Runner uses an allow-all rule — the same trust model as running the AI model directly in your own shell: ```yaml @@ -411,8 +401,6 @@ So the real file-access boundary is the **OS user** the Runner runs as, plus the ## Selecting an environment in a session ---- - The environment selector at the bottom of the chat input decides where a new session executes: | Option | Meaning | @@ -438,8 +426,6 @@ A dispatched subagent brings its own **child session**, whose execution-environm ## Scope ---- - Each BYOC Environment has Shared or team-level scope: | Scope | Visibility | @@ -459,8 +445,6 @@ The account remains the runtime security boundary, but team scope also participa ## Troubleshooting ---- - When troubleshooting Runner issues, start with the **Status** and **Last heartbeat** columns in the self-hosted environment list. @@ -484,8 +468,6 @@ Fastest split: **Offline / Pending** points to the Runner-to-AI-SRE connection; ## Related pages ---- - Learn the cloud Sandbox lifecycle, use cases, and egress boundary. diff --git a/en/ai-sre/im.mdx b/en/ai-sre/im.mdx index f5a6684b..f066c2a9 100644 --- a/en/ai-sre/im.mdx +++ b/en/ai-sre/im.mdx @@ -11,8 +11,6 @@ sidebarTitle: IM Platform ## Overview ---- - Incident response usually happens right inside your IM group — alerts come in, the team discusses in the channel, and someone spins up a war room. AI SRE puts the agent directly into that collaboration chain: **you never have to switch to the console; you can summon it from IM to investigate**, and your teammates can follow every step of its analysis in real time. AI SRE's IM integration has two trigger modes: @@ -28,8 +26,6 @@ AI SRE's IM integration has two trigger modes: ## Supported IM Platforms ---- - AI SRE's IM interaction covers four major platforms. Each platform supports inbound @mentions (webhook), historical message reads, and outbound replies: | Platform | Group @mention | Direct message (DM) | Processing receipt | War room auto-diagnosis | @@ -47,8 +43,6 @@ IM interaction requires that you have already connected the corresponding platfo ## AI SRE Settings in IM Integrations ---- - Open the corresponding IM integration under **On-call → Integration Center → Integration List → Instant Messaging** and configure its AI SRE behavior under **Enhanced features**. The following switches are on by default: - **Automatically start AI incident analysis**: available after you enable War Room. When the integration creates a war room, AI SRE starts one preliminary diagnosis and posts the result back to the room. @@ -61,8 +55,6 @@ If AI SRE is not enabled for the account, these switches do not take effect. Aft ## @Mention Summon ---- - In a connected IM group where **Allow AI SRE conversations in IM** is enabled, **@mention the bot** and type your question (for example, "@AI SRE check why the payment service's 5xx rate is spiking") — the message is forwarded to AI SRE for processing via the platform webhook: @@ -114,8 +106,6 @@ A single reply also has a soft reading-length budget: when it is too long, `repl ## War Room Auto-Diagnosis ---- - When you open a **war room** for an incident in IM and the integration keeps **Automatically start AI incident analysis** enabled, AI SRE intervenes automatically — no one needs to @mention it: @@ -136,8 +126,6 @@ War room auto-diagnosis is bound to the incident context: when the investigation ## Standing Tasks and the Monitoring Card ---- - When the agent's current turn ends but a **standing process-type task** it started is still running (e.g. a monitor watcher or a background command), AI SRE posts a monitoring card to the chat: ``` @@ -170,8 +158,6 @@ Waiting reminders appear only on **attended IM requests**; the console, API, and ## Connections and Authorization ---- - When a credential is missing, the console renders inline cards (**"Authorize [resource name] to continue"**, **"Connect [vendor] to continue"** — see [Console](/en/ai-sre/sessions#when-authorization-is-required)). **IM and API channels get no card** — the agent hands the matter to you according to this session's channel, as follows: | Situation | Behavior on IM / API channels | @@ -185,8 +171,6 @@ On the automation channel nobody is watching and no reply will ever arrive: the ## In-session Switch Commands ---- - IM sessions have no picker UI like the console, but they support two slash commands that let you **switch bindings mid-conversation** — neither command is available for console sessions, whose environment and team bindings are set at creation and cannot be changed afterwards. ### /env — Switch Runner Environment @@ -227,8 +211,6 @@ Knowledge bundles already mounted into this session are not removed — mounts a ## /feedback — Rate an AI SRE Reply ---- - Once an AI SRE reply lands in a group chat, anyone in the group can rate it — not only whoever started the investigation. Send `/feedback` to the bot to rate or comment on the reply you are looking at: - **Entry and resolution:** `/feedback` is backed by the AI SRE side (POST /safari/session/latest-reply → POST /safari/feedback/create); it resolves "the message you are looking at" into the corresponding reply event even if you never took part in that conversation. @@ -239,8 +221,6 @@ Once an AI SRE reply lands in a group chat, anyone in the group can rate it — ## Relationship to Console Sessions ---- - Whether you start a session from IM or the console, it's **the same AI SRE**: messages are handled one at a time, with streaming output, automatic context compaction for long conversations, and optional team and environment bindings. The only difference is the entry point — - **Console**: ask questions one at a time in the **Chat** workspace and view the full tool-call and sub-session panels; environment and team bindings are fixed at creation and cannot be changed. @@ -250,8 +230,6 @@ For more about sessions, see [Conversations](/en/ai-sre/sessions). ## Related Pages ---- - Learn about AI SRE's overall capabilities, typical use cases, and console navigation. diff --git a/en/ai-sre/init.mdx b/en/ai-sre/init.mdx index afd8846e..23037511 100644 --- a/en/ai-sre/init.mdx +++ b/en/ai-sre/init.mdx @@ -11,8 +11,6 @@ sidebarTitle: Setup ## Overview ---- - Type `/init` in the input box of any AI SRE session, and the agent switches into an **operational onboarding interviewer** that walks you through building operational knowledge from scratch — your team's "operational map." It scans your Flashduty incidents and notification channels, asks you questions, captures the service topology, runbooks, cluster access, and more that you describe into knowledge files, and helps you connect external tools (MCP) when needed. `/init` is the **starting point** for knowledge. AI SRE's diagnostic quality depends directly on how much real knowledge it can read about your systems: the more complete and accurate your [knowledge](/en/ai-sre/knowledge) is, the faster and more reliably the agent pinpoints root causes. `/init` is the guided flow that builds that knowledge from zero — and once it's built, every session loads it automatically. @@ -23,8 +21,6 @@ Type `/init` in the input box of any AI SRE session, and the agent switches into ## When to use /init vs. plain natural language ---- - `/init` is for **structured setup from scratch / systematic backfilling**; small, one-off edits don't need it. | Scenario | What to use | @@ -39,8 +35,6 @@ Type `/init` in the input box of any AI SRE session, and the agent switches into ## How to run ---- - Type `/init` in the input box of any AI SRE session and send it. No parameters are required. @@ -61,8 +55,6 @@ Type `/init` in the input box of any AI SRE session, and the agent switches into ## The interview ---- - `/init` works through a fixed sequence of phases, each with clear entry and exit conditions. You can skip, go back, or stop at any time. @@ -104,8 +96,6 @@ Type `/init` in the input box of any AI SRE session, and the agent switches into ## Safety and consent ---- - `/init` writes knowledge, may install MCP, and touches credentials, so consent and least privilege are hard constraints: @@ -125,8 +115,6 @@ Type `/init` in the input box of any AI SRE session, and the agent switches into ## What it produces ---- - The result of `/init` is a [Knowledge](/en/ai-sre/knowledge) base that every subsequent session loads automatically: - **`DUTY.md`** — the table-of-contents entry point for the knowledge, holding only a one-line introduction and a list of `@filename` links pointing to each topic file; @@ -139,8 +127,6 @@ The result of `/init` is a [Knowledge](/en/ai-sre/knowledge) base that every sub ## /init and /insight: a best-practice pair ---- - `/init` and [`/insight`](/en/ai-sre/insight) are the two ends of the operational-knowledge "build → refine" loop: @@ -158,8 +144,6 @@ The recommended rhythm: use `/init` to lay a solid foundation, run a few real in ## Related pages ---- - Where `/init`'s output lands — learn the DUTY.md structure, file constraints, and how to edit and maintain it manually. diff --git a/en/ai-sre/insight.mdx b/en/ai-sre/insight.mdx index 9e3f32d2..a9286562 100644 --- a/en/ai-sre/insight.mdx +++ b/en/ai-sre/insight.mdx @@ -11,8 +11,6 @@ sidebarTitle: Usage Insights ## Overview ---- - Type `/insight` in the input box of any AI SRE session and AI SRE will look back at **your** last 30 days of sessions to produce a single-page operational insight report. The report uses a parchment-style HTML layout and renders directly in the session as a chat card, which you can preview and download. It is a **coach's read on the month**, not a problem list. It leads with **what's working** — where AI SRE genuinely pulled its weight this month; then covers the **frictions worth eliminating now** — the patterns that repeatedly drain your time, such as pasting the same database connection string across multiple sessions, an agent missing a runbook it should already know, or it repeatedly querying the wrong data source; and finally offers **2–3 higher-leverage next steps** — shifts in *how* you work with AI SRE that are worth trying. @@ -25,8 +23,6 @@ It is a **coach's read on the month**, not a problem list. It leads with **what' ## How to Generate ---- - Type `/insight` in the input box of any AI SRE session and send it. No parameters are required. @@ -70,8 +66,6 @@ Understanding how the report is put together helps you see where the numbers com ## Report Contents ---- - The report has **six parts** from top to bottom. Regardless of whether any friction is found, the quantitative overview is always present. ### 1. At a glance @@ -126,8 +120,6 @@ Every friction and win must be grounded in at least one real session and carry a ## Friction Types ---- - `/insight` recognizes exactly five friction types, each corresponding to a clear, adjustable "dial." Listed in default importance order: | Friction type | What it looks like in sessions | Recommended destination | @@ -144,8 +136,6 @@ Every friction and win must be grounded in at least one real session and carry a ## How to Act on Suggestions ---- - The report is **read-only**: it surfaces problems and provides copyable fix text, but **never** automatically applies any changes. For now, all suggestions are copy-paste style: you confirm them, then manually apply them in the corresponding resource. @@ -170,8 +160,6 @@ The report is **read-only**: it surfaces problems and provides copyable fix text ## Related Pages ---- - Learn about session creation, team binding, and war rooms — these determine the analysis scope of `/insight`. diff --git a/en/ai-sre/knowledge.mdx b/en/ai-sre/knowledge.mdx index 9e48e00c..50c5f610 100644 --- a/en/ai-sre/knowledge.mdx +++ b/en/ai-sre/knowledge.mdx @@ -11,8 +11,6 @@ sidebarTitle: Learn about Knowledge ## Overview ---- - Knowledge is the operational knowledge you hand to AI SRE: a `DUTY.md` file plus a collection of runbooks, FAQs, service catalogs, cluster configs, and similar files. When a session starts, the agent reads `DUTY.md` first, then opens other files as needed — bringing your team's incident-handling experience, naming conventions, and system topology into every diagnosis. Console entry: **AI SRE → Customize → Context → Knowledge**. [Memory](/en/ai-sre/memory), in the same group, is a separate page and is managed separately. @@ -30,8 +28,6 @@ Knowledge is one type of AI SRE resource and follows the same two-level scope mo ## DUTY.md Structure ---- - `DUTY.md` is the **table of contents entry point** for the whole knowledge and is loaded automatically in every session. The agent reads `DUTY.md` in full, then fetches other files on demand via `@filename` references. The system attaches no file listing beside `DUTY.md`: knowledge files sit under the `knowledge/` directory of the session workspace, and the agent finds them with ls / glob / grep the way it browses a code repository, so files that `DUTY.md` does not reference can still be found. If a scope has no `DUTY.md` yet, that scope is not silently skipped: the system tells the agent that this scope has no guide and which directory holds its files, and requires it to list that directory and read the relevant files before doing substantive work. @@ -71,8 +67,6 @@ After reading `DUTY.md`, the agent decides which `@references` to expand based o ## Maintain it in the console ---- - Go to **AI SRE → Customize → Context → Knowledge**. Each row of the list is one knowledge, labeled by scope ("Shared" or the team name), with its file count, `DUTY.md` status, and last edit time. The `DUTY.md` status is one of **Not created**, **Up to date**, or **Needs refresh · N changes since** (other files changed after `DUTY.md` was written). Click **Create** to add knowledge for the Shared scope or for a team you belong to; when the account and every team available to you already have one, the button is disabled. When no knowledge exists yet, the page shows a starter instead: **Set up AI-SRE** opens a new chat that runs [`/init`](/en/ai-sre/init), and **Upload existing docs** opens a new chat with the attachment picker open. @@ -104,8 +98,6 @@ If other files change after `DUTY.md` was written, a notice appears above the fi ## How the Agent Uses Knowledge ---- - Knowledge is not all loaded at once — it follows a **catalog-first, expand-on-demand** pattern: @@ -130,8 +122,6 @@ Knowledge is not all loaded at once — it follows a **catalog-first, expand-on- ## Scope & Visibility ---- - Every knowledge has a scope: Shared (account-level, visible across the entire account) or team-level. | Dimension | Shared | Team | @@ -155,8 +145,6 @@ This two-level scope model applies uniformly to all resources within the account ## Best Practices ---- - Keep `DUTY.md` to link lists and one-line descriptions only — all substantive content goes into the sibling files it `@references`. This keeps the catalog concise and readable, and lets the agent expand only the branches relevant to the current incident, avoiding irrelevant content consuming context. @@ -180,8 +168,6 @@ This two-level scope model applies uniformly to all resources within the account ## Related Pages ---- - Encapsulate reusable diagnostic workflows as Skills, sharing the same scope model as Knowledge. diff --git a/en/ai-sre/mcp.mdx b/en/ai-sre/mcp.mdx index 0cea0ea0..7c20285f 100644 --- a/en/ai-sre/mcp.mdx +++ b/en/ai-sre/mcp.mdx @@ -11,8 +11,6 @@ sidebarTitle: MCP ## Overview ---- - **MCP** (Model Context Protocol) lets AI SRE agents connect to external tools and data sources. Each **MCP server** is a standardized endpoint that exposes a set of tools (functions) — for example, querying GitHub issues, sending Slack messages, reading Kubernetes resources, or retrieving metrics from an observability platform. Once you configure and enable an MCP server in the console, agents will **autonomously decide** when they need an external capability during incident investigation and call the corresponding tool directly — no manual data-shuttling required. @@ -25,8 +23,6 @@ This is **different** from the [Flashduty MCP Server](/en/developer/mcp-server) ## What Is MCP ---- - **MCP** (Model Context Protocol) is an open protocol that describes in a uniform way "what tools a server exposes, what parameters each tool accepts, and what it returns." Think of it as the "USB port" of the AI agent world — any MCP-compliant server can be discovered and called plug-and-play by an agent, with no per-system adapter code required. In AI SRE, MCP extends an agent's capability from "built-in tools" to "any external system": @@ -41,8 +37,6 @@ In AI SRE, MCP extends an agent's capability from "built-in tools" to "any exter ## Installing MCP Servers from the Marketplace ---- - Go to **Customize → Plugins → Overview** to see Flashduty's curated catalog of third-party MCP templates. The catalog is grouped into category tabs (All / Observability / Cloud & Infrastructure / Database & Middleware / Code & Collaboration / Skill), and the search box in the top-right corner filters it by name or description. The **Recommended** block above the catalog ("Recommended from your alert sources and common usage. Once connected, AI SRE can use them during investigations.") picks the templates that match the **alert integrations already configured** in your account (ranked by alert count over the last 30 days), then fills in the picks promoted for your current locale, showing at most 3. Installed templates, templates that need a Runner, and templates you may not install never appear here. @@ -90,8 +84,6 @@ Row names share a namespace with template names: if a system already has a templ ## Adding an MCP Server ---- - Go to **Customize → Plugins → MCP**. The list page has two entries in the top-right corner: - **Add MCP**: opens a form for defining an MCP server by hand (its fields are listed under "Basic Fields" below). @@ -190,8 +182,6 @@ OAuth authorization completes through a browser **bounce page** at `/oauth-callb ## Management & Inspection ---- - The MCP list displays each server's **name** (including its AI description), **scope** (Shared or team name), **transport**, an **enabled** toggle, and an **actions** column — the list only contains MCP servers you have added to the account; the built-in Flashduty MCP server is injected by the runtime and does not appear in this list, see "Inspection" below. The scope filter bar at the top lets you switch between All / Shared / Team views, and the search box to its right filters the list by keywords in the name, description, transport, or URL. @@ -235,8 +225,6 @@ Conversely, to make a connector directly usable **here**, add the current enviro ## Scope ---- - MCP shares the same **two-level scope** model as other resources (Skills, Knowledge, Agents, Environments), divided into Shared scope and team scope: | Scope | Visibility | @@ -252,8 +240,6 @@ MCP shares the same **two-level scope** model as other resources (Skills, Knowle ## Related Pages ---- - Skills call MCP-provided tools inside SKILL.md using the `mcp:server/tool` notation. diff --git a/en/ai-sre/memory.mdx b/en/ai-sre/memory.mdx index 8a559c2a..8c35ce0d 100644 --- a/en/ai-sre/memory.mdx +++ b/en/ai-sre/memory.mdx @@ -11,16 +11,12 @@ sidebarTitle: Learn about Memory ## Overview ---- - A new session starts from the memory files already in the current scope. If you had to re-explain your habits, where to look first for a kind of failure, or why a previous approach was abandoned, troubleshooting would begin with the same background every time. Memory keeps those points as Markdown files and later sessions reuse them. Memory is not [knowledge](/en/ai-sre/knowledge). People maintain knowledge, and it describes how the environment runs. The system organizes memory: preferences, procedures, facts, and lessons kept from conversations. Both belong to the console's [Context](/en/ai-sre/context) group, but each has its own page: **AI SRE → Customize → Context → Memory**. ## Memory Types ---- - Each memory file starts with a name, a one-line description, and a type. There are four types: | Type | What it is for | @@ -34,8 +30,6 @@ Where the file is saved follows the session. A session bound to a team writes th ## How Memory Is Created ---- - Memory arrives in two ways: - **You ask for it.** In the conversation, tell the assistant to remember, change, or forget something. It writes or updates the matching memory file. @@ -45,16 +39,12 @@ Both ways write into the scope of the current session. ## How the Agent Uses Memory ---- - When a session starts, the memory files in the current scope are ready. The assistant sees each file's name and description first, and opens the body when it needs the detail. A session bound to a team uses that team's memory. A session with no team uses your personal memory. The four types carry different weight: procedure, fact, and lesson are past records that must be checked against the current situation before use; preference is a request you made explicitly, followed within its stated scope, and it wins when it conflicts with a Skill's or tool's default behavior. ## Scope & Isolation ---- - Memory has only two scopes, personal and team. There is no account-level memory, and cross-account reads are rejected outright. | Dimension | personal | team | @@ -68,8 +58,6 @@ This isolation follows the same permission model as other AI SRE resources: team ## View and edit it in the console ---- - Go to **AI SRE → Customize → Context → Memory**. - **Pick a scope**: switch between **Personal** and **Team** at the top; for Team, pick one of your teams from the dropdown. There is no Shared (account-level) memory. The scope and team are kept in the page URL, so a refresh or a shared link opens the same set of memories. @@ -85,8 +73,6 @@ With edit permission, an input box sits below the body (placeholder: "What shoul ## Related pages ---- - How memory and knowledge differ, and what personal, team, and shared scopes each contain. diff --git a/en/ai-sre/overview.mdx b/en/ai-sre/overview.mdx index 602c2294..15700d5d 100644 --- a/en/ai-sre/overview.mdx +++ b/en/ai-sre/overview.mdx @@ -11,8 +11,6 @@ sidebarTitle: Overview ## What Is AI SRE ---- - AI SRE is Flashduty's autonomous SRE agent platform. You give the AI instructions through conversation, and it independently investigates incidents, diagnoses root causes, calls tools to run diagnostics, and captures the operational knowledge gained from each investigation for future reuse. It is not a simple Q&A chatbot — it is a **hands-on troubleshooting worker**: it plans its own steps, reads and writes files, queries monitoring and logs, executes commands, calls external tools (MCP), and delegates subtasks when needed, ultimately delivering conclusions backed by a full investigation trail. @@ -30,8 +28,6 @@ AI SRE is deeply integrated with Flashduty's incident response system. When Flas ## Typical Use Cases ---- - AI SRE is more than a chat box in the console — it covers multiple collaboration entry points across the full lifecycle from incident trigger to retrospective: @@ -51,8 +47,6 @@ AI SRE is more than a chat box in the console — it covers multiple collaborati ## Activation and billing ---- - AI SRE is available to accounts holding a **valid (enabled)** On-call Pro or higher subscription, with no application needed. @@ -118,8 +112,6 @@ A subscription block never points at AI SRE billing — that page sells AI SRE c ## Core Capabilities ---- - AI SRE is built around "conversational troubleshooting + knowledge accumulation + autonomous execution," with every capability configurable and manageable from the console. @@ -157,8 +149,6 @@ AI SRE is built around "conversational troubleshooting + knowledge accumulation ## Console Navigation ---- - After entering AI SRE, the left sidebar has four entries (menu names match the console): | Entry | Purpose | @@ -182,14 +172,10 @@ Visibility of each area is determined by your access permissions in the account: ## Quick Start ---- - For the full walkthrough from activating access to finishing your first investigation, see [Quickstart](/en/ai-sre/quickstart). ## Next Steps ---- - Learn about sessions, streaming output, cancellation and context compaction, and how to launch an investigation from an incident. diff --git a/en/ai-sre/quickstart.mdx b/en/ai-sre/quickstart.mdx index d82e2ad6..1dc1c3ba 100644 --- a/en/ai-sre/quickstart.mdx +++ b/en/ai-sre/quickstart.mdx @@ -11,8 +11,6 @@ sidebarTitle: Quick Start ## Key Concepts (30 Seconds) ---- - Four things to know before you start: | Concept | What it is | @@ -24,8 +22,6 @@ Four things to know before you start: ## Three Entry Points ---- - There's no single way into AI SRE — start from wherever you already are: ### Chat @@ -42,8 +38,6 @@ Where incidents actually happen. In any Slack, Feishu, DingTalk, or WeCom group ## Your First Investigation (~5 min) ---- - Prerequisite: at least one incident in your account. AI SRE needs no application; starting September 16, 2026, 08:00 Beijing time, activate it in the console first. If you don't have an incident on hand right now, skip ahead to "Growing It Into Your SRE" below. @@ -80,8 +74,6 @@ If you don't have an incident on hand right now, skip ahead to "Growing It Into ## Growing It Into Your SRE (As Needed) ---- - Your first investigation is just the starting point. From here you can make analysis automatic, and keep sharpening its diagnoses — the latter depends on how much it knows about your systems and how much real data it can reach. All of this builds up over time, not all at once. ### Get every new incident analyzed automatically @@ -119,8 +111,6 @@ Permission rules (limiting what the agent may do on that machine), upgrades, and ## What's Next ---- - What AI SRE is, its full capability set, and console navigation. diff --git a/en/ai-sre/sandbox.mdx b/en/ai-sre/sandbox.mdx index 00868f03..af1f42c6 100644 --- a/en/ai-sre/sandbox.mdx +++ b/en/ai-sre/sandbox.mdx @@ -11,8 +11,6 @@ sidebarTitle: Sandbox ## Overview ---- - The **cloud sandbox** is a **temporary execution environment** managed by Flashduty — an isolated, ready-to-use container. The AI SRE agent's tool calls (running commands, reading and writing files, running Skills, connecting to MCP) all happen inside it, and you **don't have to install or maintain anything**. It is AI SRE's **default fallback**: when no usable self-hosted Runner ([BYOC Runner](/en/ai-sre/environments#byoc-runner)) is online for the current member, sessions automatically run in the cloud sandbox; you can also **pin a session to it manually**. @@ -30,8 +28,6 @@ The cloud sandbox executes on the hosting provider's serverless platform, in **H ## When to use the cloud sandbox ---- - The cloud sandbox is best for **investigations that don't depend on your private network**, and for getting started quickly: - **Quick start / demos**: you haven't deployed a Runner yet and want to try AI SRE's troubleshooting first; @@ -44,8 +40,6 @@ The cloud sandbox **cannot reach your private network**: its egress is restricte ## Using it in a session ---- - The **environment selector** at the bottom of the chat box decides where the session executes. Two of its options relate to the cloud sandbox: | Option | Behavior | @@ -59,8 +53,6 @@ The environment choice is **locked once per session**: the environment determine ## Cloud sandbox vs. self-hosted Runner ---- - | Dimension | Cloud sandbox | Self-hosted Runner ([BYOC Runner](/en/ai-sre/environments#byoc-runner)) | |---|---|---| | Deployment | No install, system-managed | Deploy a persistent process on your own machine | @@ -75,8 +67,6 @@ The two aren't mutually exclusive: keep sessions on **Auto** day to day — they ## Related pages ---- - Deploy a persistent Runner on your own machine so investigations reach your private network. diff --git a/en/ai-sre/sessions.mdx b/en/ai-sre/sessions.mdx index 19ce4245..e3934165 100644 --- a/en/ai-sre/sessions.mdx +++ b/en/ai-sre/sessions.mdx @@ -11,8 +11,6 @@ sidebarTitle: Console ## Overview ---- - A session is one complete conversation between you and AI SRE. It holds every message you send, the agent's streaming replies, tool calls made along the way, and any artifacts the agent produces (such as code, reports, charts, or Skill archives). Each session is fully independent, with its own context, bound team, and environment. You switch between sessions in the left sidebar, and exchange messages, read replies, and view artifacts in the central chat area. @@ -23,8 +21,6 @@ Sessions are isolated from one another: context, bound team, and environment do ## Creating and Managing Sessions ---- - The left sidebar is the single entry point for sessions. Click **New Chat** to start a fresh session. The list is sorted by most recent activity in descending order; only the most recent entries are shown initially, and older history is revealed incrementally with **Show more**. In a blank AI SRE session, four scenario suggestion cards appear above the composer: **Investigate an incident**, **Query data with natural language**, **Reduce alert noise**, and **Schedule an automated inspection**. Selecting a card only fills the composer; it does not send the prompt. You can edit it before pressing Enter. @@ -114,8 +110,6 @@ Opening a session clears its unread dot. ## Sending Messages and Streaming Responses ---- - Type a message in the input box at the bottom and press Enter to send. The input box supports Markdown and slash commands (type `/` to open the command menu) to trigger built-in skills and commands. When the console publishes a new version, a **version update notice** appears above the input box: "A new version of the console has been published. Refresh the page to continue." Click **Refresh** to reload the page and use the new version; clicking the close button hides the notice, and it will not repeat for the same version (the notice only appears in the full web console, not in embedded mode or on-premises deployments). @@ -201,8 +195,6 @@ If an error occurs during initialization, the card switches to a **Session setup ## Tool Calls and Artifacts ---- - Tools the agent invokes during a turn (reading and writing files, querying monitors, executing commands, calling MCP tools, etc.) are rendered inline in the conversation as collapsible blocks. Click one to expand and inspect its inputs and outputs; they are collapsed by default to keep the chat readable. ### Todo List @@ -427,8 +419,6 @@ The card also has a free-text box to add specifics (optional). On submit, the fe ## Context Compaction ---- - As a conversation grows longer, the session context approaches the model's context-window limit. AI SRE automatically compacts older conversation history — summarizing it into a digest while preserving recent content — to free up context space without losing critical information. Every compaction boundary summary also appends a deterministic **folded-resources manifest**: it lists the resources folded out of context this round and how to get them back — skills re-read via `skill(name)`, MCP server tool definitions re-discovered via `tool_search`, and A2A agent usage notes re-delivered automatically on the next dispatch or message. Post-compaction turns can recover those definitions on demand without keeping them in context. @@ -456,8 +446,6 @@ Compaction is transparent to you: what you perceive is a continuous conversation ## Choosing a Runtime Environment ---- - When creating a session, the input area has a separate **environment** selector alongside the team selector, which determines where the agent's tool, Skill, and MCP calls actually execute. The selector has three sections: | Option | Description | @@ -472,8 +460,6 @@ The environment choice is fixed once the first message is sent and the session i ## Binding a Team ---- - When you create a session you can **bind a team** to it. Once bound, the session automatically loads that team's knowledge, skills, and MCP servers at startup, giving the agent the team's domain context and capabilities from the very beginning. When no team is bound, the session runs in account scope. @@ -498,8 +484,6 @@ For the rules governing team scope for resources (account scope vs. team scope, ## Session entry kind ---- - Every session is created with an **entry kind** (`entry_kind`) that identifies which surface produced it. The value is persisted to the database and returned in the create response. | Value | Source | Notes | @@ -517,8 +501,6 @@ Sessions with `entry_kind=im` support **in-place environment and team switching* ## Reply language ---- - Every session determines a **reply language** at creation time. The agent replies in that language for the entire session and never switches midway; reopening the session later continues in the same language. | Entry kind | Where the reply language comes from | @@ -528,8 +510,6 @@ Every session determines a **reply language** at creation time. The agent replie ## Session data export ---- - `POST /safari/session/export` streams all events from a session as **NDJSON** (`application/x-ndjson`), one JSON object per line. This is intended for auditing, archiving, offline analysis, or feeding session data into external systems. ### Request fields @@ -589,8 +569,6 @@ If an error occurs after streaming has already begun, the server cannot switch t ## Related Pages ---- - Learn about AI SRE's positioning, capabilities, and use cases. diff --git a/en/ai-sre/skills.mdx b/en/ai-sre/skills.mdx index 29930de0..bf6a8d55 100644 --- a/en/ai-sre/skills.mdx +++ b/en/ai-sre/skills.mdx @@ -11,8 +11,6 @@ sidebarTitle: Skills ## Overview ---- - A Skill is a **reusable capability bundle**. Every skill consists of two parts: - A **SKILL.md** instruction document that tells the agent "when to use it, how to use it, and what steps to follow"; @@ -94,8 +92,6 @@ Those are examples, not the whole set: the runtime also bundles `init`, `insight ## Install from Marketplace ---- - The skill catalog is part of the plugin catalog on **Customize → Plugins → Overview**: skill templates are listed alongside MCP templates and the built-in Apps, grouped by category, with skills in their own **Skill** category (they also appear under the "All" tab, tagged `Skill`). The search box above the catalog filters by name or description, the tabs narrow the list to one category, and "See all N" next to a category heading expands that category; the search term and the selected tab live in the page URL, so leaving and coming back lands you where you were. @@ -137,8 +133,6 @@ Updating a modified skill **overwrites your local changes with the latest Market ## Custom Skills ---- - In addition to installing from the Marketplace, you can upload your own skill packages. On the skill list page, click **Upload Skill** and fill in the form: | Field | Type | Required | Description | @@ -181,8 +175,6 @@ Skill archive size limits: archives saved by the agent in-conversation are cappe ## Management and Inspection ---- - The skill list displays each skill's **name** (with source template badge, **Update available** marker, and **Local runner only** badge), **scope** (shared or team), **version**, **enabled** toggle, and an **actions** column. Skills that declare `venues: [byoc]` carry a **Local runner only** badge whose tooltip reads "Available only in sessions bound to a local runner; unavailable in cloud sandbox sessions"; Marketplace template cards show the same badge, so you know a template needs a self-hosted Runner before you install it. The toolbar above the list provides a scope filter (All / Account / Team) and a search box that filters the list by keywords in the name, description, or author. @@ -219,8 +211,6 @@ When a skill package is **too large to preview**, the detail panel displays the ## Scope ---- - Skills share the same **two-level scope** model with other resources (Knowledge, MCP, Agents, environments), divided into account level and team level: | Scope | Visibility | @@ -240,8 +230,6 @@ The `/` autocomplete dropdown in the chat input only shows **shared-scope skills ## Related Pages ---- - Use DUTY.md and knowledge to provide the agent with team context and troubleshooting experience. diff --git a/en/compliance/service-sla.mdx b/en/compliance/service-sla.mdx index 18bb92d6..96654144 100644 --- a/en/compliance/service-sla.mdx +++ b/en/compliance/service-sla.mdx @@ -10,7 +10,6 @@ This Service Level Agreement (hereinafter referred to as "SLA") stipulates the s Please note that unless otherwise agreed, this agreement does not apply to Flashduty's beta, invitation-only, free features and versions, nor does it apply to Flashduty's on-premises version. ## How We Ensure SLA ---- 1. **Multi-Active in Same City**: Infrastructure is built on multiple data centers, with stateful components all running in multi-active mode within the same city; 2. **Asynchronous Processing**: After an alert is reported, it immediately enters an asynchronous process with retry mechanisms, reducing the risk of alert loss; @@ -19,7 +18,6 @@ Please note that unless otherwise agreed, this agreement does not apply to Flash 5. **Continuous Monitoring**: Comprehensive collection of system metrics, regular stress testing to identify system issues proactively or in advance. ## Our SLA Commitment ---- - **Feature Availability (Error Rate)**: Core features are available 99.9% of the time - **Delivery Timeliness (Delay Rate)**: 99.9% of alerts are delivered within 5 minutes of triggering @@ -58,7 +56,6 @@ Service unavailability due to the following reasons will not be counted as servi - Force majeure events. ## How to Apply for Compensation ---- ### Compensation Standards @@ -75,7 +72,6 @@ You can submit compensation applications for Flashduty services that didn't meet Compensation applications must be submitted within two (2) months after the end of the month when Flashduty failed to meet service availability commitments. ## Additional Notes ---- Flashcat Cloud reserves the right to modify these SLA terms. diff --git a/en/compliance/terms-of-service.mdx b/en/compliance/terms-of-service.mdx index 0b922e95..6878f4f3 100644 --- a/en/compliance/terms-of-service.mdx +++ b/en/compliance/terms-of-service.mdx @@ -8,7 +8,6 @@ Last Updated: 2023-02-10 Welcome to sign this "Flashcat Cloud Product Service Agreement" (hereinafter referred to as "this Agreement") with Beijing Flashcat Cloud Technology Co.,Ltd. (hereinafter referred to as "Flashcat Cloud") and use Flashcat Cloud services! ## **General Terms** ---- 1.1. You confirm that before using this service, you have fully read, understood, and accepted all contents of this agreement and other related agreements and rules (especially the content marked in bold and/or underlined). Once you select "Agree" on this website (specific wording detailed on the registration page) and complete the purchase process or choose to use this service in any other way, you agree to comply with all terms under the aforementioned agreements and/or rules and are willing to be bound by them. @@ -19,7 +18,6 @@ Welcome to sign this "Flashcat Cloud Product Service Agreement" (hereinafter ref 1.4. Flashcat Cloud only provides technical services and technical support related to Flashcat Cloud services, and is a neutral information storage space and related technical service provider. The websites, applications, and any products, services, and related content that you own, upload, store, or manage and operate in any form through Flashcat Cloud are developed and operated by you, and you bear full responsibility. Flashcat Cloud assumes no responsibility for any such products, services, and related content. ## **Standard Service Terms** ---- ### **1. Contracting Parties and Agreement Scope** diff --git a/en/compliance/user-agreement.mdx b/en/compliance/user-agreement.mdx index 99e11841..777d9632 100644 --- a/en/compliance/user-agreement.mdx +++ b/en/compliance/user-agreement.mdx @@ -11,7 +11,6 @@ This "Flashduty User Agreement" (hereinafter referred to as "this Agreement") is Please carefully read and fully understand each clause of this Agreement, as well as any separate agreements or rules (hereinafter referred to as "other relevant agreements and rules") that should apply and be followed when activating or using certain Flashcat Cloud Services, especially the terms highlighted in bold or underlined text. ## **1 General Terms** ---- 1.1 You confirm that before using the Services, you have fully read, understood, and accepted all contents of this Agreement and other relevant agreements and rules (especially the content marked in bold and/or underlined). Once you select "Agree" on this website (specific wording detailed on the registration page) and complete the registration process or choose to use the Services in any other way, you agree to comply with all terms under the aforementioned agreements and/or rules and are willing to be bound by them. @@ -22,7 +21,6 @@ Please carefully read and fully understand each clause of this Agreement, as wel 1.4 Flashcat Cloud only provides technical services and technical support related to Flashcat Cloud Services, and is a neutral provider of information storage space and related technical services. Any products, services, and related content that you own, upload, store, or manage and operate in any form through Flashcat Cloud are developed and operated by you, and you shall bear full responsibility. Flashcat Cloud does not assume any responsibility for any such products, services, and related content. ## **2 User Service Account** ---- ### **2.1 Account Registration** @@ -64,7 +62,6 @@ If you are a minor or a person with limited capacity for civil conduct, you do n 2.4.3 You have the right to actively cancel your account by sending an email to [support@flashcat.cloud](mailto:support@flashcat.cloud) to request account cancellation. ## **3 Service Rules** ---- 3.1 Instructions sent by you to Flashcat Cloud in the following ways are irrevocable or irreversible instructions issued by you personally, and you shall bear any results and responsibilities arising from Flashcat Cloud executing such instructions: @@ -112,7 +109,6 @@ If you are a minor or a person with limited capacity for civil conduct, you do n 3.10.5 If you believe content generated by AI Features is illegal, incorrect, or infringes your lawful rights, you may complain or report via the in-product feedback entry or by emailing [contact-us@flashcat.cloud](mailto:contact-us@flashcat.cloud), and Flashcat Cloud will review and act promptly. ## **4 Your Rights and Obligations** ---- 4.1 Flashcat Cloud will provide you with network technical and information services, and will provide Flashcat Cloud's technical support, customer consultation, and other services when providing services to you. The content of such services is detailed on the relevant pages of this website. @@ -167,7 +163,6 @@ If you violate the above promises, Flashcat Cloud can not only take measures suc 4.6 You acknowledge and recognize that installing and using pirated software and other unauthorized software that violates this Service Agreement is not allowed on Flashcat Cloud services. At the same time, you should take all necessary and appropriate security protection measures for your computer information system according to national regulations, including but not limited to installing computer information system security special products permitted by the state. ## **5 Flashcat Cloud's Rights and Obligations** ---- 5.1 According to your service selection and payment situation, Flashcat Cloud will provide you with qualified network technical and information services. @@ -195,7 +190,6 @@ If you violate the above promises, Flashcat Cloud can not only take measures suc If circumstances occur where your account funds are frozen according to the above provisions, Flashcat Cloud will notify you through one or multiple methods such as email, in-site messages, SMS, or phone calls. You can appeal according to the corresponding procedures. If you appeal according to the requirements of Article 3.8 of this Agreement and pass Flashcat Cloud's review, Flashcat Cloud will immediately lift the fund freezing measures; if you fail to appeal within the specified time, or your appeal fails to pass Flashcat Cloud's review, you acknowledge that Flashcat Cloud has the right to freeze such funds long-term, or return the relevant frozen funds to the original recharge source account through the original route, including but not limited to bank accounts, WeChat accounts, Alipay accounts, etc. ## **6 Personal Information Protection** ---- 6.1 Flashcat Cloud collects, uses, stores, shares, and protects your personal information in accordance with the [Privacy Policy](/en/compliance/privacy-policy). The Privacy Policy sets out the categories of information we collect, the purposes for which we use it, whom we share it with, cross-border transfers, retention periods, device permission and third-party SDK disclosures, and the rights you have over your personal information. @@ -204,7 +198,6 @@ If circumstances occur where your account funds are frozen according to the abov 6.3 For your responsibility in safeguarding your account and password, see Article 2.3 of this Agreement. ## **7 System Interruption or Failure** ---- When the following circumstances occur, the Flashcat Cloud service system may not operate normally, thus causing you to be unable to use the services and producing corresponding consequences, for which Flashcat Cloud shall not bear any responsibility: @@ -218,7 +211,6 @@ When the following circumstances occur, the Flashcat Cloud service system may no - 8. Other circumstances not due to Flashcat Cloud's fault, beyond Flashcat Cloud's control or reasonable foresight. ## **8 Scope of Responsibility and Limitation of Liability** ---- 8.1 Flashcat Cloud only assumes responsibility within the scope of responsibility stated in this Agreement. @@ -231,14 +223,12 @@ When the following circumstances occur, the Flashcat Cloud service system may no 8.5 In any case, unless otherwise stipulated in this Agreement or separately agreed between Flashcat Cloud and you regarding a specific product and/or service, you agree that the total compensation liability borne by Flashcat Cloud under the terms of this Agreement and other relevant agreements and rules shall not exceed the total service fee charged to you for that particular service. ## **9 Intellectual Property** ---- 9.1 Except for third-party products or services, all content on this website, including but not limited to all content of related products or services, as well as images, logos, files, information, architecture, page design, etc., are legally owned by Flashcat Cloud or Flashcat Cloud affiliated companies for their intellectual property rights, including but not limited to copyright, trademark rights, patent rights, trade secrets, etc. For any behavior infringing upon Flashcat Cloud's intellectual property rights, Flashcat Cloud has the right to require legal responsibility according to relevant applicable laws and the provisions of this Agreement. 9.2 Without written permission from Flashcat Cloud or Flashcat Cloud affiliated companies, no one may use, modify, copy, distribute, spread, publish or publicly display any part of the products, services, software, programs, information, etc. on this website in any way or for any reason, or bundle them with other products for use or sale, or use them through hyperlinks or transmission or for any other commercial purposes. ## **10 Confidentiality** ---- 10.1 Under this Agreement, for any information received by either party ("Receiving Party") from the other party ("Disclosing Party"), if marked or can be reasonably considered as confidential or proprietary information of the Disclosing Party (including but not limited to technical, commercial related information, hereinafter referred to as "Confidential Information"), the Receiving Party shall keep it confidential, and without written consent from the Disclosing Party, shall not use it for any purpose outside this Agreement. The Receiving Party shall handle the Disclosing Party's Confidential Information with the same degree of care as it uses to protect its own confidential information (and not less than reasonable prudent duty). @@ -254,7 +244,6 @@ When the following circumstances occur, the Flashcat Cloud service system may no 10.4 Both parties' confidentiality obligations remain valid during the effective period of this Agreement and after its expiration, until the relevant information no longer has confidential significance. ## **11 Complete Agreement** ---- 11.1 This Agreement consists of these Agreement terms and various rules displayed on this website. If there are different understandings of the meanings of words used in this Agreement and various rules displayed on this website, the terms of this Agreement shall prevail. @@ -265,14 +254,12 @@ When the following circumstances occur, the Flashcat Cloud service system may no 11.4 If part of the content of this Agreement is determined to be invalid or unenforceable by a court with jurisdiction, it does not affect the validity or enforceability of other content. ## **12 Notice Delivery** ---- 12.1 You understand and recognize that after reasonable judgment, Flashcat Cloud can send notices to you through webpage announcements, emails, SMS, or regular mail delivery, etc., and Flashcat Cloud can presume that the contact information you provide to this website is complete, accurate, and currently valid; the above notices are deemed delivered to the recipient on the date of sending. 12.2 Unless otherwise agreed in the terms of this Agreement or explicitly specified in a special agreement signed between Flashcat Cloud and you, any notice you send to Flashcat Cloud must be delivered through Flashcat Cloud's officially announced communication address, fax number, email address, and other contact information. ## **13 Applicable Law and Dispute Resolution** ---- 13.1 The signing place of this Agreement is Haidian District, Beijing. diff --git a/en/developer/go-sdk.mdx b/en/developer/go-sdk.mdx index e5de5abc..fe6a062c 100644 --- a/en/developer/go-sdk.mdx +++ b/en/developer/go-sdk.mdx @@ -7,8 +7,6 @@ keywords: ["Go SDK", "go-flashduty", "Open API", "Golang", "client"] ## Overview ---- - `go-flashduty` is the official open-source Go client for Flashduty, covering every REST endpoint of the Flashduty Open API. It follows the same design as [go-github](https://github.com/google/go-github) — service groups, typed requests and responses, a composable transport layer — and stays strictly 1:1 with the OpenAPI spec: each method maps to exactly one HTTP call, returns `(*T, *Response, error)`, and performs no implicit cross-endpoint aggregation or enrichment. The SDK provides typed API operations generated from the Flashduty OpenAPI spec, covered by unit tests, and end-to-end verified against the live API. @@ -30,8 +28,6 @@ The module path is `github.com/flashcatcloud/go-flashduty`, the package name is ## Installation ---- - Make sure your local Go toolchain is at least 1.24. @@ -50,8 +46,6 @@ import flashduty "github.com/flashcatcloud/go-flashduty" ## Quick start ---- - Here is a minimal runnable example: construct the client, list incidents in the "Triggered" state, and handle the returned triple `(data, *Response, error)`. ```go @@ -100,8 +94,6 @@ Every call returns three values: ## Create a client ---- - `NewClient` takes an `app_key` plus zero or more `Option`s. An empty `app_key` returns an error directly. The default Base URL is `https://api.flashcat.cloud`, the default HTTP timeout is 30 seconds, and the default User-Agent is `go-flashduty`. ```go @@ -134,8 +126,6 @@ client, err := flashduty.NewClient("YOUR_APP_KEY", ## Services and methods ---- - Endpoints are grouped by service and hang off the client: the call convention is uniformly `client..(ctx, req)`, returning `(*T, *Response, error)`. For example, `client.Incidents.List(ctx, req)` or `client.Sessions.Info(ctx, req)`. | Service field | Description | @@ -223,8 +213,6 @@ All identifiers, service field names, and method names match the generated code. ## Response timestamps ---- - Time fields in responses are no longer bare integers but self-describing `Timestamp` (Unix seconds) or `TimestampMilli` (milliseconds) types (types shared by requests and responses are the exception — see the warning below). They serialize to RFC3339 strings in the local time zone, so JSON, logs, and LLM-facing output are directly readable; the raw epoch is still one method call away. - **Serialization (outbound)**: a non-zero value serializes to a quoted RFC3339 string (`TimestampMilli` uses RFC3339Nano to preserve millisecond precision). A zero value serializes to the bare integer `0` — an "unset" sentinel rather than a 1970 date, and dropped by `json:",omitempty"`. @@ -265,8 +253,6 @@ zero := inc.StartTime.IsZero() // whether it's the unset sentinel ## Pagination ---- - All list endpoints share `ListOptions`, which you embed in the request struct. Zero values are omitted and never override server defaults (the backend defaults to `p=1`, `limit=20`). | Field | Type | Wire field | Description | @@ -303,8 +289,6 @@ for page := 0; page < 100; page++ { ## Error handling ---- - An unsuccessful call returned by the Flashduty API — whether the envelope carries an error or the HTTP status is non-2xx — returns `*ErrorResponse`. It has `Code`, `Message`, an optional `Reason`, and `RequestID` fields; when troubleshooting, give `RequestID` to the support team to pinpoint the request. `Reason` carries the server-supplied optional cause (the envelope's `DutyError` has the same field, JSON `reason`,omitempty); when non-empty it is also appended to the end of the error string, as `, reason X`. When the API returns 429, the error is promoted to `*RateLimitError`: it embeds `*ErrorResponse` (so `errors.As` for `*ErrorResponse` still matches) and additionally carries a `RetryAfter` hint. @@ -354,8 +338,6 @@ case flashduty.ErrorCodeAccessDenied, flashduty.ErrorCodeUnauthorized: ## Retry ---- - The core client has **no** built-in automatic retry. Compose the optional `retry` subpackage through the transport layer — a safe-by-default retrying `http.RoundTripper`. Features of `github.com/flashcatcloud/go-flashduty/retry`: @@ -388,8 +370,6 @@ The `retry` subpackage is pure `net/http` and deliberately does not import the p ## Streaming export ---- - `client.Sessions.Export` exports the full event transcript of an AI SRE session, returning an `io.ReadCloser` (an NDJSON stream, `application/x-ndjson`) rather than a JSON envelope. The first line is always a `session_meta` envelope, and each subsequent line is a session event; when `req.IncludeSubagents` is true, each `subagent_dispatch` line is followed by the subagent's own full event stream. Because the response body can be large, read it line by line and write directly to a file — do **not** buffer the whole transcript into memory. The returned `io.ReadCloser` is the live HTTP response body, held by the caller and which you **must** `Close` (a `defer` close is correct). Pair it with `NewExportScanner` to scan line by line and `DecodeExportLine` to decode a line into an `ExportLine`: diff --git a/en/developer/mcp-server.mdx b/en/developer/mcp-server.mdx index cba814b0..4fd77b43 100644 --- a/en/developer/mcp-server.mdx +++ b/en/developer/mcp-server.mdx @@ -13,8 +13,6 @@ Flashduty MCP Server is a [Model Context Protocol (MCP)](https://modelcontextpro ## Use cases ---- - Hand incident creation, acknowledgment, and closure in Flashduty over to AI orchestration, wired into your operations workflow. @@ -32,8 +30,6 @@ Flashduty MCP Server is a [Model Context Protocol (MCP)](https://modelcontextpro ## Deployment ---- - Flashduty MCP Server offers three deployment modes; choose based on your MCP client's capabilities and your runtime environment. @@ -116,8 +112,6 @@ Flashduty MCP Server offers three deployment modes; choose based on your MCP cli ## Authentication and transport ---- - | Item | Description | | --- | --- | | Auth (local) | Provide the Flashduty APP Key via the `FLASHDUTY_APP_KEY` environment variable or the `--app-key` command-line flag. | @@ -131,8 +125,6 @@ Flashduty MCP Server offers three deployment modes; choose based on your MCP cli ## Configuration ---- - Flashduty MCP Server supports toolset trimming, read-only mode, output format, and other settings to suit different scenarios. Local deployments are configured via environment variables or command-line flags; the remote service is configured dynamically by appending query parameters to the URL. ### Environment variables @@ -205,8 +197,6 @@ The server supports outputting tool results in [TOON (Token-Oriented Object Nota ## Toolsets and tools ---- - The server provides **8 toolsets and 23 tools** in total, all enabled by default. The table below summarizes each toolset: | Toolset | Tools | Description | @@ -330,8 +320,6 @@ The tools in each toolset are as follows: ## Related resources ---- - The Go SDK that MCP Server depends on, covering the entire Flashduty Open API. diff --git a/en/on-call/comparison/vs-opsgenie.mdx b/en/on-call/comparison/vs-opsgenie.mdx index f52d7a54..0cc48625 100644 --- a/en/on-call/comparison/vs-opsgenie.mdx +++ b/en/on-call/comparison/vs-opsgenie.mdx @@ -6,8 +6,6 @@ keywords: ["Opsgenie", "Opsgenie alternative", "Opsgenie sunset", "Opsgenie migr ## Introduction ---- - Atlassian has given Opsgenie a definite end: **new sales stopped on June 4, 2025**; existing customers can keep using it until **support ends on April 5, 2027**, after which Opsgenie access shuts off and customer data that has not been moved out will be deleted (see the [Atlassian Opsgenie Licensing FAQ](https://www.atlassian.com/licensing/opsgenie)). @@ -33,8 +31,6 @@ The feature and pricing information on this page is current **as of September 20 ## Sunset Timeline and the Official Migration Path ---- - ### Key Dates | Date | Event | Impact | @@ -57,8 +53,6 @@ For organizations already standardized on Jira, Confluence, and JSM, this is the ## Product Feature Comparison ---- - ### On-call On-call solves "getting the alert to the right person": reduce noise first, then notify according to scheduling and escalation policies. @@ -148,8 +142,6 @@ Response solves "closing the loop quickly once the right person is found": a sin ## Pricing Comparison ---- - | Dimension | Flashduty | Opsgenie / JSM Path | | --- | --- | --- | | **Billing Model** | License fee + excess communication fees | Per-user seats; after migrating to JSM, billed by the JSM plan | @@ -176,8 +168,6 @@ Opsgenie's seat price is modest, but it is a sunset product — the meaningful c ## Migration Path Comparison ---- - ### Path One: Migrate into Jira Service Management (Stay in Atlassian) Best for organizations already standardized on the Atlassian suite. The official in-app tool syncs most configuration into the selected JSM plan, but note: @@ -216,8 +206,6 @@ Whichever path you choose, **complete the migration and export the data you need ## How to Choose ---- - - You need a durable on-call / incident-response home outside Atlassian's merge path @@ -241,8 +229,6 @@ Still comparing other vendors? See the in-depth [Flashduty vs PagerDuty comparis ## Summary ---- - Opsgenie was an excellent alerting and on-call product, but its lifecycle is now on a countdown. For existing users, April 5, 2027 is a firm planning boundary: **migration is not a question of whether, but of where to**. - If your organization already runs on the Atlassian suite, JSM is the official, lowest-friction path; diff --git a/en/on-call/comparison/vs-pagerduty.mdx b/en/on-call/comparison/vs-pagerduty.mdx index 1b34ce66..e394f5d8 100644 --- a/en/on-call/comparison/vs-pagerduty.mdx +++ b/en/on-call/comparison/vs-pagerduty.mdx @@ -6,8 +6,6 @@ keywords: ["product comparison", "PagerDuty", "feature comparison", "pricing com ## Introduction ---- - In the rapidly evolving digital era, enterprises increasingly rely on **monitoring and incident management tools**—these are essential foundations for ensuring business continuity and service stability. However, as monitoring systems scale, the flood of **alerts and event notifications** presents unprecedented operational challenges for IT teams. @@ -37,8 +35,6 @@ When your organization encounters the following situations, it's time to conside ## Procurement Guide Overview ---- - This guide provides **comprehensive On-call tool procurement recommendations**. We'll analyze the points IT managers should focus on when seeking efficient collaborative incident management solutions for development and operations teams, across three core dimensions: **Product Features**, **Service Quality**, and **Pricing Strategy**. We'll also provide detailed comparison analysis between **Flashduty** and **PagerDuty**, two leading On-call vendors, to help you make an informed choice. @@ -51,8 +47,6 @@ The feature and pricing information on this page is current **as of July 2026**; ## Product Feature Comparison ---- - Product features are compared module by module, following Flashduty's current product structure: **On-call** (noise reduction, scheduling, escalation, notifications), **Response** (war room collaboration and incident resolution), **Status Pages** (external status communication), **AI SRE** (autonomous troubleshooting agent), and the **platform foundation** that underpins them (integrations, alert pipelines, insights, security, and the open developer ecosystem). This breakdown roughly maps to PagerDuty's own product lines, making it easy to compare block by block. ### On-call @@ -239,8 +233,6 @@ Before reaching the team, alerts pass through routing, filtering, and transforma ## Pricing Comparison ---- - Pricing is a critical factor in enterprise decisions—you need to choose the most cost-effective option that meets your requirements. | Dimension | Flashduty | PagerDuty | @@ -296,8 +288,6 @@ Take a 100-person engineering team where 15 people are routinely involved in inc ## Service Quality Comparison ---- - Quality service support is essential for successful product implementation. | Service Item | Flashduty | PagerDuty | @@ -317,8 +307,6 @@ Quality service support is essential for successful product implementation. ## Migrating from PagerDuty / Opsgenie ---- - Flashduty is **compatible with the PagerDuty protocol**—existing alert integration configs can switch over with essentially no rework. A dedicated service group provides one-on-one expert support throughout the migration. @@ -332,8 +320,6 @@ Quality service support is essential for successful product implementation. ## Summary and Recommendations ---- - ### Core Advantages Comparison diff --git a/en/on-call/configuration/filter-conditions.mdx b/en/on-call/configuration/filter-conditions.mdx index 8b5809c2..060f7067 100644 --- a/en/on-call/configuration/filter-conditions.mdx +++ b/en/on-call/configuration/filter-conditions.mdx @@ -5,8 +5,6 @@ description: Filter specific alerts or incidents through condition matching, use ## Where Are Filter Conditions Used? ---- - Filter conditions apply to the following scenarios: | Scenario | Description | @@ -21,8 +19,6 @@ Filter conditions apply to the following scenarios: ## How to Configure Filter Conditions? ---- - ### Rule Design Flashduty On-call abstracts the entire filter condition system, aiming for minimal configuration while meeting most scenario requirements. @@ -145,8 +141,6 @@ or ## FAQ ---- - Flashduty On-call receives large volumes of data. To ensure system stability, the system only searches the most recent 500 alert events from the past 24 hours for label deduplication. Therefore, extracted labels may change dynamically, or no labels may be extracted if there's no new data in the past 24 hours. diff --git a/en/on-call/configuration/notifications.mdx b/en/on-call/configuration/notifications.mdx index d5ad98ab..f62bdec6 100644 --- a/en/on-call/configuration/notifications.mdx +++ b/en/on-call/configuration/notifications.mdx @@ -4,8 +4,6 @@ description: Comprehensive guide to Flashduty On-call supported notification cha --- ## Overview ---- - ### Supported Channel Matrix Flashduty On-call provides a comprehensive notification matrix covering mobile App, traditional communication, and mainstream instant messaging (IM) tools. @@ -23,8 +21,6 @@ Flashduty On-call provides a comprehensive notification matrix covering mobile A ## Core Notification Channel Configuration ---- - ### Flashduty App The Flashduty App is the most efficient mobile work tool for On-call engineers. Wherever you are, you can fully control the incident handling process just like at your computer. @@ -119,8 +115,6 @@ The Flashduty App is the most efficient mobile work tool for On-call engineers. ## Instant Messaging (IM) Integration ---- - Integrating Flashduty On-call with your team's daily IM tools (like Feishu/Lark, Dingtalk) allows receiving and handling incidents in familiar collaboration environments, greatly improving On-call efficiency. ### App Integration (Recommended) @@ -364,8 +358,6 @@ Verify the following: ## General Configuration ---- - Flashduty On-call allows you to customize personalized notification messages for different channels. @@ -397,8 +389,6 @@ Flashduty On-call allows you to customize personalized notification messages for ## Related Topics ---- - Configure alert notification rules and escalation paths diff --git a/en/on-call/configuration/personal-settings.mdx b/en/on-call/configuration/personal-settings.mdx index dacdf140..7646abf7 100644 --- a/en/on-call/configuration/personal-settings.mdx +++ b/en/on-call/configuration/personal-settings.mdx @@ -10,16 +10,12 @@ description: Set personal contact information, notification preferences, and API ## Accessing Personal Center ---- - Hover over the user icon in the lower left corner and select **Personal Information**. Related personal settings (**Notification Preferences**, APP Key, Flashduty APP) live in the same menu; for organization-level settings, go to **Platform Management → Organization → Organization Information**. ![Personal Center Entry](https://fcpub-1301667576.cos.ap-nanjing.myqcloud.com/flashduty/doc/zh/fd/gerenzhongxin-1.png) ## Personal Information ---- - Personal settings are accessed via the user icon in the lower left corner → **Personal Information**. The page shows an **account profile card** at the top and a **Login & Security** section below. ### Account Profile Card @@ -61,8 +57,6 @@ The organization time zone is maintained by the subject account or an Account.Ad ## Notification Preferences ---- - The Notification Preferences page configures notification channels **per notification scene**: **Incident Dispatch**, **Collaboration & Follow-up**, **Schedule Shift**, and **Internal Status Page**. Supported channels per scene: @@ -140,8 +134,6 @@ Status-page notifications are pushed only through IM apps; subscription emails a ## APP Key ---- - APP Keys are used for API request authentication. | Limit | Description | @@ -159,8 +151,6 @@ When creating or editing an APP Key, choose its mode under **Permission Scope**. ## Flashduty APP ---- - ### Download the app | Platform | Download Method | @@ -197,8 +187,6 @@ The Flashduty APP supports free push notifications for alerts, ensuring critical ## FAQ ---- - 1. Check if the channel has escalation rules configured. Without escalation rules, incidents won't trigger notifications @@ -210,8 +198,6 @@ The Flashduty APP supports free push notifications for alerts, ensuring critical ## Related Topics ---- - Set notification channel to "Follow Personal Preferences" diff --git a/en/on-call/configuration/schedule.mdx b/en/on-call/configuration/schedule.mdx index 9cdb026b..1b37909c 100644 --- a/en/on-call/configuration/schedule.mdx +++ b/en/on-call/configuration/schedule.mdx @@ -10,15 +10,11 @@ Flashduty On-call provides highly flexible scheduling capabilities, supporting d {/* ## Video Introduction ---- - */} ## Core Concepts ---- - Understanding these concepts before configuration will help you better plan your schedules: | Concept | Description | @@ -35,8 +31,6 @@ Understanding these concepts before configuration will help you better plan your ## Configuration Process ---- - Go to **Schedule Management**, click "Create Schedule" @@ -96,8 +90,6 @@ Understanding these concepts before configuration will help you better plan your ## Delete a schedule ---- - You can delete a schedule from the schedule list or the schedule detail page. The system asks for confirmation before deletion. @@ -106,8 +98,6 @@ If a schedule is referenced by escalation rules, the delete button is disabled. ## On-call roles ---- - On-call roles distinguish responders with different responsibilities within the same schedule (e.g., "primary" and "backup") and are an account-level resource: - **Shared across the account**: Roles take effect at the account level and are shared by all schedules @@ -120,8 +110,6 @@ By default, each account has only one on-call role, so you don't need to choose ## Override and time off ---- - When on-call personnel need time off or have a temporary conflict, **don't modify permanent rules** — use the "Override" feature instead. An override is an independent rule type that **fully preempts** the normal on-call rules within its effective window. Once the window ends, the original rules resume automatically. ### Two ways to create an override @@ -155,8 +143,6 @@ We recommend having a brief sync meeting between outgoing and incoming on-call p ## Date mask and continuous rotation ---- - ### Date mask Date mask controls which days of the week an on-call rule takes effect. By selecting different day combinations, you can flexibly implement differentiated scheduling between weekdays and weekends. @@ -186,8 +172,6 @@ Consider enabling continuous rotation in the following scenarios: ## Common scheduling scenarios ---- - **Requirement**: Ops team has A, B, C—each person on-call for one week, handoff Monday at 10:00 AM. @@ -234,8 +218,6 @@ Consider enabling continuous rotation in the following scenarios: ## View schedule details ---- - Click a schedule name to enter the detail page, where you can view the scheduling calendar and manage on-call rules. The upper right corner provides these options: - **View switcher**: Toggle between "Week", "Two Weeks", and "Calendar" (month view) @@ -245,8 +227,6 @@ Click any time slot in the calendar to view the current responders or create an ## View My Schedule ---- - The **Schedules** list page embeds a **My Schedule** section at the top, summarizing your on-call assignments in a week view: the left column lists the schedules in which you have shifts this week, and the calendar on the right shows your on-call time slots in each schedule. Click the left and right arrows next to the section title to browse previous or upcoming weeks, and click the dot button in the middle to quickly jump back to the current week. @@ -255,8 +235,6 @@ Shift times are rendered in your effective time zone; when a schedule's time zon ## Related Topics ---- - Configure alert notification rules and escalation paths diff --git a/en/on-call/configuration/service-calendar.mdx b/en/on-call/configuration/service-calendar.mdx index d3aafec9..bb25fead 100644 --- a/en/on-call/configuration/service-calendar.mdx +++ b/en/on-call/configuration/service-calendar.mdx @@ -9,16 +9,12 @@ description: Service calendars define workdays and rest days, working with escal {/* ## Video Introduction ---- - */} ## Use Cases ---- - | Scenario | Description | | --- | --- | | **Escalation Rules** | Assign to different on-call personnel based on workdays/rest days | @@ -26,8 +22,6 @@ description: Service calendars define workdays and rest days, working with escal ## Creating a Calendar ---- - Go to **Configuration → Service Calendar** and click **Add Calendar**. | Configuration | Description | @@ -48,8 +42,6 @@ New calendars default to all workdays. After creation, open the calendar detail ## Editing a Calendar ---- - | Action | Description | | --- | --- | | **Modify Basic Info** | Calendar name, description, management team | @@ -65,8 +57,6 @@ Deleting a calendar is irreversible. Please confirm no escalation rules or silen ## FAQ ---- - They serve different purposes: @@ -80,8 +70,6 @@ Deleting a calendar is irreversible. Please confirm no escalation rules or silen ## Related Topics ---- - Reference service calendars in escalation rules diff --git a/en/on-call/integration/alert-integration/alert-sources/aikido.mdx b/en/on-call/integration/alert-integration/alert-sources/aikido.mdx index b40e3c4f..da90922c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aikido.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aikido.mdx @@ -9,7 +9,6 @@ Use an Aikido Security webhook to send security issues to Flashduty On-call. Eac
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure in Aikido ---- @@ -65,12 +63,10 @@ Let Aikido raise a new issue and confirm the alert reaches Flashduty. Then close ## Alert Key ---- Flashduty uses `payload.issue_id` as the Alert Key. Aikido's documentation defines it as the ID of the issue, and every event for the same issue carries it. Changes to severity, status, or event type do not change the Alert Key. An issue event without `payload.issue_id` is rejected, because later updates and recovery could not be matched to the alert. ## Status and severity ---- | Aikido `event_type` | Flashduty handling | | :--- | :--- | @@ -94,7 +90,6 @@ Flashduty uses `payload.issue_id` as the Alert Key. Aikido's documentation defin The Aikido payload has no title field, so the alert title looks like `Aikido open_source issue #123 (critical)`. The issue type (`open_source`, `leaked_secret`, `cloud`, `iac`, `sast`, `surface_monitoring`, `malware`), `severity_score`, and `workspace_id` are stored as alert labels. ## Troubleshooting ---- - **Aikido gets a non-200 response and retries**: Aikido retries 5 times on a non-200 response or a timeout. Confirm the push URL is complete and includes `integration_key` - **Flashduty returns a parameter error**: confirm the body is valid JSON and issue events carry `payload.issue_id` diff --git a/en/on-call/integration/alert-integration/alert-sources/airbrake.mdx b/en/on-call/integration/alert-integration/alert-sources/airbrake.mdx index b8b1d117..e0e55a2b 100644 --- a/en/on-call/integration/alert-integration/alert-sources/airbrake.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/airbrake.mdx @@ -9,7 +9,6 @@ Use the Webhook integration of an Airbrake project to send error notifications t
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Airbrake ---- @@ -60,17 +58,14 @@ Airbrake's documentation does not describe a test notification body, so Flashdut ## Alert Key ---- Flashduty computes the Alert Key from `error.id` (the Airbrake error ID) in the webhook body. Every notification for the same error uses the same Alert Key, and changes to the error message, occurrence count, environment, or last occurrence time do not change it. A notification without `error.id` is rejected. ## Severity ---- The Airbrake webhook carries no severity. Every notification is a Warning trigger. ## Labels ---- | Label | Source | | :--- | :--- | @@ -84,7 +79,6 @@ The Airbrake webhook carries no severity. Every notification is a Warning trigge | `url` | Link to the error in Airbrake (`airbrake_error_url`) | ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: confirm the URL is complete and includes `integration_key` - **Alerts do not recover**: Airbrake sends no recovery notification; turn on the channel's auto-close or close alerts manually diff --git a/en/on-call/integration/alert-integration/alert-sources/alertsite.mdx b/en/on-call/integration/alert-integration/alert-sources/alertsite.mdx index 9e54feb3..da42f536 100644 --- a/en/on-call/integration/alert-integration/alert-sources/alertsite.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/alertsite.mdx @@ -9,7 +9,6 @@ Use AlertSite JSON alerts (POST JSON request to web server) to send monitor avai
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure AlertSite ---- @@ -68,14 +66,12 @@ Use the default JSON alert template. This integration reads the field names of t ## Alert Key ---- Flashduty computes the Alert Key from the alert type (availability or performance) and `device_id`. The AlertSite docs note that monitor names can change and recommend `device_id` as the identifier. The error and clear alerts of a monitor carry the same `device_id`, so they land on the same alert. Availability alerts (`error` / `clear`) and performance alerts (`perf_warning` / `perf_error` / `perf_clear`) are keyed separately: a performance clear does not close an availability alert that is still failing. Changes to the monitor name, failing location, failing step, status code, time, or response time do not change the Alert Key. Flashduty rejects a request without `device_id`, because the later recovery could not be matched. ## Status and severity ---- | AlertSite `notify_type` | Flashduty status | Flashduty severity | | :--- | :--- | :--- | @@ -89,14 +85,12 @@ Availability alerts (`error` / `clear`) and performance alerts (`perf_warning` / An empty or other `notify_type` is rejected, so a request whose state cannot be determined never lands in the wrong alert lifecycle. ## Alert content ---- - **Title**: the monitor name `device_name` - **Description**: status text, failing location, URL, HTTP status, failing step, check time; the status of each location for rotated locations (`rotated_locations`); the response time and threshold of each location for performance alerts (`locations`) - **Labels**: `device_id`, `device_type`, `custid`, `notify_type`, `alert_type` (`availability` or `performance`), `status_code` (the AlertSite status code, `0` means OK), `status_text`, `location`, `location_num`, `http_status`, `check` (monitor name), `resource` (the monitored URL), and `source` (always `alertsite`) ## Troubleshooting ---- - **AlertSite delivery fails**: make sure **Recipient** holds the full push URL, including `https://` and `integration_key` - **Flashduty returns a parameter error**: make sure the default template is used and the request has `notify_type` and `device_id` diff --git a/en/on-call/integration/alert-integration/alert-sources/aliyun-arms.mdx b/en/on-call/integration/alert-integration/alert-sources/aliyun-arms.mdx index fce1e1ed..148891b2 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aliyun-arms.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aliyun-arms.mdx @@ -8,7 +8,6 @@ Sync Alibaba Cloud ARMS monitoring alerts to Flashduty via webhook for automated
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In Alibaba Cloud ARMS ---- **Step 1: Configure Notification Target**
@@ -69,7 +67,6 @@ Choose this method when you need to route alerts to different channels based on
## Status Mapping ----
Alibaba Cloud ARMS monitoring to Flashduty alert severity mapping: diff --git a/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-event.mdx b/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-event.mdx index db160711..bca617b7 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-event.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-event.mdx @@ -8,7 +8,6 @@ Sync Alibaba Cloud Monitor event center alerts to Flashduty via webhook for auto
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In Alibaba Cloud Monitor CM Event ---- **Step 1: Add Push Channel**
@@ -72,7 +70,6 @@ Choose this method when you need to route alerts to different channels based on
## Status Mapping ----
Alibaba Cloud Monitor event alert to Flashduty severity level mapping: diff --git a/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-metrics.mdx b/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-metrics.mdx index 25c67ad9..b77889d0 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-metrics.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-metrics.mdx @@ -8,7 +8,6 @@ Sync Alibaba Cloud Monitor alert events to Flashduty via webhook for automated a
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Alibaba Cloud Monitor ---- Choose one of the following two methods: **Method 1: Rule-based Configuration** @@ -81,7 +79,6 @@ Choose one of the following two methods:
## Status Mapping ----
Severity level mapping from Alibaba Cloud Monitor to Flashduty: diff --git a/en/on-call/integration/alert-integration/alert-sources/aliyun-dataworks-op.mdx b/en/on-call/integration/alert-integration/alert-sources/aliyun-dataworks-op.mdx index c865c0f3..ed7510ba 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aliyun-dataworks-op.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aliyun-dataworks-op.mdx @@ -8,7 +8,6 @@ keywords: ["alert integration", "Alibaba Cloud DataWorks", "DataWorks Intelligen
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following two ways. ### Use an exclusive integration @@ -46,7 +45,6 @@ Choose this option when you need to route alerts to different collaboration spac
## In Alibaba Cloud DataWorks ---- **Step 1: Create a custom webhook**
@@ -70,7 +68,6 @@ Choose this option when you need to route alerts to different collaboration spac
## Supported alert types ----
DataWorks Intelligent Monitoring wraps every custom webhook message in a `message` field, distinguished by `message.title`. This integration supports the following three alert families: @@ -86,7 +83,6 @@ The connectivity test message (`message.content`) is used only to verify the pus
## Severity mapping ----
Mapping from custom alert `remind_type` to Flashduty severity: @@ -122,7 +118,6 @@ Mapping from event alert `event_type`:
## Alert Key and alert merging ----
DataWorks Intelligent Monitoring webhooks are **one-shot events**: the official protocol defines alert notifications only, with **no recovery** or update semantics, and it provides no vendor-level deduplication ID or fingerprint field. Therefore this integration never automatically recovers (closes) any alert; every event is delivered in a triggered state. @@ -132,7 +127,6 @@ Every webhook delivery receives a fresh random UUID as its Alert Key, so each pu
## Field label mapping ----
Key fields from the push message are preserved as labels on the alert event and can be used for routing, silencing, and template rendering: @@ -156,7 +150,6 @@ Key fields from the push message are preserved as labels on the alert event and
## FAQ ----
**Why are alerts never automatically recovered?** diff --git a/en/on-call/integration/alert-integration/alert-sources/aliyun-prometheus.mdx b/en/on-call/integration/alert-integration/alert-sources/aliyun-prometheus.mdx index 550f941e..f14b7615 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aliyun-prometheus.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aliyun-prometheus.mdx @@ -7,7 +7,6 @@ keywords: ["alert integration", "Alibaba Cloud Prometheus integration", "monitor
## In Flashduty On-call ---- You can obtain an integration push URL through either of these two methods: ### Using private integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In Alibaba Cloud ---- @@ -74,7 +72,6 @@ Go back to the Flashduty console integration list page. If the latest event time ## Severity mapping ----
Alibaba Cloud Prometheus to Flashduty severity mapping: diff --git a/en/on-call/integration/alert-integration/alert-sources/aliyun-sls.mdx b/en/on-call/integration/alert-integration/alert-sources/aliyun-sls.mdx index d09acace..16d91c61 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aliyun-sls.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aliyun-sls.mdx @@ -8,7 +8,6 @@ Sync Alibaba Cloud Log Service (SLS) monitoring alert events to Flashduty via we
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Alibaba Cloud SLS ---- **Step 1: Configure Webhook**
@@ -109,7 +107,6 @@ Choose this option when you need to route alerts to different channels based on
## Status Mapping ----
Alibaba Cloud SLS monitoring to Flashduty alert severity mapping: @@ -125,7 +122,6 @@ Alibaba Cloud SLS monitoring to Flashduty alert severity mapping:
## Alibaba Cloud ActionTrail ----
ActionTrail's "event alert" feature is provided by Log Service (SLS), not a separate push channel: first create a trail that delivers events to a Logstore, then configure an SLS alert on that Logstore. The notification channel reuses the webhook integration steps above — no separate integration is needed for ActionTrail. diff --git a/en/on-call/integration/alert-integration/alert-sources/amazon-inspector.mdx b/en/on-call/integration/alert-integration/alert-sources/amazon-inspector.mdx index a81373fb..6262ba61 100644 --- a/en/on-call/integration/alert-integration/alert-sources/amazon-inspector.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/amazon-inspector.mdx @@ -9,7 +9,6 @@ Amazon Inspector sends an **Inspector2 Finding** event to Amazon EventBridge whe
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the AWS EventBridge integration type** in both, not Amazon Inspector. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the AWS Ev
## Configure in AWS ---- Inspector emits events to the default event bus of each Region where it is enabled, so create the rule in every such Region. @@ -67,7 +65,6 @@ Do not add `"status": ["ACTIVE"]` to the pattern. The notification example in th Other Inspector events (`Inspector2 Scan`, `Inspector2 Coverage`, `Inspector2 AutoEnable`) are not findings and should not be forwarded to Flashduty; the `detail-type` above already excludes them. ## Field mapping ---- The mapping below is how Flashduty processes these AWS EventBridge events: @@ -83,7 +80,6 @@ The mapping below is how Flashduty processes these AWS EventBridge events: | Event `source`, `region`, `account`, `detail-type`, `detail`, `resources` | Labels `source`, `region`, `account`, `check`, `detail`, `resources` | ## Recovery and deduplication ---- - Inspector sends another event for the same `findingArn` when a vulnerability is fixed or a finding changes state. When `status` is `CLOSED` (fixed) or `SUPPRESSED`, Flashduty closes the alert. - If the account is an Inspector delegated administrator, findings of member accounts are also delivered to it; use the label `aws_account_id` to tell the source account. @@ -91,7 +87,6 @@ The mapping below is how Flashduty processes these AWS EventBridge events: - The `detail` of code vulnerability findings contains file paths and detector names, which end up in the alert through the `detail` label. ## Troubleshooting ---- - **The API destination call fails**: confirm the endpoint is the full push URL including `integration_key` and that `HTTP method` is `POST` - **Alerts do not recover**: check whether the rule's event pattern filters on `status`, and whether the target has an Input transformer (the full event must be sent) diff --git a/en/on-call/integration/alert-integration/alert-sources/apcupsd.mdx b/en/on-call/integration/alert-integration/alert-sources/apcupsd.mdx index ae31e583..d2921360 100644 --- a/en/on-call/integration/alert-integration/alert-sources/apcupsd.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/apcupsd.mdx @@ -9,7 +9,6 @@ When apcupsd detects a UPS state change it calls `apccontrol`, which runs the ex
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the Standard Alert Event integration type** in both, not apcupsd. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Standa
## Configure in apcupsd ---- ### Step 1: Create the push script @@ -114,7 +112,6 @@ Run the event scripts by hand on the host, first a trigger and then a recovery: In Flashduty you should first see the alert `UPS myups: on battery` and then see it recover. Running `onbattery` by hand also runs whatever else the event file already contains; to test only the push, run `/etc/apcupsd/flashduty-notify.sh onbattery myups` directly. ## Recovery and deduplication ---- - `onbattery`, the failure events (`failing`, `timeout`, `loadlimit`, `runlimit`), `offbattery` and `mainsback` share the Alert Key `apcupsd::power`: `onbattery` triggers the alert, a following failure event raises it to Critical, and it recovers when utility power returns - `commfailure` and `commok`, and `battdetach` and `battattach`, are paired @@ -122,7 +119,6 @@ In Flashduty you should first see the alert `UPS myups: on battery` and then see - Alerts of several UPS units do not affect each other: the Alert Key contains the UPS name (the name configured in `apcupsd.conf`) ## Troubleshooting ---- - **No alert arrives**: confirm the file named after the event exists in `/etc/apcupsd` and is executable, and that `URL` in `flashduty-notify.sh` is correct; run the event file by hand and check the output - **The alert does not recover**: confirm the recovery events (`offbattery`, `mainsback`, `commok`, `battattach`) are hooked too diff --git a/en/on-call/integration/alert-integration/alert-sources/apimetrics.mdx b/en/on-call/integration/alert-integration/alert-sources/apimetrics.mdx index 3c425cde..c3433589 100644 --- a/en/on-call/integration/alert-integration/alert-sources/apimetrics.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/apimetrics.mdx @@ -9,7 +9,6 @@ Use the APIContext (formerly APImetrics) Performance Results Webhook to send API
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure APIContext ---- @@ -65,7 +63,6 @@ With **Pass** on, every successful call sends a request to Flashduty. A `PASS` w ## Payload ---- APIContext sends JSON with an HTTP POST, one request per call result; no template is needed. Flashduty uses these fields: @@ -86,14 +83,12 @@ APIContext sends JSON with an HTTP POST, one request per call result; no templat The alert title is "call name: result", for example `Orders API: HTTP_SERVER_ERROR`. ## Alert Key ---- The Alert Key is computed from `call_id`, so each API call has one alert. The APIContext documentation describes `call_id` as a static ID that is the same every time the call is made, so the failure and the recovery of one call land on the same alert, whichever probe location reports them. With the default schedule each run executes from one random location, so a `PASS` from any location closes the call's alert and the next failure reopens it. `location_id` is kept as a label and in the description. Changing the call name, result detail, response time or HTTP status code does not change the Alert Key. When a request has no `call_id`, Flashduty returns a parameter error because it cannot reliably match a recovery to its alert. A request with no `call_id`, `result_id` and `result_class` (such as an empty object) is treated as a test request: it returns success and creates no alert. ## Status and severity ---- | `result_class` | Flashduty status or severity | | :--- | :--- | @@ -106,7 +101,6 @@ Changing the call name, result detail, response time or HTTP status code does no `SLOW` means the call succeeded but responded slowly. Flashduty records it as Warning and does not close an existing failure alert. To change a severity, rewrite it with a rule under the channel's **Configuration**. ## FAQ ---- @@ -129,7 +123,6 @@ No. The Alert Key of a call does not change, so repeated failure results merge i ## Troubleshooting ---- - **APIContext does not receive a success response**: confirm the URL is the full push URL and includes `integration_key` - **Flashduty returns a parameter error**: the request body has no `call_id`. Confirm that you use the Generic webhook rather than an OpenTelemetry or other export type diff --git a/en/on-call/integration/alert-integration/alert-sources/appdynamics.mdx b/en/on-call/integration/alert-integration/alert-sources/appdynamics.mdx index a0007de4..f2aee7f8 100644 --- a/en/on-call/integration/alert-integration/alert-sources/appdynamics.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/appdynamics.mdx @@ -8,7 +8,6 @@ Sync AppDynamics alerts to Flashduty via webhook for automated alert noise reduc
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In AppDynamics ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/appsignal.mdx b/en/on-call/integration/alert-integration/alert-sources/appsignal.mdx index 0be8db83..4bf44ba6 100644 --- a/en/on-call/integration/alert-integration/alert-sources/appsignal.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/appsignal.mdx @@ -13,7 +13,6 @@ Use the AppSignal Webhook notifier to send exception incidents, performance inci
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -34,7 +33,6 @@ You can obtain an integration push URL in either of the following ways.
## In AppSignal ---- @@ -69,7 +67,6 @@ The AppSignal documentation does not describe a test button for the Webhook noti ## Events and recovery ---- | AppSignal payload | When it is sent | Effect in Flashduty | | :--- | :--- | :--- | @@ -82,7 +79,6 @@ The AppSignal documentation does not describe a test button for the Webhook noti AppSignal notifies webhooks only on two anomaly detection transitions, opened and resolved. The warming up and cooldown phases send nothing. ## Alert Key ---- Flashduty builds the Alert Key from the object the event is about, so every delivery for one object shares one Alert Key: @@ -94,17 +90,14 @@ Flashduty builds the Alert Key from the object the event is about, so every deli Exception and performance incidents share one incident numbering. The Alert Key is computed from the object type and the fields above, so changes to the trigger name, current value, time, exception message, or revision do not change it. A delivery missing one of these fields is rejected, and the error names the field. ## Severity ---- AppSignal payloads carry no severity, so every alert is Warning in Flashduty, and a recovery moves it to recovered. To distinguish severity, use labels in the integration's routing or alert processing rules. ## Incidents do not recover ---- AppSignal sends no recovery for exception and performance incidents. In the channel that receives this integration, turn on the [auto-resolve timeout](/en/on-call/channel/create-edit). 24 hours is a reasonable start; adjust it to how quickly your team handles exceptions. A repeat occurrence of the same incident updates the same alert; once the alert is closed, the next occurrence creates a new one. ## Labels ---- | Label | Source | | :--- | :--- | @@ -123,7 +116,6 @@ AppSignal sends no recovery for exception and performance incidents. In the chan | `url` | Link to the alert or incident in AppSignal | ## Troubleshooting ---- - **Flashduty returns an invalid parameter error**: confirm the URL is complete and includes `integration_key` - **Nothing arrives**: confirm the Webhook notifier is selected on the trigger (alerts) or in the app's notification settings (incidents), and that the payload types are selected diff --git a/en/on-call/integration/alert-integration/alert-sources/argocd.mdx b/en/on-call/integration/alert-integration/alert-sources/argocd.mdx index 8412f226..07bd3107 100644 --- a/en/on-call/integration/alert-integration/alert-sources/argocd.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/argocd.mdx @@ -12,7 +12,6 @@ Argo CD pushes alerts through its built-in **Notifications** (`argocd-notificati
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -33,7 +32,6 @@ You can get the integration push URL in either of the following ways.
## Configure Argo CD ---- The steps below need Kubernetes permission to edit ConfigMaps in the Argo CD namespace (`argocd` by default) and to edit annotations on Applications or AppProjects. The Argo CD cluster must be able to reach the domain of the push URL. @@ -160,7 +158,6 @@ Make a subscribed application fail to sync (for example, set a Deployment's imag ## Alert Key ---- Flashduty computes the Alert Key from `event_type` and the application's `app_uid` (`app.metadata.uid`). Kubernetes gives every object a UID that is unique over the whole lifetime of the cluster, so: @@ -173,7 +170,6 @@ Changes to the application name, project, revision, sync status, or error messag Flashduty rejects a request that lacks `event_type` or `app_uid`, a sync message without `phase`, or a health message without `health_status`. ## Alert lifecycle ---- | `event_type` | Status field | Value | Flashduty action | | :--- | :--- | :--- | :--- | @@ -189,7 +185,6 @@ Status values are case-insensitive. Any other value is rejected. If an application is deleted while its alert is open, Argo CD sends no recovery message. Close the alert by hand, or turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) (24 hours suggested). ## Severity ---- | Alert | Severity | | :--- | :--- | @@ -199,7 +194,6 @@ If an application is deleted while its alert is open, Argo CD sends no recovery To use one severity for every alert, append `&severity=Critical` (or `Warning`, `Info`) to the push URL. A recovery event keeps the severity of the original alert. ## Alert content ---- - **Title**: `Argo CD application sync ` or `Argo CD application health ` - **Description**: for a sync failure, the Argo CD sync result message (`operationState.message`); for health degraded, `Health status: Degraded` @@ -208,7 +202,6 @@ To use one severity for every alert, append `&severity=Critical` (or `Warning`, Empty fields are not written as labels. ## Troubleshooting ---- - **No alert arrives**: check the `argocd-notifications-controller` logs (`kubectl logs -n argocd deploy/argocd-notifications-controller`) and confirm that the application has the `notifications.argoproj.io/subscribe.on-flashduty.flashduty` annotation, or that `subscriptions` includes `on-flashduty` - **The logs show `failed with error code 400`**: make sure the templates match this page and every value goes through `toJson`. The response body names the missing or unsupported field diff --git a/en/on-call/integration/alert-integration/alert-sources/atatus.mdx b/en/on-call/integration/alert-integration/alert-sources/atatus.mdx index 52bd94d6..7c43bb84 100644 --- a/en/on-call/integration/alert-integration/alert-sources/atatus.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/atatus.mdx @@ -9,7 +9,6 @@ Sync Atatus incidents to Flashduty On-call through an Atatus Webhook notificatio
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Atatus ---- @@ -57,7 +55,6 @@ Trigger an alert rule and confirm Flashduty receives an active alert. After the ## Payload ---- Atatus POSTs these fields as `application/json`. Flashduty parses them directly, with no template to configure: @@ -77,14 +74,12 @@ Atatus POSTs these fields as `application/json`. Flashduty parses them directly, Other fields, including `target_name`, `acknowledge_url`, `account_id`, `alert_url` and `timestamp`, are not stored. ## Alert Key ---- Flashduty uses `incident_id` as the Alert Key. The open and close notifications of one Atatus incident carry the same `incident_id`, so they land on the same alert. What counts as one incident is set by the policy's **Incident preference** (by policy, by rule, or by rule and target), and Flashduty follows it. A request without `incident_id` is rejected with a parameter error, because its close notification could not be matched to the original alert. ## Status and severity ---- | Atatus field | Flashduty status or severity | | :--- | :--- | @@ -96,7 +91,6 @@ A request without `incident_id` is rejected with a parameter error, because its A request whose `status` is empty or any other value is rejected, so a request of unknown state never lands in the wrong lifecycle. ## FAQ ---- @@ -113,7 +107,6 @@ The channel test only checks that the URL is reachable and opens a separate Info ## Troubleshooting ---- - **Atatus fails to deliver**: confirm the URL is the full push URL and includes `integration_key` - **Flashduty returns a parameter error**: confirm the request has `incident_id` and that `status` is `Opened`, `Closed` or `Acknowledged` diff --git a/en/on-call/integration/alert-integration/alert-sources/auth0.mdx b/en/on-call/integration/alert-integration/alert-sources/auth0.mdx index e5eca44b..6c26265c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/auth0.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/auth0.mdx @@ -9,7 +9,6 @@ Auth0 log streams deliver tenant logs in near real time to a custom webhook. Set
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Auth0 ---- @@ -65,19 +63,16 @@ Auth0 log streams have no "send test notification" button. ## Events and recovery ---- Auth0 sends each tenant log once and never sends an update or a recovery. Each log has a unique `log_id`, which Flashduty uses as the Alert Key. A retried delivery of the same log does not create a duplicate alert, and different logs each create their own Flashduty alert. Alerts do not recover automatically. Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) (24 hours suggested), or close alerts by hand after handling them. When the same source IP triggers many logs, configure a noise-reduction rule on the channel to merge them into one incident. ## Alert Key ---- The Alert Key is computed from the log's `log_id`. An alertable log without `log_id` is rejected with an invalid-parameter error. ## Severity ---- Severity follows the log type code (`type`); logs with any other type code are ignored: @@ -92,7 +87,6 @@ Severity follows the log type code (`type`); logs with any other type code are i For the full list of type codes, see [Auth0 log event type codes](https://auth0.com/docs/deploy-monitor/logs/log-event-type-codes). ## Labels ---- | Label | Source | | :--- | :--- | @@ -109,7 +103,6 @@ For the full list of type codes, see [Auth0 log event type codes](https://auth0. The alert description comes from the log's `description` and `details.error.message`. Flashduty does not read the user's email, the User-Agent, or other fields. ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: confirm Content Type is `application/json` and check the `integration_key` in the Payload URL - **No alert arrives**: confirm the log type is in the table above, the Health tab shows Active, and the stream's event category filter does not exclude that type diff --git a/en/on-call/integration/alert-integration/alert-sources/auvik.mdx b/en/on-call/integration/alert-integration/alert-sources/auvik.mdx index c1e66b25..85664aca 100644 --- a/en/on-call/integration/alert-integration/alert-sources/auvik.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/auvik.mdx @@ -9,7 +9,6 @@ Use the Webhook integration of Auvik to send alerts on devices, interfaces, netw
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Auvik ---- Webhook integrations can be managed only from the MSP global view in Auvik, and you need the matching administrative permission. The webhook URL must use HTTPS, which the Flashduty push URL does. @@ -70,12 +68,10 @@ Auvik requires standard English characters in organization names. Webhook alerts ## Alert Key ---- Flashduty uses `correlationId` from the notification as the Alert Key. Auvik documents it as the unique API identifier of the alert trigger. The triggered and cleared notifications of one alert carry the same `correlationId` but different `alertId` values, so Flashduty does not use `alertId`. Changes to the alert name, severity, description, or time do not change the Alert Key. A notification that has a status but no `correlationId` is rejected. ## Status and severity ---- Flashduty derives the status from `alertStatusString` (or `alertStatus` when the string is missing) and the severity from `alertSeverity` (or `alertSeverityString` when the number is missing): @@ -94,7 +90,6 @@ Flashduty derives the status from `alertStatusString` (or `alertStatus` when the A missing or unrecognized severity is treated as Warning. ## Labels ---- | Label | Source | | :--- | :--- | @@ -108,7 +103,6 @@ A missing or unrecognized severity is treated as Warning. | `url` | Link to the alert in Auvik | ## Troubleshooting ---- - **Test Connection fails**: Confirm the webhook URL is complete, includes `integration_key`, and uses HTTPS - **No alerts arrive**: Confirm the notification channel is associated with the alerts and uses this Webhook integration as its contact method diff --git a/en/on-call/integration/alert-integration/alert-sources/aws-cloudwatch.mdx b/en/on-call/integration/alert-integration/alert-sources/aws-cloudwatch.mdx index 34c2e4a0..e4acf362 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aws-cloudwatch.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aws-cloudwatch.mdx @@ -8,7 +8,6 @@ This integration receives the HTTPS subscription of an Amazon SNS topic. The tri
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## Configure in AWS ----
1. Log in to the AWS console and open `Simple Notification Service` @@ -69,7 +67,6 @@ The subscription works with **Raw message delivery** on or off. With raw deliver ## Other AWS services that publish to SNS ---- Send the notifications of these services to the same `Flashduty` topic. No other setup is needed. @@ -98,7 +95,6 @@ In the budget **Alert** settings, choose **Amazon SNS Alerts** and enter the ARN Each unrecognized message (plain text or other JSON) creates one Warning alert. The Alert Key is the SNS `MessageId`, so an SNS retry of the same message does not create a second alert. The title is the SNS `Subject`, or the first line of the message when there is no subject. These alerts do not recover automatically. ## Alert Key ---- | Message | Alert Key | Recovers when | | :--- | :--- | :--- | @@ -110,7 +106,6 @@ Each unrecognized message (plain text or other JSON) creates one Warning alert. `ALARM`, `INSUFFICIENT_DATA` and `OK` of a CloudWatch alarm share one Alert Key; changes to the alarm name, threshold, reason or description do not split the alert. A CloudWatch alarm message without `AlarmArn` is rejected. ## Status and severity ----
CloudWatch alarms have no severity. `ALARM` and `INSUFFICIENT_DATA` map to Warning by default, and `OK` recovers the alert. @@ -124,7 +119,6 @@ Order service CPU too high flashduty_severity: critical
## Labels ---- - Single-metric alarms: `trigger_metric_name`, `trigger_namespace`, `trigger_dimensions_` and more. When the dimensions include `InstanceId`, it is written to `resource` - Metric math and anomaly detection alarms: each query writes `trigger_expression_`, `trigger_metric_` (`namespace/metric name`) and `trigger_dimensions_`. `metric` and `check` come from the query that returns data @@ -132,7 +126,6 @@ Order service CPU too high flashduty_severity: critical - All alarms: `alarm_arn`, `aws_account_id`, `region`, `new_state_value`, `old_state_value` ## Troubleshooting ---- - **Subscription stays in `Pending confirmation`**: Make sure the endpoint is the full push URL including `integration_key`, then run **Request confirmation** on the subscription in the SNS console - **Flashduty returns a SubscribeURL error**: Flashduty only visits subscription confirmation URLs on `sns..amazonaws.com`, `sns..amazonaws.com.cn` and `sns..amazonaws.eu`. Make sure the subscription request comes from Amazon SNS diff --git a/en/on-call/integration/alert-integration/alert-sources/aws-eventbridge.mdx b/en/on-call/integration/alert-integration/alert-sources/aws-eventbridge.mdx index eac543ad..d55530f0 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aws-eventbridge.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aws-eventbridge.mdx @@ -8,7 +8,6 @@ This integration receives Amazon EventBridge events, either pushed directly by a
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## Configure in AWS EventBridge ---- Use either of the following delivery methods. @@ -101,7 +99,6 @@ Use either of the following delivery methods. Flashduty only visits subscription confirmation URLs on `sns..amazonaws.com`, `sns..amazonaws.com.cn` and `sns..amazonaws.eu`. ## Event rule ---- Use an event pattern in the rule, for example: @@ -131,7 +128,6 @@ Do not filter out recovery states in the rule, or alerts cannot recover automati AWS Health sends events to the Region where they occur; events of global services arrive in `us-east-1`. Create the rule in every Region you care about. ## Alert Key and recovery ---- | Source | `detail-type` | Alert Key | Recovers when | | :--- | :--- | :--- | :--- | @@ -150,7 +146,6 @@ AWS Health sends events to the Region where they occur; events of global service - GuardDuty sends no event when a finding is archived, so close the alert manually ## Severity ---- EventBridge events have no common severity field, so every event triggers as Warning, as it always has. The source's own severity is kept in a label, and an [alert pipeline](/en/on-call/integration/alert-integration/alert-pipelines) can rewrite the severity based on it: @@ -166,7 +161,6 @@ EventBridge events have no common severity field, so every event triggers as War For CloudWatch alarms, set the severity with `flashduty_severity: critical` (`critical`, `warning` or `info`) in the **Alarm description**, the same way as in the [AWS CloudWatch integration](/en/on-call/integration/alert-integration/alert-sources/aws-cloudwatch). ## Title and labels ---- - The alert title is `source::detail-type`, for example `aws.guardduty::GuardDuty Finding` - Every event carries the labels `source`, `region`, `account`, `check` (`detail-type`), `detail` (the event `detail` as JSON) and `resources` @@ -174,7 +168,6 @@ For CloudWatch alarms, set the severity with `flashduty_severity: critical` (`cr - Sources with dedicated handling also add source fields such as `finding_id`, `finding_arn`, `event_arn`, `config_rule_name` and `insight_id`; `resource` is the affected resource (DevOps Guru insights have none) ## Troubleshooting ---- - **API destination invocations fail**: Make sure the endpoint is the full push URL including `integration_key` and `HTTP method` is `POST` - **SNS subscription stays in `Pending confirmation`**: Make sure the subscription points to this integration's push URL, then run **Request confirmation** in the SNS console diff --git a/en/on-call/integration/alert-integration/alert-sources/aws-health.mdx b/en/on-call/integration/alert-integration/alert-sources/aws-health.mdx index 3f21c793..4e8ba96c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aws-health.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aws-health.mdx @@ -9,7 +9,6 @@ AWS Health sends the service events that affect your account (operational issues
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the AWS EventBridge integration type** in both, not AWS Health. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the AWS Ev
## Configure in AWS ---- AWS Health events are forwarded by an EventBridge rule whose target is an API destination that points to the Flashduty push URL (an SNS topic target also works). The steps for both target types are in the [AWS EventBridge integration](/en/on-call/integration/alert-integration/alert-sources/aws-eventbridge); for AWS Health you only need the event pattern below. @@ -66,14 +64,12 @@ Do not filter out `statusCode` in the event pattern, for example by matching onl ## Regions and backup rules ---- - Create a rule in every Region you want to receive events from. Global events (for example IAM-related events) are delivered to US East (N. Virginia), `us-east-1` - In the standard AWS partition, events are also sent to the backup Region US West (Oregon). If you create rules in both the primary and the backup Region, the same event arrives twice; both copies have the same `eventArn` and affected account, so Flashduty merges them into one alert through the same Alert Key - To keep only the primary Region's events, add the filter `"backupEvent": ["false"]` (`detail.backupEvent`) to the backup Region rule ## Field mapping ---- | AWS Health field | Flashduty | | :--- | :--- | @@ -88,12 +84,10 @@ Do not filter out `statusCode` in the event pattern, for example by matching onl | `region`, `account`, `resources`, `detail` | Labels `region`, `account`, `resources`, `detail` (`detail` holds the event detail as JSON) | ## Severity ---- EventBridge events carry no common severity field, so every AWS Health event triggers as Warning. To differentiate, rewrite the severity by the `event_type_category` label in [Alert processing](/en/on-call/integration/alert-integration/alert-pipelines), for example `issue` to Critical and `scheduledChange` kept at Warning or lowered to Info. ## Recovery and deduplication ---- - AWS Health sends an update with `statusCode` set to `closed` when the event ends, and Flashduty recovers the alert with the same Alert Key - Scheduled changes (`scheduledChange`) are sent with status `upcoming` before they start, so Flashduty triggers alerts ahead of time. If you only care about ongoing incidents, restrict `eventTypeCategory` to `issue` in the event pattern @@ -101,7 +95,6 @@ EventBridge events carry no common severity field, so every AWS Health event tri - Events without `detail.eventArn` are rejected (HTTP 400) ## Troubleshooting ---- - **The rule does not fire**: check the event pattern; public events can take up to an hour after the rule is created; make sure rules exist in the event's Region and in `us-east-1` for global events - **The alert does not recover**: confirm the event pattern does not filter out the `closed` status and that the target has no Input transformer (the full event must be sent) diff --git a/en/on-call/integration/alert-integration/alert-sources/aws-security-hub.mdx b/en/on-call/integration/alert-integration/alert-sources/aws-security-hub.mdx index 16848384..2fb49cb2 100644 --- a/en/on-call/integration/alert-integration/alert-sources/aws-security-hub.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/aws-security-hub.mdx @@ -9,7 +9,6 @@ AWS Security Hub sends each finding to Amazon EventBridge as a **Security Hub Fi
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the AWS EventBridge integration type** in both, not AWS Security Hub. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the AWS Ev
## Configure in AWS ---- 1. Follow "Option 1: API destination" in the [AWS EventBridge integration](/en/on-call/integration/alert-integration/alert-sources/aws-eventbridge) to create the Connection and API destination, using the Flashduty push URL as the endpoint. "Option 2: SNS topic" also works 2. In the EventBridge console, create a rule and choose **Rule with an event pattern** for **Rule type** @@ -67,7 +65,6 @@ Do not filter on `Workflow.Status`, `RecordState`, `Compliance.Status` or `Sever Create the rule in every Region where Security Hub is enabled. **Security Hub Findings - Custom Action** events, sent by custom actions, also carry findings and are handled the same way; add that `detail-type` to the rule if you use them. ## Field mapping ---- The `detail.findings` array of a **Security Hub Findings - Imported** event holds a single finding. The mapping below is how Flashduty processes these AWS EventBridge events: @@ -82,14 +79,12 @@ The `detail.findings` array of a **Security Hub Findings - Imported** event hold | Event `source`, `region`, `account`, `detail-type`, `detail` | Labels `source`, `region`, `account`, `check`, `detail` | ## Recovery and deduplication ---- - Changing a finding's workflow status to **Resolved** or **Suppressed** in Security Hub, or archiving the finding, produces a new **Security Hub Findings - Imported** event, and Flashduty closes the alert with the same Alert Key. - When an event contains several findings, each finding becomes its own alert. - If an event lacks `Id` or `ProductArn`, Flashduty returns HTTP 400. ## Troubleshooting ---- - **The API destination call fails**: confirm the endpoint is the full push URL including `integration_key` and that `HTTP method` is `POST` - **Alerts do not recover**: check whether the rule's event pattern filters on `Workflow.Status` or `RecordState`, and whether the target has an Input transformer (the full event must be sent) diff --git a/en/on-call/integration/alert-integration/alert-sources/axiom.mdx b/en/on-call/integration/alert-integration/alert-sources/axiom.mdx index 76d68e13..c9ab5c70 100644 --- a/en/on-call/integration/alert-integration/alert-sources/axiom.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/axiom.mdx @@ -9,7 +9,6 @@ Use an Axiom custom webhook notifier to send monitor alerts to Flashduty On-call
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Axiom ---- @@ -96,7 +94,6 @@ Make a threshold monitor's condition actually hold (for example, lower the thres ## Alert Key ---- Flashduty builds the Alert Key from `event.monitorID`. When the notification carries groups (`event.groupKeys` is not empty), the group names and values are part of the Alert Key too. Axiom's documentation defines `.MonitorID` as the unique identifier of the monitor the notification belongs to; with **Notify by group** on, each group triggers separately and the notification carries that group's values. @@ -105,7 +102,6 @@ Flashduty builds the Alert Key from `event.monitorID`. When the notification car - Changes to the monitor name, description, current value, or times do not change the Alert Key ## Status and severity ---- Axiom notifications carry no severity, so Flashduty sets every Axiom alert to Critical. To use another severity, adjust it by the `check` or `monitor_id` label with an [Alert Pipeline](/en/on-call/integration/alert-integration/alert-pipelines). @@ -116,7 +112,6 @@ Axiom notifications carry no severity, so Flashduty sets every Axiom alert to Cr | Empty or any other value | Rejects the request | ## Labels ---- | Label | Source | | :--- | :--- | @@ -133,7 +128,6 @@ Axiom notifications carry no severity, so Flashduty sets every Axiom alert to Cr The alert description is the notification's `event.body`: for a threshold monitor, the current value compared with the threshold; for a match monitor, the matched event. ## Troubleshooting ---- - **Flashduty returns a parameter error**: confirm the body is still the default template above and `monitorID` and `action` are not empty - **The alert does not recover**: match monitors send no recovery, so turn on auto-close. A threshold monitor sends `Closed` only when a later run no longer crosses the threshold diff --git a/en/on-call/integration/alert-integration/alert-sources/azure-monitor.mdx b/en/on-call/integration/alert-integration/alert-sources/azure-monitor.mdx index e5f0d8f4..de29dfa9 100644 --- a/en/on-call/integration/alert-integration/alert-sources/azure-monitor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/azure-monitor.mdx @@ -8,7 +8,6 @@ Sync Azure Monitor alert events to Flashduty via webhook for automated alert noi
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In Azure Monitor ---- **Step 1: Configure webhook**
@@ -72,7 +70,6 @@ Metric alerts, log search alerts, Prometheus alerts, Application Insights smart
## Service Health ----
1. In the Azure Portal, go to `Service Health -> Health alerts` and click `Create service health alert`; @@ -86,7 +83,6 @@ The Service Health sample sent by `Test action group` is at the `Resolved` stage
## Resource Health ----
1. In the Azure Portal, go to `Service Health -> Resource health` and click `Add resource health alert`; @@ -98,7 +94,6 @@ Each resource maps to one Flashduty alert, with the Alert Key derived from the r
## Defender for Cloud security alerts ----
Defender for Cloud writes its security alerts to the `Security` category of the activity log. In `Alerts -> Alert rules`, create an alert rule whose condition is an activity log signal with category `Security`, and select the Action group created above. @@ -108,7 +103,6 @@ With the common alert schema, the alert title is "alert rule name on resource na
## Other activity log alerts ----
Administrative, Policy, Autoscale, and Recommendation activity log alerts are one-shot events: each notification creates one Flashduty alert that does not recover automatically. With the common alert schema, the alert title is "alert rule name on resource name" and the operation goes into the `operation_name` label. Without it, the payload has no rule name, so the title is "operation on resource", for example `Microsoft.Compute/virtualMachines/restart/action on test-VM`. @@ -116,7 +110,6 @@ Administrative, Policy, Autoscale, and Recommendation activity log alerts are on
## Alert Key and recovery ----
| Alert type | Alert Key source | Recovers when | @@ -133,7 +126,6 @@ Dimensions of metric and log alerts (for example `ApiName` or `Computer`), the m
## Status mapping ----
Azure Monitor to Flashduty alert severity mapping: @@ -151,7 +143,6 @@ Noncommon metric alerts and Log Alerts V1 express severity as `0` to `4`, mapped
## FAQ ----
- **Azure reports a failed webhook call (400)**: check whether the log search alert uses a custom JSON payload. Enable the common alert schema and retry. diff --git a/en/on-call/integration/alert-integration/alert-sources/azure-service-health.mdx b/en/on-call/integration/alert-integration/alert-sources/azure-service-health.mdx index 3cea2f72..7efcb836 100644 --- a/en/on-call/integration/alert-integration/alert-sources/azure-service-health.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/azure-service-health.mdx @@ -9,7 +9,6 @@ Azure writes service issues, planned maintenance, health advisories and security
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the Azure Monitor integration type** in both, not Azure Service Health. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Azure
## Configure in Azure ---- ### Step 1: Create an action group with a webhook @@ -51,7 +49,6 @@ Azure requires that the action group used by a Service Health alert has its regi 5. Click **Advanced options**, select the action group from Step 1 on the **Actions** tab, and create the rule ## Field mapping ---- | Service Health field | Flashduty | | :--- | :--- | @@ -64,7 +61,6 @@ Azure requires that the action group used by a Service Health alert has its regi | Subscription ID + `trackingId` | Label `service_health_url`, which links to the event's Service Health page | ## Title and description ---- | | Common alert schema on | Off (legacy `Microsoft.Insights/activityLogs`) | | :--- | :--- | :--- | @@ -75,14 +71,12 @@ Azure requires that the action group used by a Service Health alert has its regi With the common schema, the event title and text stay in the JSON of the `alertContext` label. If you want the event title directly in notifications, use the legacy payload (leave the common alert schema off). ## Recovery and deduplication ---- - Azure sends several notifications for one Tracking ID as the event progresses, and Flashduty merges them through the Alert Key; the alert recovers when the event reaches a resolved stage - Legacy notifications without `properties.trackingId` are rejected (HTTP 400); with the common schema, a notification without a Tracking ID becomes its own alert and does not recover automatically - Planned maintenance recovers in the `Complete` or `Canceled` stage; until then, the alert stays triggered ## Troubleshooting ---- - **The action group does not fire**: confirm the action group's region is **Global** and that the alert rule's **Actions** tab has this action group selected - **The alert does not recover**: confirm the alert rule is still enabled and wait for Azure to send the notification for the resolved stage diff --git a/en/on-call/integration/alert-integration/alert-sources/baidu-bcm.mdx b/en/on-call/integration/alert-integration/alert-sources/baidu-bcm.mdx index 6fc87a23..2914a37c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/baidu-bcm.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/baidu-bcm.mdx @@ -8,7 +8,6 @@ Sync Baidu Cloud BCM alerts to Flashduty via webhook for automated alert noise r
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Baidu Cloud BCM ----
1. Log in to your Baidu Cloud Console, search for the `Cloud Monitor` product, and enter its console @@ -58,7 +56,6 @@ Choose this option when you need to route alerts to different channels based on
## Status Mapping ----
Severity level mapping from Baidu Cloud Monitor to Flashduty: diff --git a/en/on-call/integration/alert-integration/alert-sources/bgpalerter.mdx b/en/on-call/integration/alert-integration/alert-sources/bgpalerter.mdx index 9916f773..ba9debaf 100644 --- a/en/on-call/integration/alert-integration/alert-sources/bgpalerter.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/bgpalerter.mdx @@ -11,7 +11,6 @@ BGPalerter sends each event once and never sends a recovery notification. Close
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure BGPalerter ---- BGPalerter has no fixed webhook format: the request body comes from the `reportHTTP` template in `config.yml`. Flashduty parses only the JSON that the template below produces, so use it as is. @@ -87,7 +85,6 @@ BGPalerter has no "send test notification" button. Running `bgpalerter -t` (in D ## Events and recovery ---- Each channel in `channels` is one kind of event: @@ -106,7 +103,6 @@ Each channel in `channels` is one kind of event: BGPalerter sends no recovery notification, so Flashduty never closes these alerts automatically. Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) (24 hours suggested). Hijack events usually need a human check, so you can also close them by hand once handled. ## Alert Key ---- Flashduty computes the Alert Key from the routing facts of the event: the channel (`channel`), the monitored prefix (`prefix`), the monitored AS (`asn`), the new origin AS (`neworigin`), and the prefix actually announced (`newprefix`). BGPalerter itself groups hijack events by origin AS and prefix. @@ -118,7 +114,6 @@ Flashduty computes the Alert Key from the routing facts of the event: the channe A request without `channel`, or without any of prefix, AS, and summary, is rejected with an error. ## Labels ---- | Label | Source | | :--- | :--- | @@ -136,7 +131,6 @@ A request without `channel`, or without any of prefix, AS, and summary, is rejec The alert title is BGPalerter's event summary, and the description is the prefix description. ## Troubleshooting ---- - **Flashduty receives no alerts**: check that `hooks.default` is the full HTTPS push URL with `integration_key`. BGPalerter only writes a failed post to its own log and does not retry - **BGPalerter logs a JSON parse error**: check the prefix descriptions in `prefixes.yml` for double quotes or line breaks diff --git a/en/on-call/integration/alert-integration/alert-sources/bigpanda.mdx b/en/on-call/integration/alert-integration/alert-sources/bigpanda.mdx index 1638fb9c..747f3145 100644 --- a/en/on-call/integration/alert-integration/alert-sources/bigpanda.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/bigpanda.mdx @@ -11,7 +11,6 @@ Notifications Webhook v2 can currently only be created and updated through BigPa
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -48,14 +47,12 @@ Choose this method when you need to route alerts to different channels based on
## Prerequisites ---- - **Permissions**: calling the Notifications Webhook v2 API needs the **Integrations** permission; creating an AutoShare rule needs the **Notifications** permission (view, add, edit, and delete AutoShare rules). - **Authentication**: the Notifications Webhook v2 API currently only accepts credentials from a **User Account** — a Service Account cannot call it. - This integration does not parse a fixed BigPanda schema. It parses the JSON template you paste into the request body in step one below — keep the field names exactly as given. ## Configure BigPanda ---- @@ -120,14 +117,12 @@ Trigger a real alert in that environment (or wait for the next real one) and con ## Alert Key ---- Flashduty uses the request body's `incident_id` (from BigPanda's template variable `{{incident.id}}`) directly as the Alert Key. BigPanda's documentation defines `incident.id` as the incident's system-generated unique identifier; an incident's creation, updates, and closure all share the same `incident.id`. Changes to `status`, `environment`, `host`, `check`, `description`, or `url` do not change the Alert Key. ## Status and severity ---- | BigPanda `incident.status` | Flashduty status | Flashduty severity | | :--- | :--- | :--- | @@ -139,7 +134,6 @@ Changes to `status`, `environment`, `host`, `check`, `description`, or `url` do `incident.status` is the most severe status among the incident's correlated alerts. `unknown` means BigPanda could not determine health from the correlated alerts; the incident is still open, so it is treated as Warning. An empty or unrecognized `status` is rejected. ## Labels ---- | Label | Source | | :--- | :--- | @@ -153,7 +147,6 @@ Changes to `status`, `environment`, `host`, `check`, `description`, or `url` do The alert title uses `check` first; when the template's `{{primaryAlert.tags.check}}` is empty, it falls back to `description`. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/bitdefender.mdx b/en/on-call/integration/alert-integration/alert-sources/bitdefender.mdx index 857b6b25..93113348 100644 --- a/en/on-call/integration/alert-integration/alert-sources/bitdefender.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/bitdefender.mdx @@ -9,7 +9,6 @@ The GravityZone Event Push Service posts detection events to a URL as JSON-RPC 2
## In Flashduty On-call ---- You can get the push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the push URL in either of the following ways.
## In GravityZone ---- The Event Push Service is configured only through the GravityZone public API; the console has no screen for it. @@ -99,12 +97,10 @@ Flashduty opens a separate Info alert titled `Bitdefender GravityZone test notif ## Turn on auto-close ---- Detection events are one-shot, and GravityZone never pushes a recovery. In the channel that receives them, turn on [auto-close](/en/on-call/channel/create-edit) with a suggested duration of 24 hours, counted from **Incident trigger**. While an alert is open, a repeat detection of the same threat merges into it; a detection after it closes creates a new alert. ## Supported event types ---- Only the detection events in the table create alerts. Status and inventory events (such as `modules`, `sva`, `registration`, `task-status`, `install`, `uninstall`, `uc` and `adcloud`) are ignored: Flashduty returns success and does nothing, so do not subscribe to them. @@ -126,19 +122,16 @@ Only the detection events in the table create alerts. Status and inventory event GravityZone publishes no severity scale for detection events, so these levels are a mapping made from the event fields. To change them, configure routing or alert processing rules on labels in the channel. ## Alert Key ---- GravityZone detection events have no event ID, so Flashduty builds the Alert Key from the parts of an event that do not change: `module`, `companyId`, the endpoint ID (`computer_id`, or `endpointId` for Sandbox Analyzer), and the threat identity of that event type. Antimalware uses the malware type, name and file path; Antiphishing uses the phishing type and URL; Ransomware Mitigation uses the attack type and attack source. Changes to the action taken, counters, times, hashes, host name and IP do not change the Alert Key. Incidents use `incident_id`. `new-incident` and `new-extended-incident` share one Alert Key, so version updates of one incident merge into one alert. Events without an endpoint ID or `incident_id` are rejected. ## Batches ---- One `addEvents` request can carry several events. Flashduty creates one alert per event and processes them sorted by Alert Key. It handles at most 100 events per request; the rest create no alerts and the response returns an error. If one event is malformed, the others are still created and the response names the malformed event's position and the reason. ## Labels ---- | Label | Source | | :--- | :--- | @@ -153,12 +146,10 @@ One `addEvents` request can carry several events. Flashduty creates one alert pe User names, mail senders and recipients, mail subjects and incident nodes (`nodes`) are never written to labels or the description. ## About signatures ---- GravityZone sends `md5(api_key, md5(request body))` in the `Event-Push-Service-Md5` header, and you can set an `authorization` header in `serviceSettings`. Flashduty verifies neither. The `integration_key` in the push URL is the only credential, so keep it safe. ## Troubleshooting ---- - **`setPushEventSettings` returns an error**: confirm the API key has Event Push Service API selected and that `serviceType` is `jsonRPC` - **Flashduty receives nothing**: confirm the push URL is a publicly reachable HTTPS address that supports TLS 1.2 or later; GravityZone treats anything other than a 2xx response as a failure diff --git a/en/on-call/integration/alert-integration/alert-sources/bleemeo.mdx b/en/on-call/integration/alert-integration/alert-sources/bleemeo.mdx index dad23b20..9c0cce0c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/bleemeo.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/bleemeo.mdx @@ -9,7 +9,6 @@ Use a Bleemeo webhook integration to send metric status changes to Flashduty On-
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Bleemeo ---- @@ -56,7 +54,6 @@ Push a metric past its threshold (for example, temporarily lower a CPU usage thr ## Payload ---- Bleemeo POSTs a JSON notification. Flashduty parses it directly, with no template to configure: @@ -70,14 +67,12 @@ Bleemeo POSTs a JSON notification. Flashduty parses it directly, with no templat | `status_text` | Status text | Label `status_text` | ## Alert Key ---- Flashduty uses `metric` as the Alert Key. The alert and recovery notifications of one metric carry the same `metric`, so they land on the same alert, while different metrics produce different alerts. The top-level `id` is not part of the Alert Key, and changes to the title, value, or time do not change it. If `metric` is missing, Flashduty returns a parameter error, because a recovery cannot be reliably matched to its alert. ## Status and severity ---- | Bleemeo `status` | Flashduty status or severity | | :--- | :--- | @@ -89,7 +84,6 @@ If `metric` is missing, Flashduty returns a parameter error, because a recovery A request with an empty or any other `status` is rejected, so a request whose state is unclear never enters the wrong alert lifecycle. ## FAQ ---- @@ -112,7 +106,6 @@ No. `3` (Unknown) is handled as Warning, and only `0` (OK) closes the alert. ## Troubleshooting ---- - **The test notification opens an Info alert**: the test sent after saving a target has no metric and is recognised by its fixed body (status `10`, title `Test`); it opens its own Info alert that never recovers, so close it manually diff --git a/en/on-call/integration/alert-integration/alert-sources/blueking.mdx b/en/on-call/integration/alert-integration/alert-sources/blueking.mdx index cdc80059..2bb1f35d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/blueking.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/blueking.mdx @@ -8,7 +8,6 @@ Sync Tencent BlueKing monitoring events to Flashduty via webhook for automated a
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Tencent BlueKing ---- The following content has been verified on `BlueKing V6/7 versions`. V5 and below versions are no longer officially supported, and upgrading is recommended. BlueKing alert policies can trigger `Action Plans`, which can integrate with external systems for complex functionalities. First, create an Action Plan and configure the Flashduty callback URL, then edit the alert policy to associate actions with this plan, enabling automatic alert changes to be pushed to Flashduty. Here are the specific steps: @@ -82,7 +80,6 @@ BlueKing alert policies can trigger `Action Plans`, which can integrate with ext
## Status Mapping ----
Alert severity mapping between BlueKing and Flashduty: diff --git a/en/on-call/integration/alert-integration/alert-sources/blumira.mdx b/en/on-call/integration/alert-integration/alert-sources/blumira.mdx index 342d6db9..4d306563 100644 --- a/en/on-call/integration/alert-integration/alert-sources/blumira.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/blumira.mdx @@ -9,7 +9,6 @@ Use a Blumira webhook to send security findings to Flashduty On-call. Each Blumi
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Blumira ---- @@ -74,19 +72,16 @@ Wait for a real Blumira finding and confirm Flashduty receives the active alert. ## About signatures ---- Blumira signs each delivery in the `X-Blumira-Signature` header (format `t=,v1=`). Flashduty does not verify this signature and does not need the signing secret. The `integration_key` in the push URL is the only credential, so keep it private. ## Alert Key ---- Flashduty uses `data.finding_id` as the Alert Key. The `finding.created` and `finding.status.changed` examples in Blumira's documentation carry the same `finding_id`, so the trigger, status updates, and recovery land on one alert. Changes to the title, priority, status, or time do not change the Alert Key. A request without `data.finding_id` is rejected with a parameter error. ## Status and severity ---- | Blumira event | Flashduty behavior | | :--- | :--- | @@ -108,7 +103,6 @@ Flashduty treats only `resolved` as recovery. Blumira's documentation shows no o Alert labels include the finding ID, short ID, type, category, priority, source country, and link. Owner and actor names and emails are not written to the alert. ## Troubleshooting ---- - **Blumira reports failed deliveries or auto-disabled the webhook**: check that the push URL is complete and includes `integration_key`. Blumira disables a webhook after sustained failures; fix the cause and re-enable it under **Edit** - **No alerts arrive**: confirm the webhook is enabled and the event filters include `finding.created` diff --git a/en/on-call/integration/alert-integration/alert-sources/bugsnag.mdx b/en/on-call/integration/alert-integration/alert-sources/bugsnag.mdx index 29720a90..629eeb11 100644 --- a/en/on-call/integration/alert-integration/alert-sources/bugsnag.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/bugsnag.mdx @@ -9,7 +9,6 @@ Use the Webhook (data forwarding) integration of a BugSnag project to send error
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure BugSnag ---- The Webhook integration is configured per project and requires administrative privileges on the project. Configure it once for each project you want to connect. @@ -82,14 +80,12 @@ The filters below the triggers, such as release stage and handled state, reduce ## Alert Key ---- Flashduty uses the BugSnag error ID (`error.errorId`) as the Alert Key. BugSnag groups repeated occurrences of the same exception into one error, and every occurrence, frequency notification, reopen, and state change of that error carries the same `errorId`, so they merge into one alert, which the error's state change recovers. The per-occurrence event ID (`error.id`), error message, release stage, and severity do not change the Alert Key. Error events without `errorId` are rejected. ## Status and severity ---- Flashduty sets the alert severity from the error's severity (`error.severity`): @@ -109,7 +105,6 @@ The trigger type sets the status: | `errorStateManualChange` with state `reopened`, `snoozeCancelled`, or `unignored` | Trigger | ## Labels ---- | Label | Source | | :--- | :--- | @@ -128,7 +123,6 @@ The trigger type sets the status: | `url` | Link to the error in BugSnag | ## Troubleshooting ---- - **Flashduty returns a parameter error**: Confirm that the URL is complete and includes `integration_key` - **No alert after clicking Test**: This is expected. The test request does not create an alert; verify with a real error diff --git a/en/on-call/integration/alert-integration/alert-sources/calibre.mdx b/en/on-call/integration/alert-integration/alert-sources/calibre.mdx index 0fdc51e4..226018cc 100644 --- a/en/on-call/integration/alert-integration/alert-sources/calibre.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/calibre.mdx @@ -9,7 +9,6 @@ Use a Calibre site webhook to send performance budget status changes to Flashdut
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Calibre ---- @@ -60,7 +58,6 @@ Calibre webhooks have no test button. You can also set a shared secret under **S ## Payload ---- The main fields of a budget notification are parsed directly, with no template to configure: @@ -77,14 +74,12 @@ The main fields of a budget notification are parsed directly, with no template t | `budgets` | Status and measured value per test profile and page | Written to the alert description | ## Alert Key ---- Flashduty builds the Alert Key from the site identifier `site_id` and the budget ID `id`. At-risk, exceeded and met notifications for the same budget carry the same Alert Key and land on one alert; different budgets or sites produce different alerts. Changing the budget name, status or measured value does not change the Alert Key. If `id` or `site_id` is missing, Flashduty returns a parameter error because a met notification could not be tied to its alert reliably. ## Status and severity ---- | Calibre `status` | Flashduty state or severity | | :--- | :--- | @@ -95,7 +90,6 @@ If `id` or `site_id` is missing, Flashduty returns a parameter error because a m A budget notification with an empty or any other `status` is rejected, so a request whose state cannot be determined never enters the wrong alert lifecycle. ## FAQ ---- @@ -112,7 +106,6 @@ No. A snapshot notification only reports a completed test run. Flashduty returns ## Troubleshooting ---- - **Calibre fails to deliver**: confirm the payload URL is the full push URL and includes `integration_key` - **Flashduty returns a parameter error**: confirm the request is a budget notification with non-empty `id`, `site_id` and `status` diff --git a/en/on-call/integration/alert-integration/alert-sources/canarytokens.mdx b/en/on-call/integration/alert-integration/alert-sources/canarytokens.mdx index 28bf9d11..96eeac03 100644 --- a/en/on-call/integration/alert-integration/alert-sources/canarytokens.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/canarytokens.mdx @@ -9,7 +9,6 @@ Canarytokens, by Thinkst, creates decoys such as web bugs, DNS names, Word, Exce
## In Flashduty On-call ---- You can get the push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the push URL in either of the following ways.
## In Canarytokens ---- @@ -60,7 +58,6 @@ Canarytokens alerts are one-shot and are never recovered. In the channel that re ## Event types ---- Canarytokens posts one JSON object per event and never posts a recovery. @@ -71,17 +68,14 @@ Canarytokens posts one JSON object per event and never posts a recovery. | The test request sent when the webhook is saved | Creates a separate Info alert that never recovers | ## Alert Key ---- Flashduty computes the Alert Key from `token`, the token's fixed identifier. A token touched from different source IPs or through different channels keeps one Alert Key, and changes to the memo, source IP or time do not change it. A request without `token` is rejected. An exposure notice uses `token` plus `key_id`, so it never merges into the token's hit alert. ## Status and severity ---- A honeytoken has no legitimate visitors, so any touch may be an intrusion and hit alerts are always Critical. Exposure notices are Warning and the test request is Info. To grade tokens differently, adjust severity with a channel route or alert processing rule on a label such as `token_type`. ## Labels ---- | Label | Source | | :--- | :--- | @@ -97,12 +91,10 @@ A honeytoken has no legitimate visitors, so any touch may be an intrusion and hi The `manage_url` in the payload carries the auth parameter that controls the token. Flashduty neither reads nor stores it. Use the Canarytokens management page to see the token's details and hit history. ## About signatures ---- The Canarytokens webhook has no signature and sends no dedicated header, so Flashduty does not verify one. The `integration_key` in the push URL is the only credential; keep it private. ## Troubleshooting ---- - **Flashduty receives nothing**: make sure the webhook URL is publicly reachable and not a private address. Canarytokens times out after 2 seconds and does not retry - **The token's webhook was disabled**: Canarytokens disables a webhook after 5 consecutive errors. Fix the push URL and save the webhook again, and confirm the push URL is complete and includes `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/catchpoint.mdx b/en/on-call/integration/alert-integration/alert-sources/catchpoint.mdx index f49f930f..7b61c2e0 100644 --- a/en/on-call/integration/alert-integration/alert-sources/catchpoint.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/catchpoint.mdx @@ -11,14 +11,12 @@ Catchpoint's [default JSON Alert Webhook format](https://docs.catchpoint.com/doc
## In Flashduty On-call ---- Create either a dedicated or shared **Catchpoint** alert integration and copy its complete Push URL.
## Configure Catchpoint ---- @@ -82,7 +80,6 @@ Let a test actually trigger a Warning or Critical alert, and confirm Flashduty r ## Alert Key ---- Flashduty derives the Alert Key from `test_id`, `alert_group_item_id`, and `alert_initial_trigger_epoch` combined. @@ -91,7 +88,6 @@ Catchpoint's own [PagerDuty Events API v2 integration template](https://docs.cat Changes to the title, description, severity, number of triggered nodes, or threshold never change the Alert Key. ## Status and alert severity ---- Catchpoint's `notification_level_id` has 4 documented values: @@ -105,7 +101,6 @@ Catchpoint's `notification_level_id` has 4 documented values: A request with an empty or unsupported `notification_level_id` is rejected. The Improved notification does not say which level the alert recovered from, so Flashduty shows it at Critical severity; the actual state is the recovery (Ok) status. ## Troubleshooting ---- - **Flashduty returns a parameter error**: confirm **Format** is set to **Template** and the template is valid JSON; confirm `test_id`, `alert_group_item_id`, and `alert_initial_trigger_epoch` are still in the template and their macros were not removed or swapped for another macro - **No alert is created**: confirm the endpoint is selected under **API Endpoints** in the **Alerts** settings of the Test/Folder/Product, or that **Apply to All Alerts** is enabled on the endpoint diff --git a/en/on-call/integration/alert-integration/alert-sources/cato.mdx b/en/on-call/integration/alert-integration/alert-sources/cato.mdx index 0042798a..c14a364e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cato.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cato.mdx @@ -9,7 +9,6 @@ Cato Networks webhooks have no fixed request body; you write the body in CMA. Th
## In Flashduty On-call ---- Get the push URL in either of the following ways. @@ -30,7 +29,6 @@ Get the push URL in either of the following ways.
## In Cato ---- You need permission to manage Subscriptions in CMA. @@ -83,12 +81,10 @@ Field definitions: [Understanding the JSON Fields for Alert Integrations](https: ## Alert Key ---- Flashduty uses `storyId` as the Alert Key, and `correlationId` when `storyId` is empty. Cato defines `storyId` as "Unique identifier for the Site Operations story" and `correlationId` as "Unique identifier used to correlate related events, messages, or operations". Changes to title, level or time never change the Alert Key. A request with neither field is rejected with the field name. ## Status and severity ---- An alert recovers when `storyStatus` is `RESOLVED` or `endDate` is not empty; other states such as `OPEN` and `IN_PROGRESS` trigger or update it. Severity comes from `level`: @@ -101,7 +97,6 @@ An alert recovers when `storyStatus` is `RESOLVED` or `endDate` is not empty; ot | Empty or other | Warning | ## Labels ---- | Label | Source | | :--- | :--- | @@ -116,7 +111,6 @@ An alert recovers when `storyStatus` is `RESOLVED` or `endDate` is not empty; ot | `isp` | `ISPName` | ## Troubleshooting ---- - **Cato test fails**: confirm the URL is complete, includes `integration_key`, and the method is POST - **Flashduty returns a parameter error**: confirm the body is valid JSON and contains `storyId` or `correlationId`. If a title or subject contains double quotes, Cato's substitution may break the JSON; remove the `title` or `subject` field from the template diff --git a/en/on-call/integration/alert-integration/alert-sources/censys.mdx b/en/on-call/integration/alert-integration/alert-sources/censys.mdx index b4684953..2c6b76d3 100644 --- a/en/on-call/integration/alert-integration/alert-sources/censys.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/censys.mdx @@ -9,7 +9,6 @@ Use the Webhook Connection of Censys Attack Surface Management (ASM) to send new
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## In Censys ASM ---- Webhook Connection is available only at the Advanced and Enterprise access levels of Censys ASM. If your firewall or gateway restricts source IPs, allow the Censys egress addresses `52.5.142.59`, `34.226.132.221`, and `52.54.43.157`. @@ -67,14 +65,12 @@ The Censys webhook documentation describes no test button. When ASM finds a new ## Alert Key ---- Flashduty computes the Alert Key from `event.data.risk_id` (the risk type ID) and `event.data.impacted_asset` (the affected asset, such as `Host: 1.1.1.1`). Censys defines a risk instance as one risk type on one asset, but does not state that `risk_id` and `impacted_asset` stay unchanged across deliveries. The same risk type on the same asset gets the same Alert Key, so repeated deliveries merge into one alert; the same risk type on different assets, or different risk types on one asset, produce separate alerts. Changes to the risk name, description, severity, first and last seen times, or the event ID do not change the Alert Key. An event without `risk_id` or `impacted_asset` is rejected. An event whose `event.type` is not `risk_instance_opened` creates no alert; Flashduty acknowledges it and returns success. ## Status and severity ---- Every event is a trigger. Flashduty sets the severity from `risk_severity`: @@ -86,7 +82,6 @@ Every event is a trigger. Flashduty sets the severity from `risk_severity`: | Empty or other | Warning | ## Labels ---- | Label | Source | | :--- | :--- | @@ -103,7 +98,6 @@ Every event is a trigger. Flashduty sets the severity from `risk_severity`: The alert title is the risk description (`risk_description`, or the risk name when empty) followed by the affected asset. ## Troubleshooting ---- - **Webhook Connection is missing**: check that the Censys ASM access level is Advanced or Enterprise - **The integration does not work**: Censys requires the receiver to accept the top-level `event` field; the Flashduty push URL needs no extra handling diff --git a/en/on-call/integration/alert-integration/alert-sources/centreon.mdx b/en/on-call/integration/alert-integration/alert-sources/centreon.mdx index b19c2719..7115f4f2 100644 --- a/en/on-call/integration/alert-integration/alert-sources/centreon.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/centreon.mdx @@ -9,7 +9,6 @@ Centreon ships a PagerDuty Events stream connector (`pagerduty-events-apiv2.lua`
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the PagerDuty Compatible integration type** in both, not Centreon. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the PagerD
## Configure in Centreon ---- ### Step 1: Install the stream connector @@ -83,7 +81,6 @@ curl -X POST -H 'content-type: application/json' '' -d '{"dedup_key":" Flashduty should return HTTP 202 and an alert should appear; send it again with `event_action` set to `resolve` and the alert recovers. ## Field mapping ---- How the fields sent by the Centreon connector (see the connector source) map to Flashduty: @@ -107,14 +104,12 @@ Severity set by the connector for each Centreon state: | Service UNKNOWN | `error` | Critical | ## Recovery and deduplication ---- - A host or service always uses the same Alert Key, so a change from WARNING to CRITICAL updates the same alert and a return to OK or UP recovers it - With the connector library's default parameters only HARD states are sent, and objects that are acknowledged or in scheduled downtime are not sent; to change this, adjust `hard_only`, `acknowledged` and `in_downtime` in the connector parameters - To push only some objects, use the connector's filter parameters such as `accepted_hostgroups`, `accepted_servicegroups` and `accepted_pollers` ## Troubleshooting ---- - **Flashduty receives no alert**: check `/var/log/centreon-broker/pagerduty-events.log` (the default log file; `log_level` goes up to 3); confirm `http_server_url` is the full push URL and `pdy_routing_key` is set - **The connector log shows a failed POST**: the connector only treats HTTP 202 as success, and Flashduty answers PagerDuty Events API v2 requests with 202; for other status codes, check that `integration_key` is correct diff --git a/en/on-call/integration/alert-integration/alert-sources/cert-spotter.mdx b/en/on-call/integration/alert-integration/alert-sources/cert-spotter.mdx index 7ace2c11..2c8b7880 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cert-spotter.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cert-spotter.mdx @@ -9,7 +9,6 @@ Cert Spotter is SSLMate's certificate monitoring service. It continuously watche
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Cert Spotter ---- Webhook notifications are available on the Cert Spotter Startup plan and above. The Hobbyist plan only sends email. @@ -59,7 +57,6 @@ Cert Spotter has no button that sends a test delivery. Issue a new certificate f ## Payload ---- | Cert Spotter event | Result in Flashduty | | :--- | :--- | @@ -69,19 +66,16 @@ Cert Spotter has no button that sends a test delivery. Issue a new certificate f Cert Spotter sends expiration reminders and installation problems only by email and Slack, not by webhook, so they do not reach this integration. ## Alert Key ---- Flashduty uses the ID of the certificate issuance (`id` in the webhook) as the Alert Key. A network problem can deliver the same request more than once; the duplicate carries the same `id` and merges into the same alert. Different certificates create different alerts. Deliveries without `id` are rejected. ## Severity ---- Cert Spotter sends no severity, so every unknown certificate triggers a **Warning** alert. Whether the certificate has been revoked is recorded in the `revoked` label and does not change the severity. ## Labels ---- | Label | Source | | :--- | :--- | @@ -99,7 +93,6 @@ Cert Spotter sends no severity, so every unknown certificate triggers a **Warnin The alert title is `Unknown certificate for `, followed by `(+N more)` when the certificate covers several names. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/cfengine.mdx b/en/on-call/integration/alert-integration/alert-sources/cfengine.mdx index a66ac260..f291bf0a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cfengine.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cfengine.mdx @@ -11,7 +11,6 @@ The CFEngine Enterprise Mission Portal has no webhook notification method, but a
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure CFEngine ---- The steps below are based on CFEngine Enterprise 3.27. Uploading custom action scripts and associating them with alerts requires the admin role in Mission Portal. The script only needs `bash` and `curl` on the hub. @@ -97,7 +95,6 @@ CFEngine has no "send test notification" button. To verify a real alert, make th ## Alert Key ---- Flashduty uses the CFEngine alert ID `ALERT_ID` as the Alert Key. The CFEngine documentation describes it as the alert's unique ID. The trigger, reminder, and clear deliveries of one alert carry the same `ALERT_ID`, so they land on the same Flashduty alert. Changes to the alert name, severity, failed host count, or timestamps do not change the Alert Key. @@ -106,7 +103,6 @@ Flashduty uses the CFEngine alert ID `ALERT_ID` as the Alert Key. The CFEngine d Flashduty rejects a request that has no `ALERT_ID`, or whose `ALERT_STATUS` is not `fail` or `success`. ## Alert lifecycle ---- One CFEngine alert covers all the hosts it is defined for. Flashduty creates one alert for it and records the failed host count in the description and labels. @@ -117,7 +113,6 @@ One CFEngine alert covers all the hosts it is defined for. Flashduty creates one | Alert cleared | `success` | Recover the alert | ## Alert severity ---- The severity comes from the severity selected when the alert was created, `ALERT_SEVERITY`: @@ -131,7 +126,6 @@ The severity comes from the severity selected when the alert was created, `ALERT A recovery event keeps the alert's severity. ## Alert content ---- - **Title**: the alert name `ALERT_NAME` - **Description**: the condition description `ALERT_CONDITION_DESCRIPTION`, followed by `Triggered on of hosts.` @@ -140,7 +134,6 @@ A recovery event keeps the alert's severity. Timestamp parameters (`ALERT_LAST_CHECK`, `ALERT_LAST_EVENT_TIME`, `ALERT_LAST_STATUS_CHANGE`), `ALERT_STATUS`, and the condition description are not written to labels, and neither are empty parameters. Each alert holds at most 50 labels; if there are more, the ones beyond the limit in name order are dropped. ## Troubleshooting ---- - **The script reports HTTP 4xx**: confirm that `FLASHDUTY_URL` is the full push URL and includes `integration_key` - **The script cannot be selected in Mission Portal**: confirm that the current user has the admin role and that the script is saved under **Custom notification scripts** diff --git a/en/on-call/integration/alert-integration/alert-sources/check-point-smartevent.mdx b/en/on-call/integration/alert-integration/alert-sources/check-point-smartevent.mdx index 477aa5b5..6e23f115 100644 --- a/en/on-call/integration/alert-integration/alert-sources/check-point-smartevent.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/check-point-smartevent.mdx @@ -9,7 +9,6 @@ SmartEvent automatic reactions offer Mail, SNMP Trap, Block Source, Block Event
## In Flashduty On-call ---- You can get the integration email address in either of two ways. **Choose the Email integration type in both cases**, not Check Point. @@ -29,12 +28,10 @@ You can get the integration email address in either of two ways. **Choose the Em
## Confirm the push mode in Flashduty ---- SmartEvent sends one mail per event and no recovery mail, and the subject carries the event number (see [Mail subject format](#mail-subject-format)), so every mail is an independent event. Set the Email integration's push mode to the one that always triggers a new alert (the create page may preselect a different mode, so check it): each mail creates a new alert whose title is the mail subject and whose description is the mail body. No trigger or close rules are needed. ## In Check Point SmartConsole ---- Paths follow the Check Point R81.10 administration guide. @@ -47,12 +44,10 @@ Paths follow the Check Point R81.10 administration guide. 7. Save, reference the automatic reaction in the event definitions you want notifications for, and install the policy ## Mail subject format ---- The default **Subject** of the Mail reaction is `[EventNumber] - [Severity] - [Name]`: event number, severity and event name. Flashduty uses the mail subject as the alert title. ## Limitations ---- - **No recovery**: SmartEvent sends no recovery mail. Enable [auto-resolve timeout](/en/on-call/channel/create-edit) on the channel that receives this integration (24 hours suggested), or close alerts manually in Flashduty. - **No deduplication**: the subject contains the event number, so each event creates its own alert. diff --git a/en/on-call/integration/alert-integration/alert-sources/checkly.mdx b/en/on-call/integration/alert-integration/alert-sources/checkly.mdx index bcbd931f..73c4579e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/checkly.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/checkly.mdx @@ -9,14 +9,12 @@ Use a Checkly Webhook Alert Channel to send check-state changes to Flashduty On-
## In Flashduty On-call ---- Create either a dedicated or shared **Checkly** alert integration and copy its complete Push URL.
## Configure Checkly ---- @@ -81,7 +79,6 @@ A Checkly test notification or webhook HTTP 200 proves connectivity only. Use re ## Alert Key ---- Normal check-state notifications use the trimmed `check_id` (Checkly variable `CHECK_ID`) as the Alert Key. Titles, errors, run locations, response times, result IDs, and alert-state changes do not affect it. @@ -92,7 +89,6 @@ If `check_id` is missing or empty, Flashduty accepts the request and generates a `ALERT_SSL` is an independent one-shot Warning event. It always receives a new random UUID, even when the payload includes `check_id`, and does not update or recover the Check's normal state alert. ## Status and severity ---- | Checkly `ALERT_TYPE` | Flashduty status | Flashduty severity | | :--- | :--- | :--- | @@ -106,7 +102,6 @@ If `check_id` is missing or empty, Flashduty accepts the request and generates a An empty or unknown `alert_type` returns an invalid-parameter response. Recovery is determined only by `alert_type`, not by the title or error text. ## Labels and description ---- Flashduty creates these labels: @@ -134,7 +129,6 @@ The request body, labels, and description all have hard limits, handled as follo A label value that is empty after trimming is not written to the alert. ## Delivery and troubleshooting ---- Checkly retries a failed webhook delivery up to five times at approximately 20-second intervals. Use Checkly's Alert Notification Log to inspect the final delivery result. diff --git a/en/on-call/integration/alert-integration/alert-sources/checkmk.mdx b/en/on-call/integration/alert-integration/alert-sources/checkmk.mdx index 933451ec..f81dbcc0 100644 --- a/en/on-call/integration/alert-integration/alert-sources/checkmk.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/checkmk.mdx @@ -9,7 +9,6 @@ Checkmk has no generic webhook notification method. This integration provides a
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Checkmk ---- The steps below are based on Checkmk 2.5. Menu names may differ slightly in other 2.x versions. The script only needs the Python 3 that ships with Checkmk; nothing else has to be installed. @@ -113,7 +111,6 @@ You can also send a test from **Test notifications** under **Setup → Events ## Alert Key ---- Flashduty computes the Alert Key from the host name `HOSTNAME` and the service name `SERVICEDESC`. Host notifications use an empty service name. Problem and recovery notifications for the same host or service carry the same host and service names, so they land on the same alert. When the state rises to a higher severity (for example a service going from WARN to CRIT), Flashduty opens a new alert at the higher severity and keeps the earlier alert open; the recovery notification closes both. @@ -122,7 +119,6 @@ Changes to the state, plugin output, notification number, time, host address, si Flashduty rejects a request that lacks `HOSTNAME`, `WHAT`, the current state, or `NOTIFICATIONTYPE`, and a service notification that lacks `SERVICEDESC`. ## Alert lifecycle ---- Checkmk sends a recovery notification only after it has sent a problem notification. Acknowledgement, downtime, flapping, and custom notifications are also sent when the problem notification was suppressed (for example while a service flaps). An alert opened from them would never get a recovery notification to close it. So only problem notifications open alerts, and Flashduty handles each notification type `NOTIFICATIONTYPE` as follows: @@ -139,7 +135,6 @@ While a service flaps, Checkmk sends no state change notifications: a return to Ignored notifications get a success response, so Checkmk does not retry them. ## Severity ---- Severity comes from the current state: `SERVICESTATE` for service notifications and `HOSTSTATE` for host notifications. @@ -155,7 +150,6 @@ Severity comes from the current state: `SERVICESTATE` for service notifications A recovery event takes the severity of the hard state before recovery (`PREVIOUSSERVICEHARDSTATE` or `PREVIOUSHOSTHARDSTATE`). ## Alert content ---- - **Title**: ` on ` for service notifications, `Host ` for host notifications - **Description**: the plugin output `SERVICEOUTPUT` or `HOSTOUTPUT`, followed by the long output when present @@ -164,7 +158,6 @@ A recovery event takes the severity of the hard state before recovery (`PREVIOUS Each alert carries at most 50 labels. When there are more, labels beyond the limit are dropped in name order. Contact details such as contact names and email addresses are not written to labels. ## Troubleshooting ---- - **Flashduty is not listed as a method in Checkmk**: make sure the script is in the site's `local/share/check_mk/notifications/` directory, is named `flashduty`, is executable, and has `# Flashduty` on its second line - **No notification is sent**: check the site's `var/log/notify.log` to confirm the rule matched the event and that the user under **Recipient** has not disabled notifications diff --git a/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx b/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx index 4cf9fd55..fa6a56a1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/chronosphere.mdx @@ -9,7 +9,6 @@ Chronosphere's webhook notifier sends an HTTP POST to the URL you enter. The bod
## 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. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Promet
## Configure in Chronosphere ---- @@ -59,7 +57,6 @@ Trigger an alert from a monitor and confirm Flashduty receives an active alert; ## Field mapping ---- | Chronosphere field | Flashduty | | :--- | :--- | @@ -75,7 +72,6 @@ Trigger an alert from a monitor and confirm Flashduty receives an active alert; One notification can carry several alerts, and Flashduty handles each one separately (up to 100 per request). ## Recovery and deduplication ---- - When Chronosphere sends a notification with `status` set to `resolved`, Flashduty closes the alert with the same `fingerprint`. - If the notifier does not send resolved notifications, Flashduty never receives a recovery request and the alert stays active. In that case enable [auto-resolve timeout](/en/on-call/channel/create-edit) on the channel. @@ -83,7 +79,6 @@ One notification can carry several alerts, and Flashduty handles each one separa - Chronosphere's documentation does not say whether the webhook notifier has a test send. After the first setup, verify with a real alert that both the trigger and the recovery show up in Flashduty. ## Troubleshooting ---- - **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not Prometheus - **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 diff --git a/en/on-call/integration/alert-integration/alert-sources/circonus.mdx b/en/on-call/integration/alert-integration/alert-sources/circonus.mdx index b301dd48..a92b44bb 100644 --- a/en/on-call/integration/alert-integration/alert-sources/circonus.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/circonus.mdx @@ -9,7 +9,6 @@ Use the webhook contact method of a Circonus contact group to send alerts raised
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Circonus ---- @@ -63,14 +61,12 @@ Let a rule fire and confirm Flashduty shows an active alert, then let the metric ## Alert Key ---- Flashduty uses the `alert_id` of each alert as the Alert Key. The Circonus alert link has the form `...fault-detection?alert_id=`, and a recovery notification carries all fields of the original alert plus `clear_value` and `clear_time`, so the trigger and the recovery share one `alert_id`. The `alerts` array of one request can hold several alerts; each becomes its own Flashduty event. Changes to the rule, metric, severity, value, or time never change the Alert Key. A request whose alert has no `alert_id` is rejected, because a later recovery could not be matched. ## Status and severity ---- Circonus severities run from 1 to 5, where 1 is the most severe. @@ -84,7 +80,6 @@ Circonus severities run from 1 to 5, where 1 is the most severe. A notification with `clear_time` or `clear_value` is treated as a recovery and keeps the original severity. A body with no `alerts`, or an empty `alerts` array, returns success and creates no alert. ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: check that the URL ends with `&format=json` and that every alert has a non-empty `alert_id` - **The alert does not recover**: check that the contact group is assigned to that severity of the rule and that Circonus has cleared the alert; the recovery must carry the same `alert_id` as the trigger diff --git a/en/on-call/integration/alert-integration/alert-sources/cloudamqp.mdx b/en/on-call/integration/alert-integration/alert-sources/cloudamqp.mdx index e4502985..ea01d283 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cloudamqp.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cloudamqp.mdx @@ -9,7 +9,6 @@ Use a webhook recipient of CloudAMQP alarms to send instance alarms to Flashduty
## In Flashduty On-call ---- You can get the push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the push URL in either of the following ways.
## In CloudAMQP ---- @@ -59,7 +57,6 @@ To get repeated reminders, set a **Reminder interval** on the alarm (minimum 30 ## Event types ---- CloudAMQP pushes one alarm subject per request, as JSON. @@ -72,17 +69,14 @@ CloudAMQP pushes one alarm subject per request, as JSON. CloudAMQP retries when the webhook returns a non-2xx status. Duplicate pushes carry the same Alert Key and merge into one alert. ## Alert Key ---- Flashduty computes the Alert Key from `dedup_key`. It combines the alarm type and its subject (for a queue alarm, `queue::/`), and the trigger, reminder, and resolve pushes of one subject carry the same value. Changes to the threshold, time threshold, current value, or subject text do not change the Alert Key. A request without `dedup_key` is rejected. ## Status and severity ---- CloudAMQP pushes carry no severity, so every alarm type is Warning in Flashduty, and `resolved: true` recovers the alert. To distinguish severity, use a label such as `alarm_type` in the channel's routing or alert processing rules. ## Labels ---- | Label | Source | | :--- | :--- | @@ -96,7 +90,6 @@ CloudAMQP pushes carry no severity, so every alarm type is Warning in Flashduty, | `data_*` | Fields of the `data` object, such as `data_value`, `data_name`, `data_type` | ## Troubleshooting ---- - **Flashduty receives nothing**: confirm the webhook recipient is added to the alarm's Recipients, and check the recipient's status column in the alarms list for errors - **Invalid parameter error**: confirm the URL is complete and includes `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/cloudflare.mdx b/en/on-call/integration/alert-integration/alert-sources/cloudflare.mdx index c88560e6..21b447e7 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cloudflare.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cloudflare.mdx @@ -8,7 +8,6 @@ Sync Cloudflare alert events to Flashduty via webhook for automated alert noise
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -44,7 +43,6 @@ Choose this method when you need to route alerts to different channels based on ## In Cloudflare ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/clustercontrol.mdx b/en/on-call/integration/alert-integration/alert-sources/clustercontrol.mdx index 2acd4271..c94aa0fe 100644 --- a/en/on-call/integration/alert-integration/alert-sources/clustercontrol.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/clustercontrol.mdx @@ -9,7 +9,6 @@ Use **Notification Services → Webhook** in Severalnines ClusterControl to send
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In ClusterControl ---- @@ -62,7 +60,6 @@ ClusterControl only notifies for alarms raised after the integration is created; ## Payload ---- ClusterControl POSTs the following JSON fields. Flashduty parses them directly, with no template to configure: @@ -80,7 +77,6 @@ ClusterControl POSTs the following JSON fields. Flashduty parses them directly, The alert title is `title`; when empty, it is `ClusterControl alarm `. ## Alert Key ---- Flashduty uses the alarm `id` as the Alert Key. The ClusterControl documentation states that when an alarm ends it sends another event with the same alarm ID and `status` set to `ENDED`, so the created, changed and ended notifications land on the same Flashduty alert, and different `id` values produce different alerts. Changing the title, host or severity does not change the Alert Key. @@ -89,7 +85,6 @@ The documented payload has no cluster ID (ClusterControl 2.1.0 also sends `contr When a request has no `id`, Flashduty returns a parameter error, because a recovery could not be matched to its alert reliably. ## Status and severity ---- | ClusterControl field | Flashduty status or severity | | :--- | :--- | @@ -101,7 +96,6 @@ When a request has no `id`, Flashduty returns a parameter error, because a recov A request whose `status` is empty or any other value is rejected, so a request with an unknown state never enters the wrong alert lifecycle. ClusterControl forwards only `CREATED` and `ENDED` by default; `CHANGED` must be enabled with the `allowed_events` parameter of `cmon-events`. ## FAQ ---- @@ -124,7 +118,6 @@ In ClusterControl, a muted alarm type sends no notification until it is unmuted. ## Troubleshooting ---- - **Flashduty receives no alert**: confirm the URL is the complete push URL (including `integration_key`), that the `cmon-events` process is running, and that notifications are enabled for the cluster and events - **Flashduty returns a parameter error**: confirm the body is ClusterControl's JSON and that `id` and `status` are not empty diff --git a/en/on-call/integration/alert-integration/alert-sources/consul.mdx b/en/on-call/integration/alert-integration/alert-sources/consul.mdx index 716e72b4..da172ed6 100644 --- a/en/on-call/integration/alert-integration/alert-sources/consul.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/consul.mdx @@ -11,7 +11,6 @@ This integration works with both Consul Community Edition and Consul Enterprise.
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -48,7 +47,6 @@ Choose this method when you need to route alerts to different channels based on
## How it works ---- Whenever any watched health check changes (its status or its output), a Consul watch of type `checks` POSTs the current state of **all** watched checks to the push URL as one JSON array. Flashduty turns each check in the array into one event: @@ -59,14 +57,12 @@ Whenever any watched health check changes (its status or its output), a Consul w The watch sends the current state once as soon as it is loaded, so checks that are already `warning` or `critical` raise alerts right away. ## Prerequisites ---- - **Network**: the Consul agent that runs the watch must be able to reach the Flashduty push URL (for example `https://api.flashcat.cloud`). - **Permissions**: you need to be able to edit that agent's configuration directory (for example `/etc/consul.d`) and run `consul reload`. - **ACL**: when ACLs are enabled, the token the watch uses needs read access to all nodes and services, as described below. ## In Consul ---- @@ -149,7 +145,6 @@ When ACLs are enabled, add `-H "X-Consul-Token: "` to each command. ## Alert Key ---- Flashduty builds the Alert Key from `Partition`, `Node`, and `CheckID`. @@ -162,7 +157,6 @@ Changes to a check's status, name, output, or notes do not change its Alert Key. A watch only returns the checks of its own datacenter, and the payload does not include the datacenter name. If several datacenters share one integration and have nodes with the same name, checks with the same ID on those nodes merge into one alert. We recommend one integration per datacenter. ## Status and severity ---- | Consul `Status` | Flashduty status | Flashduty severity | | :--- | :--- | :--- | @@ -173,7 +167,6 @@ A watch only returns the checks of its own datacenter, and the payload does not When a check moves between `warning` and `critical`, Flashduty keeps one alert per severity: `warning` turning `critical` creates a new Critical alert, and `passing` recovers both. ## Labels ---- | Label | Source | | :--- | :--- | @@ -190,7 +183,6 @@ When a check moves between `warning` and `critical`, Flashduty keeps one alert p The alert title is ` on `, and the alert description is the check's `Output` and `Notes`. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/contrast.mdx b/en/on-call/integration/alert-integration/alert-sources/contrast.mdx index be5738ad..2256e01f 100644 --- a/en/on-call/integration/alert-integration/alert-sources/contrast.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/contrast.mdx @@ -11,7 +11,6 @@ Contrast's generic webhook has no fixed payload; the body is the template you en
## In Flashduty On-call ---- Get the push URL in either of the following ways. @@ -32,7 +31,6 @@ Get the push URL in either of the following ways.
## In Contrast Security ---- @@ -67,7 +65,6 @@ Click **Add**. Contrast disconnects a webhook after 5 consecutive attempts witho ## Events and Alert Key ---- | Contrast event | `event_type` | Effect in Flashduty | Alert Key field | | :--- | :--- | :--- | :--- | @@ -81,7 +78,6 @@ Changes to severity, status, title, or application do not change the Alert Key. Server-offline alerts and the events in the last row have no recovery event. Configure **Auto-close after timeout** (for example 24 hours) on the integration or channel, or close them manually. ## Severity mapping ---- Mapped from `$Severity`: @@ -95,7 +91,6 @@ Mapped from `$Severity`: When a vulnerability is closed the alert recovers and keeps the severity carried by the closing event. ## Labels ---- | Label | Source | | :--- | :--- | @@ -110,7 +105,6 @@ When a vulnerability is closed the alert recovers and keeps the severity carried | `organization` / `organization_id` | Organization name and ID | ## Troubleshooting ---- - **Contrast reports the webhook as disconnected**: Flashduty returned a non-2XX response. Check that the URL contains `integration_key` and that the Payload is the template above and valid JSON, then test and save again in Contrast - **The alert does not recover**: confirm the vulnerability moved to a closed status in Contrast. Other status changes (such as Confirmed or Suspicious) send no event diff --git a/en/on-call/integration/alert-integration/alert-sources/coralogix.mdx b/en/on-call/integration/alert-integration/alert-sources/coralogix.mdx index 9c71c8f6..a4ac3c21 100644 --- a/en/on-call/integration/alert-integration/alert-sources/coralogix.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/coralogix.mdx @@ -9,7 +9,6 @@ Use a Coralogix Notification Center Generic HTTPS connector to send alerts to Fl
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Coralogix ---- These steps require Notification Center admin permissions (create connectors, presets, and routers, and edit alert definition labels). @@ -101,7 +99,6 @@ Let the alert actually trigger and confirm that Flashduty receives an active ale ## Alert Key ---- Flashduty uses `alert.groupingKey` as the Alert Key. Coralogix defines `groupingKey` as the deduplication key in its alert notification schema, and its official Opsgenie and Jira Service Management setups use `groupingKey` to close the matching alert on `Resolved`. @@ -110,7 +107,6 @@ With **Separate cases**, each Group by combination is notified separately with i Changes to the title, description, priority, or group values do not change the Alert Key. ## Status and severity ---- Flashduty uses `status` to tell triggers from recoveries, and `priority` (`alert.highestPriority`, or the alert definition priority when empty) to set the severity. @@ -126,7 +122,6 @@ Flashduty uses `status` to tell triggers from recoveries, and `priority` (`alert When `status` is `Resolved`, Flashduty recovers the original alert and keeps its last severity. An empty or any other `status` is rejected. ## Labels ---- | Label | Source | | :--- | :--- | @@ -142,7 +137,6 @@ When `status` is `Resolved`, Flashduty recovers the original alert and keeps its An alert can have at most 50 labels. Requests that exceed this limit are rejected. ## Troubleshooting ---- - **Coralogix reports a delivery failure**: Confirm that the connector URL is the complete push URL and includes `integration_key` - **Flashduty returns a parameter error**: Confirm that the preset Body matches the template above, renders valid JSON, and that `grouping_key` and `status` are not empty diff --git a/en/on-call/integration/alert-integration/alert-sources/coroot.mdx b/en/on-call/integration/alert-integration/alert-sources/coroot.mdx index 76d472d3..0ca1383f 100644 --- a/en/on-call/integration/alert-integration/alert-sources/coroot.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/coroot.mdx @@ -9,7 +9,6 @@ Sync the alerts (alerting rules) and SLO incidents of a Coroot project to Flashd
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Coroot ---- @@ -76,7 +74,6 @@ Coroot only sends webhooks for categories that have notifications enabled. ## Alert Key ---- Flashduty uses the ID carried in the `url` field of the Coroot notification as the Alert Key: @@ -88,7 +85,6 @@ Flashduty uses the ID carried in the `url` field of the Coroot notification as t Coroot generates a unique ID when it creates an alert or incident, and the open and resolve notifications use the same one. If the same rule fires again on the same application, Coroot creates a new ID, so it is a new Flashduty alert. Changes to severity, rule name, summary or the domain in `url` never change the Alert Key. ## Status and severity ---- Coroot sends a notification only when an alert or incident opens or resolves; a severity change in between is not notified. @@ -104,7 +100,6 @@ Coroot sends a notification only when an alert or incident opens or resolves; a - An unrecognized `status` is treated as Warning, so that Coroot is not made to pause later notifications by an error response ## Labels ---- | Label | Meaning | | :--- | :--- | @@ -117,7 +112,6 @@ Coroot sends a notification only when an alert or incident opens or resolves; a | Custom fields | Custom fields configured on the integration | ## Troubleshooting ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/cronicle.mdx b/en/on-call/integration/alert-integration/alert-sources/cronicle.mdx index 59a7479a..14e73146 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cronicle.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cronicle.mdx @@ -9,7 +9,6 @@ Use the Cronicle event web hook to send job failures and launch failures to Flas
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Cronicle ---- @@ -61,7 +59,6 @@ An alert closes only when the next job of the same event succeeds. Events that a ## Payload ---- Cronicle POSTs the following fields as JSON. Flashduty parses them directly, with no template to configure: @@ -80,12 +77,10 @@ Cronicle POSTs the following fields as JSON. Flashduty parses them directly, wit The body also contains the event parameters (`params`) and the web hook URL (`web_hook`). Flashduty neither reads nor stores these two fields. ## Alert Key ---- Flashduty uses `event` (the event ID) as the Alert Key. Every job of the same event carries the same `event`, and only the job ID `id` changes per run, so failures, launch failures, and the later success of one event land on the same alert. Changing the event title, the exit code, or the server that ran the job does not change the Alert Key. ## Status and severity ---- Cronicle notifications carry no severity, so a failed scheduled job is treated as Critical: @@ -99,7 +94,6 @@ Cronicle notifications carry no severity, so a failed scheduled job is treated a The Cronicle web hook has no test button. To check connectivity, run an event once. ## FAQ ---- @@ -122,7 +116,6 @@ The Web Hook URL can be set on a single event or on a category, so fill it in on ## Troubleshooting ---- - **Cronicle does not send anything**: confirm the Web Hook URL is the complete push URL including `integration_key`, and set `debug_level` to 9 to see `Web Hook Error` and `Web Hook Response` entries in the Cronicle log - **Flashduty returns a parameter error**: confirm the body contains `action` and `event`, and that `job_complete` notifications contain `code` diff --git a/en/on-call/integration/alert-integration/alert-sources/cronitor.mdx b/en/on-call/integration/alert-integration/alert-sources/cronitor.mdx index c6542a09..8575ba7b 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cronitor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cronitor.mdx @@ -11,7 +11,6 @@ According to the Cronitor pricing page, webhook alerts are included in the free
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure Cronitor ---- @@ -70,7 +68,6 @@ Cronitor recommends testing alerts with a heartbeat monitor: ## Payload fields ---- Cronitor sends the following fields as JSON: @@ -90,7 +87,6 @@ Cronitor sends the following fields as JSON: The alert title is the issue name; when it is empty, the monitor name, then the monitor key. Every alert also carries the label `source=cronitor`. ## Alert Key ---- Flashduty builds the Alert Key from the monitor key (`id`) and the environment (`environment`): @@ -103,7 +99,6 @@ The monitor key is the same for every outage. After an alert recovers, the next Changing the monitor key, or deleting the monitor and creating it again, produces a new Alert Key that is no longer linked to the old alert. ## Status and severity ---- Cronitor webhooks carry no severity. Flashduty maps them as follows: @@ -115,7 +110,6 @@ Cronitor webhooks carry no severity. Flashduty maps them as follows: `type` is matched case-insensitively. Requests without `id`, or with an empty or any other `type`, are rejected. ## FAQ ---- @@ -134,7 +128,6 @@ Resolving an issue by hand in Cronitor sends no recovery notification. A failure ## Troubleshooting ---- - **Flashduty returns an invalid parameter error**: make sure the push URL is complete (including `integration_key`) and the body has the `id` and `type` fields - **No notifications arrive**: make sure the webhook is selected in the monitor's notification list, and the list's environments include the alert's environment diff --git a/en/on-call/integration/alert-integration/alert-sources/crowdsec.mdx b/en/on-call/integration/alert-integration/alert-sources/crowdsec.mdx index 4b69fe9f..a862ff0a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/crowdsec.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/crowdsec.mdx @@ -9,7 +9,6 @@ The CrowdSec Security Engine is an open-source, self-hosted intrusion detection
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure CrowdSec ---- Do the following on the machine that runs the CrowdSec Local API (LAPI). The HTTP notification plugin ships with CrowdSec, so nothing extra needs to be installed. @@ -98,24 +96,20 @@ An Info alert titled `test alert` appears in Flashduty. It does not recover on i ## What is pushed ---- Each request carries a JSON array with one CrowdSec alert per element; with `group_wait` or `group_threshold`, CrowdSec holds alerts until the next flush, so delivery can lag the detection by up to `group_wait`, and a request may hold several alerts. Flashduty creates one alert per array element. The event details (`events`) and the raw logs in `meta` are not sent to Flashduty. ## Alert Key ---- Flashduty uses the `uuid` that CrowdSec generates for each alert as the Alert Key. A retried request carries the same `uuid` and merges into the same alert; when the same source IP triggers again later, the new alert has a new `uuid` and creates a new Flashduty alert. For older releases that send no `uuid`, Flashduty derives the Alert Key from the scenario, source scope, source value and `start_at`. The request is rejected when those fields are missing. ## Severity ---- CrowdSec provides no severity, so every alert triggers at **Warning**, including alerts in simulation mode (`simulated`). The test alert from `cscli notifications test` is **Info** and uses its own Alert Key, so it never merges with a real alert. ## Labels ---- | Label | Source | | :--- | :--- | @@ -136,7 +130,6 @@ CrowdSec provides no severity, so every alert triggers at **Warning**, including The alert title is ` from ` and the description is the CrowdSec `message`. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/crowdstrike-logscale.mdx b/en/on-call/integration/alert-integration/alert-sources/crowdstrike-logscale.mdx index ca16240d..0938e7d7 100644 --- a/en/on-call/integration/alert-integration/alert-sources/crowdstrike-logscale.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/crowdstrike-logscale.mdx @@ -12,7 +12,6 @@ Falcon LogScale (formerly Humio) describes an always-running query as a **Trigge
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -33,7 +32,6 @@ You can get the integration push URL in either of the following ways.
## Configure Falcon LogScale ---- @@ -75,7 +73,6 @@ LogScale triggers only fire; they never send anything that means "resolved", so ## Payload ---- Flashduty parses the request body against LogScale's own default Message Body Template, sent as `application/json`: @@ -115,7 +112,6 @@ Flashduty parses the request body against LogScale's own default Message Body Te Don't rename or move the fields above in the default template. The template can carry more variables, but Flashduty only reads the fields in this table and ignores the rest. ## Alert Key ---- Flashduty uses `alert.id` (what the LogScale docs define as the Trigger ID) as the Alert Key directly: @@ -124,12 +120,10 @@ Flashduty uses `alert.id` (what the LogScale docs define as the Trigger ID) as t - A request without `alert.id` is rejected ## Status and severity ---- LogScale's default template carries no severity field, so every alert opens as Warning. ## FAQ ---- @@ -152,7 +146,6 @@ No. Flashduty identifies the integration by the `integration_key` in the push UR ## Troubleshooting ---- - **"Problem invoking test action" when clicking Test action**: usually means `{id}` and other template variables had no real value at test time, so Flashduty rejected the empty `alert.id`. Trigger a real match with your query to verify instead - **No alert in Flashduty**: check that the action's URL is complete (including `integration_key`) and that the action is attached to a trigger diff --git a/en/on-call/integration/alert-integration/alert-sources/crowdstrike.mdx b/en/on-call/integration/alert-integration/alert-sources/crowdstrike.mdx index b8183da8..99d769bd 100644 --- a/en/on-call/integration/alert-integration/alert-sources/crowdstrike.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/crowdstrike.mdx @@ -9,7 +9,6 @@ CrowdStrike Falcon has no built-in generic alert webhook: detection notification
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure CrowdStrike Falcon ---- The steps below need permission to create and release (publish) Fusion SOAR workflows in the Falcon console. The NG-SIEM Detection trigger needs the Next-Gen SIEM module; the EPP Detection trigger needs Falcon Insight/Prevent endpoint detection. The Falcon cloud must be able to reach the domain of the push URL. @@ -85,7 +83,6 @@ To also ingest endpoint protection (EPP) detections, repeat the previous step fo ## Alert Key ---- Flashduty uses the `detection_id` field of the request body as the Alert Key. It maps to the Falcon Fusion trigger variable `${data['Trigger.Detection.DetectionID']}` — CrowdStrike's own Fusion workflow authoring reference calls this path "release-verified" (checked to exist at release time), and both the NG-SIEM and EPP detection triggers return it in the same composite-ID format for the same detection. @@ -97,7 +94,6 @@ Flashduty rejects a request that is missing `detection_id`, or whose `severity` Falcon Fusion has no "detection closed" trigger that carries the detection ID, so this integration is one-shot: Flashduty does not close an alert when the detection is closed in Falcon. **Turn on [auto-close](/en/on-call/channel/create-edit) for the channel (24 hours is a reasonable default for security detections).** A repeat of the same detection inside that window refreshes the same alert. ## Severity mapping ---- | CrowdStrike `severity` (SeverityDisplayName) | Flashduty level | | :--- | :--- | @@ -109,7 +105,6 @@ Falcon Fusion has no "detection closed" trigger that carries the detection ID, s | (empty) | **Warning** | ## Alert content ---- - **Title**: `name` (the detection name), falling back to `CrowdStrike detection` when empty - **Labels**: `detection_id`, `product` (`NGSIEM` or `EPP`), `severity_raw` (the raw `severity` value); the NG-SIEM template also sends `source_url`; the EPP template also sends `resource`/`host` (`hostname`), `process_sha256`, `ioc_value`, `ioc_type` @@ -117,7 +112,6 @@ Falcon Fusion has no "detection closed" trigger that carries the detection ID, s Empty fields are not written as labels. ## Troubleshooting ---- - **The workflow shows no error, but Flashduty never receives an alert**: confirm the workflow was **Released**, not just saved as a draft — a draft workflow never runs - **The HTTP Action fails with a 400 in the logs**: check that the body field names match the templates above exactly; the response names the missing or unsupported field (for example `detection_id is required`) diff --git a/en/on-call/integration/alert-integration/alert-sources/ctyun.mdx b/en/on-call/integration/alert-integration/alert-sources/ctyun.mdx index 29fa7690..baaca508 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ctyun.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ctyun.mdx @@ -11,7 +11,6 @@ For resource monitoring events from StateCloud [secondary nodes](#secondary-node
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Dedicated Integration @@ -46,7 +45,6 @@ Choose this option when you need to route alerts to different channels based on
## In StateCloud ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx b/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx index 184ce35d..b01a9549 100644 --- a/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/cubeapm.mdx @@ -9,7 +9,6 @@ CubeAPM can send alert notifications by HTTP POST to any webhook URL. The defaul
## 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. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Promet
## Configure in CubeAPM ---- @@ -49,7 +47,6 @@ Let a CubeAPM alert rule fire and confirm Flashduty receives an active alert; af ## Field mapping ---- | CubeAPM field | Flashduty | | :--- | :--- | @@ -65,13 +62,11 @@ Let a CubeAPM alert rule fire and confirm Flashduty receives an active alert; af One notification can carry several alerts, and Flashduty handles each one separately (up to 100 per request). ## Recovery and deduplication ---- - When CubeAPM sends a notification whose `status` is not `firing` (for example `resolved`), Flashduty closes the alert with the same `fingerprint`. CubeAPM's own PagerDuty and Zenduty examples likewise map any non-`firing` status to a resolve. - The CubeAPM documentation does not say whether the webhook has a test-send function. After the first setup, verify with a real alert that both trigger and recovery appear in Flashduty. ## Troubleshooting ---- - **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not Prometheus - **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 diff --git a/en/on-call/integration/alert-integration/alert-sources/dash0.mdx b/en/on-call/integration/alert-integration/alert-sources/dash0.mdx index 2605c5b5..d0eed200 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dash0.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dash0.mdx @@ -9,14 +9,12 @@ Use a Dash0 webhook notification channel to send check rule alerts to Flashduty
## In Flashduty On-call ---- Create either a dedicated or shared **Dash0** alert integration and copy its complete Push URL.
## Configure Dash0 ---- @@ -42,14 +40,12 @@ Let a check rule cross its threshold and confirm Flashduty receives an active al ## Alert Key ---- Flashduty uses `data.issue.issueIdentifier` as the Alert Key. Dash0 documents it as the "identifier for the combination of CheckRule and Resource, should remain stable over different issue instances", so trigger and recovery carry the same value. `data.issue.id` identifies a single issue instance and `data.issue.checkrules[].id` identifies the check rule. Both are kept as labels only and are not part of the Alert Key. Changes to the title, status, description, start time, or check rule version do not change the Alert Key. An alert-type request without `issueIdentifier` is rejected, because later recovery could not be matched. ## Event types and severity ---- | Dash0 `type` | Flashduty handling | | :--- | :--- | @@ -68,7 +64,6 @@ Flashduty uses `data.issue.issueIdentifier` as the Alert Key. Dash0 documents it Dash0 does not publish the exact meaning of `alert.closed` and `alert.superseded`. Flashduty handles them conservatively: `closed` is treated as the issue having ended, and `superseded` is assumed to be followed by a new `alert.ongoing` for the same identifier, so it does not change alert state. ## Troubleshooting ---- - **Dash0 gets a non-2xx response**: confirm the Push URL is complete and includes `integration_key` - **Flashduty returns an invalid-parameter error**: confirm the body is valid JSON and `data.issue.issueIdentifier` is not empty diff --git a/en/on-call/integration/alert-integration/alert-sources/datadog.mdx b/en/on-call/integration/alert-integration/alert-sources/datadog.mdx index 0bec748a..5d51b09f 100644 --- a/en/on-call/integration/alert-integration/alert-sources/datadog.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/datadog.mdx @@ -9,7 +9,6 @@ Use a Datadog webhook to send Monitor alerts to Flashduty On-call. Flashduty pri
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. ### Use a dedicated integration @@ -45,7 +44,6 @@ Choose this method when you need to route alerts to different channels based on
## Configure a webhook in Datadog ---- @@ -123,7 +121,6 @@ A Datadog test notification can verify webhook connectivity, but only a real fir ## Add custom labels ---- The default payload includes common environment, service, team, and region labels. To send additional Datadog variables, add a `custom_labels` object at the top level of the payload: @@ -152,7 +149,6 @@ Do not encode multiple custom labels in a comma-separated string. Label values c ## Alert Key ---- Flashduty primarily uses `$ALERT_CYCLE_KEY` as the Alert Key. Datadog defines this value as the ID that links events from the time an alert triggers until it resolves, so repeat notifications and recovery events update the same Flashduty alert. @@ -161,7 +157,6 @@ If `alert_cycle_key` is missing or empty, Flashduty generates a random Alert Key `$ID`, `$ALERT_ID`, `$AGGREG_KEY`, the title, severity, timestamps, and custom labels do not participate in Alert Key generation. ## Status and Severity ---- Recovery is determined only from `$ALERT_TRANSITION` and is independent of severity mapping. @@ -177,7 +172,6 @@ Recovery is determined only from `$ALERT_TRANSITION` and is independent of sever To change the severity, remap it with an [Alert Processing Pipeline](/en/on-call/integration/alert-integration/alert-pipelines). ## Troubleshooting ---- - **Datadog does not send a request**: Confirm that the Monitor notification message contains the correct `@webhook-` recipient - **Flashduty returns an invalid parameter error**: Confirm that the payload is valid JSON and contains a non-empty `alert_transition` value diff --git a/en/on-call/integration/alert-integration/alert-sources/datto-rmm.mdx b/en/on-call/integration/alert-integration/alert-sources/datto-rmm.mdx index 2cd1f612..90fb4ef7 100644 --- a/en/on-call/integration/alert-integration/alert-sources/datto-rmm.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/datto-rmm.mdx @@ -11,14 +11,12 @@ Datto RMM sends a request body that you write yourself, so paste the JSON templa
## In Flashduty On-call ---- Create either a dedicated or shared **Datto RMM** alert integration and copy its complete Push URL.
## Configure Datto RMM ---- You can configure the webhook on a single monitor's response settings or globally. **Turning on Global Webhooks automatically disables the webhooks set on individual monitors**, so use one or the other. @@ -93,12 +91,10 @@ Click **Test Webhook** (**Test Alert Webhook** for global webhooks) to confirm D ## Alert Key ---- Flashduty uses `alert_uid` (the Datto RMM variable `[alert_uid]`, documented as "The alert ID") as the Alert Key. The alert-raised and alert-resolved payloads use the same variable, so they refer to the same alert. Changes to device, site, alert type, message, or severity do not change the Alert Key. ## Status and severity ---- | `event` | Flashduty status | | :--- | :--- | @@ -113,12 +109,10 @@ Flashduty uses `alert_uid` (the Datto RMM variable `[alert_uid]`, documented as | Empty or other | Warning | ## About recovery ---- Datto RMM sends the resolved payload only when an alert resolves **automatically**; resolving an alert manually in the console sends nothing. Turn on [auto-close after timeout](/en/on-call/channel/create-edit) in the channel that receives these alerts, with a suggested duration of 24 hours, so manually resolved alerts do not stay open. ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: Check that the payload is valid JSON, `alert_uid` is not empty, and `event` is `triggered` or `resolved` - **The alert does not recover**: Check that **When alert is resolved (optional)** is on and uses the `resolved` template; manually resolved alerts send no recovery diff --git a/en/on-call/integration/alert-integration/alert-sources/db-pull.mdx b/en/on-call/integration/alert-integration/alert-sources/db-pull.mdx index 8b4cf8e3..b2175155 100644 --- a/en/on-call/integration/alert-integration/alert-sources/db-pull.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/db-pull.mdx @@ -13,7 +13,6 @@ DB Pull is the right choice when **alert data is already stored in a relational
## Setup Steps ---- ### In Flashduty @@ -42,7 +41,6 @@ When you need to route alert events to different channels based on the alert pay
## Configuration ---- ### Database Driver @@ -149,14 +147,12 @@ Example configuration: ``` ## Default Route ---- When creating a "Shared Integration" (under **Integration Center => Alert Events**), you must configure a default route — otherwise newly pulled events will be dropped. After creation, you can add finer-grained rules under **Route**. A "Dedicated Integration" (created under **Configuration → Integrations → Private integration** in a specific channel) is automatically bound to that channel and does not require a separate default route. ## Notes ---- - **Database account permissions**: Create a dedicated read-only account for DB Pull with only `SELECT` privilege on the target table. Do not grant write access. - **Network reachability**: The Flashduty service must be able to reach `host:port` over the public internet or a dedicated line. Private subnets (`10.x.x.x`, `192.168.x.x`, `172.16–31.x.x`) and loopback addresses are rejected by the system. diff --git a/en/on-call/integration/alert-integration/alert-sources/dbmarlin.mdx b/en/on-call/integration/alert-integration/alert-sources/dbmarlin.mdx index 07670ec1..f2a84861 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dbmarlin.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dbmarlin.mdx @@ -11,14 +11,12 @@ DBmarlin's webhook has no fixed format: you write the request body in the **Cont
## In Flashduty On-call ---- Create either a dedicated or shared **DBmarlin** alert integration and copy its complete Push URL.
## Configure DBmarlin ---- The Webhook integration requires DBmarlin v5.11 or later, and the webhook you create is marked **Default** and enabled, which is what sends alerts. @@ -95,7 +93,6 @@ Save and enable the integration. Under **Settings → Alert Rules**, create a ru ## Alert Key ---- Flashduty computes the Alert Key from the rule ID (`ruleid`) plus the instance name (`instance`) or host name (`node`); instance alerts and host alerts never share a key. The "started" and "ended" notifications of one rule on the same instance or host share one Alert Key; changes to `from`, `to`, values, and the rule name do not change it. @@ -103,7 +100,6 @@ Flashduty computes the Alert Key from the rule ID (`ruleid`) plus the instance n - When the same rule fires again, it uses the same Alert Key ## Status and severity ---- | DBmarlin `startedended` | Flashduty status or severity | | :--- | :--- | @@ -113,12 +109,10 @@ Flashduty computes the Alert Key from the rule ID (`ruleid`) plus the instance n The webhook body carries no severity, so every alert is treated as Warning. DBmarlin sends `startedended` in upper case (`STARTED`, `ENDED`); Flashduty ignores the case, treats a value starting with `end` as the end and any other value as a start. ## Recovery and auto-close ---- DBmarlin sends an "ended" notification when an alert ends, and Flashduty uses it to recover the alert. To keep a lost notification from leaving an alert open, configure **auto-close after timeout** on the channel or integration, longer than your rules can stay active. ## Troubleshooting ---- - **DBmarlin logs `status code 400`**: confirm the template is valid JSON and contains `ruleid`, plus `instance` (instance alerts) or `node` (host alerts) - **`404` or `401`**: confirm the Webhook URL is complete and contains `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/dead-mans-snitch.mdx b/en/on-call/integration/alert-integration/alert-sources/dead-mans-snitch.mdx index 98a8a0e7..895fdd57 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dead-mans-snitch.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dead-mans-snitch.mdx @@ -11,7 +11,6 @@ According to the Dead Man's Snitch pricing page, integrations are available from
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure Dead Man's Snitch ---- @@ -67,7 +65,6 @@ If your plan includes Error Notices, you can also report a non-zero exit status ## Payload fields ---- Dead Man's Snitch sends the following fields as JSON: @@ -84,7 +81,6 @@ Dead Man's Snitch sends the following fields as JSON: The alert title is the snitch name followed by its state, for example `Nightly Backup is missing`. When the name is empty, `Snitch` is used. Every alert also carries the label `source=dead-mans-snitch`. ## Alert Key ---- The token is the check-in credential of the snitch: anyone who holds it can check in to the snitch. Flashduty therefore never shows the token in alerts and uses the MD5 hash of the token as the Alert Key: @@ -94,7 +90,6 @@ The token is the check-in credential of the snitch: anyone who holds it can chec The token stays the same for the whole life of a snitch. After an alert recovers, the next time the same snitch goes missing a new alert is created; the recovered alert is not reopened. Deleting a snitch and creating it again produces a new token that is no longer linked to the old alert. ## Status and severity ---- Dead Man's Snitch webhooks carry no severity. Flashduty maps them as follows: @@ -108,7 +103,6 @@ Dead Man's Snitch webhooks carry no severity. Flashduty maps them as follows: `type` is case-insensitive. Requests without `data.snitch.token`, or with an empty or other `type`, are rejected. ## FAQ ---- @@ -131,7 +125,6 @@ The first check-in of a new snitch also sends `snitch.reporting`. There is no ac ## Troubleshooting ---- - **Flashduty returns a parameter error**: make sure the push URL is complete (it includes `integration_key`) and the request body contains `type` and `data.snitch.token` - **No notifications arrive**: make sure your plan includes integrations. If the webhook has tag filters, make sure the snitch carries one of those tags diff --git a/en/on-call/integration/alert-integration/alert-sources/dependency-track.mdx b/en/on-call/integration/alert-integration/alert-sources/dependency-track.mdx index 4ba429ff..4f203756 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dependency-track.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dependency-track.mdx @@ -17,7 +17,6 @@ Dependency-Track notifies once when it finds a problem and sends nothing when th
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -38,7 +37,6 @@ You can get the integration push URL in either of the following ways.
## In Dependency-Track ---- @@ -76,7 +74,6 @@ Selecting other groups (for example BOM_CONSUMED or PROJECT_AUDIT_CHANGE) does n ## Alert Key ---- Flashduty builds the Alert Key from the `uuid` values in the notification, joined with an invisible separator and hashed with MD5: @@ -93,7 +90,6 @@ Flashduty builds the Alert Key from the `uuid` values in the notification, joine - When the `uuid` of the project, component, vulnerability or policy violation is missing, Flashduty returns 400 and names the missing field ## Status and severity ---- NEW_VULNERABILITY uses `subject.vulnerability.severity`; NEW_VULNERABLE_DEPENDENCY uses the most severe of its vulnerabilities: @@ -112,21 +108,18 @@ POLICY_VIOLATION carries no vulnerability, so the policy's violation state decid | `INFO` or any other value | Info | ## Alerts do not recover automatically ---- Dependency-Track notifies once per problem and has no "vulnerability fixed" or "violation cleared" notification, so every alert stays open until it is closed. In the channel that receives this integration, turn on [auto-close after timeout](/en/on-call/channel/create-edit) and set it to how quickly your team handles vulnerabilities, for example 7 days. A repeated notification for the same problem (for example the same vulnerability found again after a re-analysis) merges into the alert that is still open; if that alert was closed, a new alert is created. ## Alert content ---- - **Title**: `Dependency-Track: in ()` for NEW_VULNERABILITY; `Dependency-Track: vulnerable dependency in ( vulnerabilities)` for NEW_VULNERABLE_DEPENDENCY; `Dependency-Track: policy violation on ()` for POLICY_VIOLATION - **Description**: the notification content, the project and component, and each vulnerability's source, severity, CVSS scores, aliases and recommendation (at most 10 vulnerabilities for a vulnerable dependency, most severe first); for a policy violation, the policy, violation type and condition - **Labels**: `source=dependency_track`, `group`, `project_uuid`, `project_name`, `project_version`, `component_uuid`, `component_group`, `component_name`, `component_version`, `component_purl`, `vuln_id`, `vuln_source`, `vuln_uuid`, `vuln_severity`, `vuln_count`, `vuln_ids`, `policy_name`, `violation_type`, `violation_state`, `violation_uuid` ## Troubleshooting ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/dingtalk-alert.mdx b/en/on-call/integration/alert-integration/alert-sources/dingtalk-alert.mdx index 242289a5..2f0bab88 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dingtalk-alert.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dingtalk-alert.mdx @@ -9,7 +9,6 @@ Generate a unique Dingtalk robot address in Flashduty, and synchronize the occur
## Operation Steps ---- ### Create DingTalk Bot Compatible Integration @@ -76,12 +75,10 @@ By default, the system always creates new alerts for each message, but you can s - When Dingtalk message type is Text, Flashduty will generate a default alert title "Dingtalk Alert" ## Severity Mapping ---- Currently, all alerts pushed to Flashduty through the DingTalk Bot Compatible integration are set to Warning severity. However, you can customize the severity using the [alert pipeline](/en/on-call/integration/alert-integration/alert-pipelines). ## Alibaba Cloud Message Center ----
The "Robot Reception" feature in Alibaba Cloud's account Message Center can push account, product, and security notices to a custom webhook. Its data format can reuse the Dingtalk robot protocol, so it connects directly to the DingTalk Bot Compatible integration on this page. diff --git a/en/on-call/integration/alert-integration/alert-sources/dkron.mdx b/en/on-call/integration/alert-integration/alert-sources/dkron.mdx index 961edcdb..6fac60c5 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dkron.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dkron.mdx @@ -9,7 +9,6 @@ Dkron can send a webhook notification after every job execution. Point it at a F
## In Flashduty On-call ---- You can get the Push URL in either of two ways. @@ -30,7 +29,6 @@ You can get the Push URL in either of two ways.
## Configure Dkron ---- Dkron has no fixed webhook body. It renders the Go template you set in `webhook-payload` and posts the result. Flashduty parses only the fields the template below produces, so use it as is. The webhook is a server-wide Dkron setting that applies to every job. It is sent once per finished job execution (after retries are used up), by the leader node, for both successes and failures. @@ -70,12 +68,10 @@ Create a job that fails, for example with the command `false`, and run it manual ## Alert Key ---- Flashduty uses the job name, `job_name` (Dkron's `JobName`), as the Alert Key. The job name identifies a job in Dkron, and every execution result of that job, success or failure, carries the same name, so a failure and the success after it land on the same alert. Changes to the node, the start and end times, or the outcome do not change the Alert Key. ## Status and severity ---- | Dkron execution result | Flashduty status or severity | | :--- | :--- | @@ -85,7 +81,6 @@ Flashduty uses the job name, `job_name` (Dkron's `JobName`), as the Alert Key. T Dkron has no severity, so every failed job is Critical. A request whose `success` is empty or is neither `true` nor `false` is rejected, so a request with an unknown state never lands in the wrong alert lifecycle. ## Alert labels ---- | Label | Source | | :--- | :--- | @@ -95,7 +90,6 @@ Dkron has no severity, so every failed job is Critical. A request whose `success | `started_at`, `finished_at` | Start and end time of the execution | ## Troubleshooting ---- - **Flashduty receives nothing**: Dkron only logs webhook send errors and does not retry. Confirm the server can reach `api.flashcat.cloud` and that the Push URL is complete and includes `integration_key` - **Dkron logs `notifier: error parsing template`**: the `webhook-payload` template has a syntax error. Compare the quotes and braces with the template above diff --git a/en/on-call/integration/alert-integration/alert-sources/dolphinscheduler.mdx b/en/on-call/integration/alert-integration/alert-sources/dolphinscheduler.mdx index 87725bec..e04f5b8a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dolphinscheduler.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dolphinscheduler.mdx @@ -11,7 +11,6 @@ This integration was verified against DolphinScheduler 3.4.3. You must fill in *
## In Flashduty On-call ---- You can get the integration push URL in either of two ways. Pick one. @@ -32,7 +31,6 @@ You can get the integration push URL in either of two ways. Pick one.
## In DolphinScheduler ---- @@ -82,7 +80,6 @@ In **Alarm Instance Manage**, open the alarm instance for editing, click **Test ## Recovery and auto-close ---- DolphinScheduler sends a notification according to the state the workflow instance ends in: @@ -99,7 +96,6 @@ Workflow and task timeout alerts are sent once and never recover. If nobody re-r Sub-workflow states are not notified on their own. ## Alert types ---- The `content` array of one request can hold several alert objects. Each object becomes one Flashduty alert. @@ -111,7 +107,6 @@ The `content` array of one request can hold several alert objects. Each object b If the alarm group also receives alerts that carry no workflow information (for example a service-down alert), Flashduty rejects them with an invalid-parameter error. To keep failed sends out of DolphinScheduler, create a separate alarm group for this integration. ## Alert Key ---- | Alert type | Alert Key | | :--- | :--- | @@ -122,7 +117,6 @@ If the alarm group also receives alerts that carry no workflow information (for Changes to the workflow instance name, state, run count, or times do not change the Alert Key. A failure and the later success of the same instance share one Alert Key, so the success recovers the failure. An alert object without `projectCode` or `workflowInstanceId` makes the whole request be rejected. ## Status and severity ---- | Source | Status | Severity | | :--- | :--- | :--- | @@ -131,7 +125,6 @@ Changes to the workflow instance name, state, run count, or times do not change | Timeout | Triggered | Warning | ## Labels ---- | Label | Source | | :--- | :--- | @@ -149,7 +142,6 @@ Changes to the workflow instance name, state, run count, or times do not change | `task_code` / `task_name` | Task code and name (task timeout) | ## Troubleshooting ---- - **Flashduty receives no events**: confirm the workflow was started with an alarm group and a notification strategy other than **None**, that the alarm group contains the alarm instance, and that the push URL is complete and includes `integration_key`. **Test Send** in the alarm instance's create or edit dialog checks the network path - **Flashduty returns an invalid-parameter error**: usually **Body** is not `{"content":"${msg}"}`, or an alert without workflow information (for example service-down) was received diff --git a/en/on-call/integration/alert-integration/alert-sources/domotz.mdx b/en/on-call/integration/alert-integration/alert-sources/domotz.mdx index 559b2007..200acddd 100644 --- a/en/on-call/integration/alert-integration/alert-sources/domotz.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/domotz.mdx @@ -11,7 +11,6 @@ Alert profiles bound through the Domotz Public API deliver named events instead
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure in Domotz ---- You need permission in the Domotz portal to create contact channels and Alert Rules. @@ -71,12 +69,10 @@ Heartbeat lost, SNMP, IP change, configuration change, security issue, and WAN/L ## Alert Key ---- For an Alert Rule notification (`monitoring_profile_state_changed`), Flashduty builds the Alert Key from the event name and `alert_id`. The Problem and the Resolved notification of one occurrence carry the same `alert_id`, so the alert closes when the state becomes Resolved. The next occurrence gets a new `alert_id` and opens a new alert. A notification without `alert_id`, or with a state other than Problem or Resolved, is rejected. ## State and severity ---- | Alert Rule severity | Flashduty severity | | :--- | :--- | @@ -87,7 +83,6 @@ For an Alert Rule notification (`monitoring_profile_state_changed`), Flashduty b `data.state.current` decides the state: `Problem` triggers the alert and `Resolved` recovers it. ## Events from Public API alert profiles ---- Alert profiles bound through the alert-profile endpoints of the Domotz Public API deliver the events below. Flashduty builds the Alert Key from the event name, `agent_id` (collector ID), and `device_id` (device ID), plus the port for TCP services. The fields are joined with a non-printing separator and hashed with MD5. These identifiers come from the webhook event schemas in the Domotz Public API definition. Changes to device name, state value, or time do not change the Alert Key. @@ -110,7 +105,6 @@ Alert profiles bound through the alert-profile endpoints of the Domotz Public AP One `device_tcp` notification can list several ports. Flashduty creates one event per port, in ascending port order, and processes at most 50. Device discovery, feature discovery, and MIB discovery are accepted but create no alert. A state value outside the table returns a parameter error. ## Labels ---- | Label | Source | | :--- | :--- | @@ -125,7 +119,6 @@ One `device_tcp` notification can list several ports. Flashduty creates one even | `trigger_name` | SNMP trigger name | ## Troubleshooting ---- - **No alerts arrive**: confirm the Alert Rule is applied to a device or collector (**Applied To** is not `-`) and lists this webhook channel under **Notification Channels** - **An alert does not recover**: only the events with a recovery condition in the table recover on their own; rely on auto-close for the rest diff --git a/en/on-call/integration/alert-integration/alert-sources/dotcom-monitor.mdx b/en/on-call/integration/alert-integration/alert-sources/dotcom-monitor.mdx index 42adcf29..20324915 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dotcom-monitor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dotcom-monitor.mdx @@ -9,7 +9,6 @@ Dotcom-Monitor is a cloud service for website, API and server monitoring. Its **
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Dotcom-Monitor ---- @@ -76,7 +74,6 @@ Make a monitoring device fail (for example, point its target at a page that does ## Alert Key ---- Flashduty computes the Alert Key from the device name (`device_name`). Both the alert and the recovery notification of Dotcom-Monitor refer to the same monitoring device, so they land on the same Flashduty alert. @@ -87,7 +84,6 @@ Flashduty computes the Alert Key from the device name (`device_name`). Both the Requests without `device_name` are rejected. ## Alert lifecycle ---- Flashduty handles messages by the `notification_type` field, case-insensitively: @@ -99,12 +95,10 @@ Flashduty handles messages by the `notification_type` field, case-insensitively: Any other value, including `TEST`, is rejected with a parameter error. Dotcom-Monitor's variables reference lists a `TEST` type but does not say whether the test send uses it, so Flashduty has no separate handling for it; verify with a real device state change. Repeated notifications received while the device stays in error merge into the same alert. ## Severity ---- Dotcom-Monitor messages carry no severity field. A device error means the monitored target is unavailable, so it is fixed at **Critical**. A recovery event keeps the severity of the original alert. ## Alert content ---- - **Title**: the device name - **Description**: error type, error code, error reason and the failing target URL @@ -113,7 +107,6 @@ Dotcom-Monitor messages carry no severity field. A device error means the monito Dotcom-Monitor HTML-encodes the text it substitutes into the template; Flashduty decodes it before use. ## Troubleshooting ---- - **A test notification returns a parameter error**: a request whose `notification_type` is `TEST` is not accepted and creates no alert. This does not mean the setup is wrong; verify with a real device state change - **Request rejected with a missing `device_name` or an unsupported `notification_type`**: check that the field names in the alert template match the template above and that Data Type is Raw JSON diff --git a/en/on-call/integration/alert-integration/alert-sources/duplicati.mdx b/en/on-call/integration/alert-integration/alert-sources/duplicati.mdx index 6d3b0846..2893ef73 100644 --- a/en/on-call/integration/alert-integration/alert-sources/duplicati.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/duplicati.mdx @@ -9,7 +9,6 @@ After every backup run, Duplicati can send a JSON report to a URL you choose. Se
## In Flashduty On-call ---- You can get the integration Push URL in either of the following two ways. @@ -30,7 +29,6 @@ You can get the integration Push URL in either of the following two ways.
## Configure Duplicati ---- The `--send-http-json-urls` option is available in Duplicati 2.0.9.106 and later. This integration was verified with 2.4.0.0. @@ -66,7 +64,6 @@ Duplicati has no "send test notification" button, so verification needs real bac ## Alert Key ---- Flashduty builds the Alert Key from `Extra.machine-id` and `Extra.backup-id` in the Duplicati report. The Duplicati documentation defines `%machine-id%` as the unique random identifier assigned to the machine and `%backup-id%` as the identifier assigned to the backup. We verified on a real Duplicati 2.4.0.0 that both fields stay the same when one backup job fails and then succeeds. @@ -78,7 +75,6 @@ Flashduty builds the Alert Key from `Extra.machine-id` and `Extra.backup-id` in If you delete a job and create it again, it gets a new `backup-id`; close any open alert of the old job manually. ## Status and severity ---- | Duplicati `Data.ParsedResult` | Flashduty status or severity | | :--- | :--- | @@ -90,7 +86,6 @@ If you delete a job and create it again, it gets a new `backup-id`; close any op An empty or any other value, including `Unknown`, is rejected. Duplicati only sends a report when a backup runs: if a job is disabled or stops running, its open alert does not recover and must be closed manually. ## Troubleshooting ---- - **Flashduty receives no events**: confirm the option is `send-http-json-urls` and the Push URL is complete with `integration_key` - **Flashduty returns a parameter error**: confirm you did not use `--send-http-url` or the form format; the report must be JSON and contain `Extra.backup-id` diff --git a/en/on-call/integration/alert-integration/alert-sources/dynatrace.mdx b/en/on-call/integration/alert-integration/alert-sources/dynatrace.mdx index 10a12b8f..3c98fb3d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/dynatrace.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/dynatrace.mdx @@ -8,7 +8,6 @@ Sync Dynatrace alert events to Flashduty via webhook to achieve automated alert
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Dynatrace ----
@@ -91,7 +89,6 @@ Choose this option when you need to route alerts to different channels based on ## II. Status Mapping - |Dynatrace|Flashduty|Status| |---|---|---| |AVAILABILITY|Critical|critical| diff --git a/en/on-call/integration/alert-integration/alert-sources/ecloud-cm.mdx b/en/on-call/integration/alert-integration/alert-sources/ecloud-cm.mdx index cd685fda..01b8cba5 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ecloud-cm.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ecloud-cm.mdx @@ -9,7 +9,6 @@ Push China Mobile Cloud (ecloud) Cloud Monitor alerts to Flashduty On-call throu
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## In China Mobile Cloud ---- @@ -62,7 +60,6 @@ When an alarm rule in the policy triggers or recovers, China Mobile Cloud pushes ## Alert Key ---- Every push from China Mobile Cloud carries an alarm ID (`alarmId`). According to China Mobile Cloud, `alarmId` stays the same for alarms that the same rule keeps raising on the same resource. Flashduty computes the Alert Key from `alarmId`, so: @@ -73,7 +70,6 @@ Every push from China Mobile Cloud carries an alarm ID (`alarmId`). According to Requests without `alarmId` are rejected. ## Status and severity ---- The alert recovers when `recover` is `true`. Any other value is treated as a trigger. The severity comes from the alarm level (`alarmLevel`): @@ -88,7 +84,6 @@ The alert recovers when `recover` is `true`. Any other value is treated as a tri A recovered alert keeps the severity it had before recovery. ## Alert content and labels ---- The alert title combines the resource name (`resourceName`) and the metric name (`metricName`), for example `ECS-45273803 CPU利用率`. The alert description is the alarm content (`content`) pushed by China Mobile Cloud, which includes the trigger value and trigger time. @@ -111,7 +106,6 @@ The alert title combines the resource name (`resourceName`) and the metric name | `notify_time` | Time of this alarm notification (`notifyTime`) | ## Troubleshooting ---- - **Flashduty receives no alerts**: Confirm that the alarm policy notifies the alarm contact that has the webhook address, and that the address is complete and includes `integration_key` - **Flashduty returns a parameter error**: Confirm that the pushed content includes `alarmId` diff --git a/en/on-call/integration/alert-integration/alert-sources/edge-delta.mdx b/en/on-call/integration/alert-integration/alert-sources/edge-delta.mdx index 19eecd38..5bfce754 100644 --- a/en/on-call/integration/alert-integration/alert-sources/edge-delta.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/edge-delta.mdx @@ -9,7 +9,6 @@ An Edge Delta webhook integration has no fixed request body: you write the paylo
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Edge Delta ---- @@ -90,7 +88,6 @@ Click **Test Notifications** in the monitor's notification section to send a tes ## Payload ---- | Field | Meaning | In Flashduty | | :--- | :--- | :--- | @@ -104,7 +101,6 @@ Click **Test Notifications** in the monitor's notification section to send a tes | `time` | `$EVENT_DATE`, the event time | Added to the description | ## Alert Key ---- Flashduty builds the Alert Key from `monitor` and `group`. The alert, warning and recovery requests of one monitor (and one group) carry the same `monitor` and `group`, so they land on the same alert; different groups stay separate. A monitor without group by sends `*` as `group`, so the whole monitor maps to one alert; a monitor with group by sends `:` (for example `ed.tag:docker-logs`). `value`, `metric` and the time are not part of the Alert Key. @@ -113,7 +109,6 @@ The Edge Delta documentation does not provide a stable ID for monitor events, so ## Status and severity ---- | `status` | Flashduty status or severity | | :--- | :--- | @@ -124,7 +119,6 @@ The Edge Delta documentation does not provide a stable ID for monitor events, so If `monitor` or `status` is missing, or `status` is not one of the values above, Flashduty returns a parameter error. ## FAQ ---- @@ -141,7 +135,6 @@ If the monitor has a renotification period, Edge Delta sends the alert request a ## Troubleshooting ---- - **The monitor shows `Receiver webhook-flashduty-warning does not exist`**: every `@webhook-...` handle in the notification must match an existing integration; create it or remove its block - **Edge Delta does not push**: confirm the monitor's Notifications reference `@webhook-` inside the matching `{{#is_alert}}` or similar block diff --git a/en/on-call/integration/alert-integration/alert-sources/elastalert2.mdx b/en/on-call/integration/alert-integration/alert-sources/elastalert2.mdx index f6022bbf..e259c333 100644 --- a/en/on-call/integration/alert-integration/alert-sources/elastalert2.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/elastalert2.mdx @@ -8,7 +8,6 @@ Push ElastAlert2 alerts to Flashduty via webhook, to achieve automatic alert noi
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Dedicated Integration @@ -44,7 +43,6 @@ Choose this method when you need to route alerts to different channels based on ## In ElastAlert 2 ---- ### Configure ElastAlert 2 Alerts Follow the [ElastAlert Flashduty](https://elastalert2.readthedocs.io/en/latest/alerts.html#flashduty) push configuration document diff --git a/en/on-call/integration/alert-integration/alert-sources/elastic.mdx b/en/on-call/integration/alert-integration/alert-sources/elastic.mdx index e3ab785b..118c22df 100644 --- a/en/on-call/integration/alert-integration/alert-sources/elastic.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/elastic.mdx @@ -11,7 +11,6 @@ This integration works with Elastic Cloud, Elastic Cloud Serverless, and self-ma
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -48,14 +47,12 @@ Choose this method when you need to route alerts to different channels based on
## Prerequisites ---- - **Subscription**: the Kibana Webhook and PagerDuty connectors require an Elastic Gold subscription or higher (Basic does not include them); a 30-day trial license also works. See [Elastic subscriptions](https://www.elastic.co/subscriptions). - **Network**: Kibana must be able to reach the Flashduty push URL. If your self-managed Kibana sets [`xpack.actions.allowedHosts`](https://www.elastic.co/docs/reference/kibana/configuration-reference/alerting-settings#action-settings) in `kibana.yml`, add the push URL's host name (for example `api.flashcat.cloud`) to that list, otherwise the connector refuses to send. - **Permissions**: you need Kibana privileges to create connectors and edit rules. See [Alerting security](https://www.elastic.co/docs/explore-analyze/alerting/alerts/alerting-setup#alerting-security). ## In Kibana ---- @@ -99,7 +96,6 @@ Let the rule actually match its condition and confirm that Flashduty receives an ## Action template ---- Paste the following JSON into the **Body** of every action: @@ -147,7 +143,6 @@ To turn fields from the rule context into Flashduty labels (for routing or noise Custom and built-in labels together are limited to 50. Keys may contain only letters, digits, and underscores and must not start with a digit. A built-in label overrides a custom label with the same key. ## Alert Key ---- Flashduty builds the Alert Key from `rule_id` and `alert_id`. @@ -160,7 +155,6 @@ Flashduty builds the Alert Key from `rule_id` and `alert_id`. Changes to the rule name, tags, severity, description, or action group do not change the Alert Key. For example, when a Metric threshold rule's group moves from `Warning` to `Alert`, both notifications carry the same Alert Key. ## Status and severity ---- | Condition | Flashduty status or severity | | :--- | :--- | @@ -175,7 +169,6 @@ Changes to the rule name, tags, severity, description, or action group do not ch Security detection rules do not send Recovered notifications. Each detection alert becomes a separate Flashduty alert that you close manually or through auto-close in Flashduty. ## Use the PagerDuty connector (optional) ---- If your rules already use the Kibana PagerDuty connector, you can point it at the Flashduty [PagerDuty Compatible integration](/en/on-call/integration/alert-integration/alert-sources/pagerduty) without rewriting the actions. Alerts sent this way arrive through Flashduty's PagerDuty Compatible integration, not the Elastic integration on this page. @@ -185,7 +178,6 @@ If your rules already use the Kibana PagerDuty connector, you can point it at th 4. Keep the **DedupKey** that Kibana pre-fills, `{{rule.id}}:{{alert.id}}`, on both actions and do not clear it, so the resolve event closes the matching alert. With an empty DedupKey on the Trigger action, Kibana sends no `dedup_key`, Flashduty generates a random Alert Key for each trigger, and the resolve event cannot close it ## Troubleshooting ---- - **Kibana reports `target url "..." is not added to the Kibana config xpack.actions.allowedHosts`**: add the Flashduty push URL's host name to `xpack.actions.allowedHosts` - **Flashduty returns an error starting with `alert_id is required`**: the action's **Action frequency** is Summary of alerts; change it to For each alert diff --git a/en/on-call/integration/alert-integration/alert-sources/email.mdx b/en/on-call/integration/alert-integration/alert-sources/email.mdx index d43d7090..ee49c180 100644 --- a/en/on-call/integration/alert-integration/alert-sources/email.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/email.mdx @@ -8,7 +8,6 @@ Generate a unique email address in Flashduty to synchronize alert triggers and r
## Steps ---- ### Create Email Integration @@ -104,6 +103,5 @@ attachment_stripped = true ## Severity Mapping ---- Currently, all alerts pushed to Flashduty through the email integration are set to Warning severity. However, you can customize the severity using the [alert pipeline](/en/on-call/integration/alert-integration/alert-pipelines). diff --git a/en/on-call/integration/alert-integration/alert-sources/emqx.mdx b/en/on-call/integration/alert-integration/alert-sources/emqx.mdx index da7c71ee..2f87480f 100644 --- a/en/on-call/integration/alert-integration/alert-sources/emqx.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/emqx.mdx @@ -7,7 +7,6 @@ keywords: ["alert integration", "EMQX", "MQTT", "monitoring alert", "data ingest
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In EMQX ---- EMQX Cloud (hosted service) and self-hosted EMQX are integrated differently. Choose the steps that match your deployment. @@ -130,7 +128,6 @@ Use the same request body template as Step 1, but set `event_status` to `Ok`, so
## Severity Mapping ----
@@ -147,7 +144,6 @@ Use the same request body template as Step 1, but set `event_status` to `Ok`, so
## FAQ ----
Why am I not receiving alerts in Flashduty? diff --git a/en/on-call/integration/alert-integration/alert-sources/extrahop.mdx b/en/on-call/integration/alert-integration/alert-sources/extrahop.mdx index 7f5ae28f..adf27744 100644 --- a/en/on-call/integration/alert-integration/alert-sources/extrahop.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/extrahop.mdx @@ -11,7 +11,6 @@ ExtraHop's documentation does not describe a notification when a detection is cl
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure ExtraHop ---- You need NDR or NPM module access with full write privileges or higher. Webhooks are sent over TCP 443 (HTTPS), so ExtraHop must be able to reach the Flashduty push URL. @@ -80,19 +78,16 @@ If you select **Send once per detection**, ExtraHop requires a custom payload. A ## Alert Key ---- Flashduty uses `id` (ExtraHop defines it as "The unique identifier for the detection") as the Alert Key. Every update of one detection carries the same `id` and merges into one alert. Changes to the title, description, risk score, and time do not change the Alert Key. Requests without `id` are rejected. ## Detections and recovery ---- ExtraHop detection notifications cover creation and updates only. The documentation does not describe a notification when a detection is closed or resolved. Every notification Flashduty receives is a trigger, and none recovers an alert automatically. Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit), 24 hours recommended, or close the alert by hand once the detection is handled. ## Severity ---- Severity comes from `risk_score`, using the same bands as the ExtraHop console colors: @@ -104,7 +99,6 @@ Severity comes from `risk_score`, using the same bands as the ExtraHop console c | Missing, 0, or non-numeric (performance detections have no risk score) | Warning | ## Labels ---- | Label | Source | | :--- | :--- | @@ -122,7 +116,6 @@ Severity comes from `risk_score`, using the same bands as the ExtraHop console c The alert title is `title`, falling back to `type` and then `ExtraHop detection `. The description is the detection description followed by the link to the detection. ## Troubleshooting ---- - **Flashduty returns a parameter error**: check that the URL is complete and includes `integration_key`, and that the payload contains `id` - **Alerts never close**: ExtraHop sends no recovery notification. Turn on the channel's auto-resolve timeout or close alerts by hand diff --git a/en/on-call/integration/alert-integration/alert-sources/fail2ban.mdx b/en/on-call/integration/alert-integration/alert-sources/fail2ban.mdx index f5509fe9..67dbb339 100644 --- a/en/on-call/integration/alert-integration/alert-sources/fail2ban.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/fail2ban.mdx @@ -9,7 +9,6 @@ Fail2ban has no built-in webhook notification, but an action is just a shell com
## In Flashduty On-call ---- You can get the push URL in either of the two ways below. **In both cases choose Standard Alert Event as the integration type**, not Fail2ban. @@ -30,7 +29,6 @@ You can get the push URL in either of the two ways below. **In both cases choose
## Configure in Fail2ban ---- Run these steps on the host where Fail2ban runs, as root. @@ -91,7 +89,6 @@ fail2ban-client set sshd unbanip 192.0.2.10 ## Field mapping ---- | Fail2ban | Flashduty | | :--- | :--- | @@ -103,7 +100,6 @@ fail2ban-client set sshd unbanip 192.0.2.10 | `labels` | Labels `jail`, `ip`, `failures`, `bantime` | ## Recovery and deduplication ---- - Fail2ban runs `actionunban` when the ban time expires, and Flashduty closes the alert with the same `alert_key`. - With a permanent ban (`bantime = -1`) the IP is never unbanned, so the alert does not close by itself. Enable [auto-resolve timeout](/en/on-call/channel/create-edit) on the channel that receives this integration, or close the alert manually once handled. @@ -111,7 +107,6 @@ fail2ban-client set sshd unbanip 192.0.2.10 - `norestored = 1` stops Fail2ban from notifying for bans restored from its database after a restart, which would otherwise produce a burst of duplicate alerts. ## Troubleshooting ---- - **Flashduty receives nothing**: confirm `fail2ban-client reload` was run; call the push URL with `curl` from the same host to check the response and that api.flashcat.cloud is reachable - **`InvalidParameter` is returned**: the push URL is missing `integration_key`, or the JSON was broken by quoting; make sure there are no stray line breaks in `[Definition]` diff --git a/en/on-call/integration/alert-integration/alert-sources/falco.mdx b/en/on-call/integration/alert-integration/alert-sources/falco.mdx index 4f5fc676..5b0962c2 100644 --- a/en/on-call/integration/alert-integration/alert-sources/falco.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/falco.mdx @@ -9,7 +9,6 @@ Use the Falcosidekick webhook output (or Falco's built-in `http_output`) to send
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Falco ---- Pushing through Falcosidekick is recommended because `minimumpriority` filters low-priority events at the source. Without Falcosidekick, Falco can push directly. @@ -78,7 +76,6 @@ The push URL contains `integration_key`. Paste it in full, including the paramet ## Verify ---- Send a request to the Falcosidekick `/test` endpoint (it listens on port 2801 by default): @@ -91,7 +88,6 @@ Flashduty opens a new alert titled `Test rule` with Info severity. The test aler Then trigger a real rule on a monitored host or container (for example, open an interactive shell in a container to fire `Terminal shell in container`) and confirm the alert appears in Flashduty. ## Alert Key ---- Each Falco event is an independent detection with no lifecycle, so each event becomes its own alert: @@ -101,7 +97,6 @@ Each Falco event is an independent detection with no lifecycle, so each event be A request without `rule` is rejected, because Flashduty cannot tell which rule fired. ## Severity ---- | Falco `priority` | Flashduty severity | | :--- | :--- | @@ -111,17 +106,14 @@ A request without `rule` is rejected, because Flashduty cannot tell which rule f | Empty or unknown | Warning | ## Labels ---- The title is the rule name (`rule`) and the description is `output`. These fields become labels: `rule`, `priority`, `hostname` (also used as `resource`), `falco_source`, `falco_uuid`, and `tags` (comma-separated). Every field in `output_fields` also becomes a label, with `.` in the key replaced by `_`, for example `container.id` becomes `container_id` and `k8s.pod.name` becomes `k8s_pod_name`. At most 50 labels are kept. ## Recovery ---- Falco sends no recovery event, so alerts do not resolve on their own. Turn on the [auto-resolve timeout](/en/on-call/channel/create-edit) for the channel that receives Falco alerts (24 hours suggested; adjust it to how quickly you need to respond), or close alerts by hand after handling them. ## Troubleshooting ---- - **Falcosidekick logs a webhook error**: check that the address is complete, includes `integration_key`, and that `api.flashcat.cloud` is reachable from where Falcosidekick runs - **Flashduty returns a parameter error**: make sure Falco has `json_output: true` and the body is valid JSON containing `rule` diff --git a/en/on-call/integration/alert-integration/alert-sources/fastnetmon.mdx b/en/on-call/integration/alert-integration/alert-sources/fastnetmon.mdx index d15df6d7..0dc23692 100644 --- a/en/on-call/integration/alert-integration/alert-sources/fastnetmon.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/fastnetmon.mdx @@ -9,7 +9,6 @@ Use the FastNetMon Advanced web callback to send DDoS ban (`ban`, `partial_block
## In Flashduty On-call ---- You can get the push URL in either of two ways. @@ -30,7 +29,6 @@ You can get the push URL in either of two ways.
## In FastNetMon ---- @@ -69,7 +67,6 @@ Trigger an attack detection (for example, send test traffic above the ban thresh ## Payload ---- | Field | Meaning | In Flashduty | | :--- | :--- | :--- | @@ -85,7 +82,6 @@ Trigger an attack detection (for example, send test traffic above the ban thresh Packet samples (`packet_dump`) and Flow Spec rules in ban notifications are not stored on the alert. ## Alert Key ---- The Alert Key identifies the attacked object: `ip` for host scope, `hostgroup_name` for host group scope. The ban, status updates and unban for one IP land on the same alert; different IPs or host groups are different alerts. Changes to severity, traffic data or `attack_uuid` do not change the Alert Key. @@ -96,7 +92,6 @@ If a blackhole ban and a Flow Spec partial block are active on the same IP, they A request without `ip` (or without `hostgroup_name` in host group scope) is rejected with a parameter error, because the unban could not be matched to its alert reliably. A request with any other `action` or `alert_scope` is rejected too. ## Status and severity ---- | FastNetMon `attack_severity` | Flashduty severity | | :--- | :--- | @@ -108,7 +103,6 @@ A request without `ip` (or without `hostgroup_name` in host group scope) is reje The official samples only show `middle`; the other values follow common naming. On unban the alert recovers and keeps the severity of the last attack notification. ## FAQ ---- @@ -131,7 +125,6 @@ This integration targets the JSON format that FastNetMon Advanced uses for web c ## Troubleshooting ---- - **No alerts arrive**: on the FastNetMon server, confirm `web_callback_enabled` is on, `fcli commit` was run, and the server can reach the Flashduty push URL - **Flashduty returns a parameter error**: confirm the request is a FastNetMon JSON notification and that `ip` (host scope) or `hostgroup_name` (host group scope) is not empty diff --git a/en/on-call/integration/alert-integration/alert-sources/firebase-crashlytics.mdx b/en/on-call/integration/alert-integration/alert-sources/firebase-crashlytics.mdx index c8bd1b36..4be7d4df 100644 --- a/en/on-call/integration/alert-integration/alert-sources/firebase-crashlytics.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/firebase-crashlytics.mdx @@ -19,7 +19,6 @@ Firebase also sends a **stability digest** (`onStabilityDigestPublished`), a dai
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -40,7 +39,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Firebase ---- Crashlytics alert functions run on Cloud Functions (2nd gen). The Firebase project must be on the **Blaze (pay as you go)** plan to deploy them, even if actual usage stays inside the free tier — a billing account still has to be attached. @@ -155,7 +153,6 @@ Crashlytics sends no "resolved" notification for any of these events, so alerts ## Alert Key ---- Flashduty computes the Alert Key from the event type `alert_type`, the app ID `app_id`, and Crashlytics' issue ID `issue_id` (the official `Issue.id`). One Cloud Function deployment (one push URL) can forward events for every app in the project (see "Scope to one app" above), and Firebase does not document `issue_id` as unique across apps, so `app_id` is folded in too — this keeps two apps from merging into one alert if they happen to get the same issue ID. As a result: @@ -167,7 +164,6 @@ Flashduty computes the Alert Key from the event type `alert_type`, the app ID `a If a request is missing `issue_id`, Flashduty rejects it. ## Severity ---- Crashlytics alert events carry no severity. Flashduty sets it by event type: @@ -182,7 +178,6 @@ Crashlytics alert events carry no severity. Flashduty sets it by event type: To override this with a fixed severity, append `&severity=Critical` (or `Warning`, `Info`) to the push URL. ## Alert content ---- The alert title is `Firebase Crashlytics : `, for example `Firebase Crashlytics new fatal issue: java.lang.NullPointerException`. The description includes the issue subtitle (the class and method where the crash happened) and the app version; a regression alert also includes the time the issue was previously marked resolved, and a velocity alert also includes the crash session count, crash percentage, and the version where the issue first appeared. @@ -198,7 +193,6 @@ The alert title is `Firebase Crashlytics : `, for examp | `crash_count` / `crash_percentage` / `first_version` | Velocity alerts only: crash session count, crash percentage, and the version where the issue first appeared | ## Troubleshooting ---- - **Function deployment fails or reports a permission error**: Make sure the Firebase project is on the Blaze plan and the account deploying it has permission to deploy Cloud Functions on that project - **A crash happened but no alert arrives**: Crashlytics can take a few minutes to process a crash log and trigger the alert function; check `firebase functions:log` to see whether the function ran and whether `fetch` threw an error diff --git a/en/on-call/integration/alert-integration/alert-sources/firefly.mdx b/en/on-call/integration/alert-integration/alert-sources/firefly.mdx index 612a9dab..59a0e46d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/firefly.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/firefly.mdx @@ -9,7 +9,6 @@ Use Firefly's Webhook notification integration to send the events Firefly detect
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Firefly ---- @@ -77,7 +75,6 @@ Firefly does not document the content of the test notification. If it carries no ## Alert Key ---- Each resource (one entry in `samples`) produces one alert. The Alert Key is computed from the event type `notificationType` and the resource's `FRN`; when `FRN` is empty, the resource's `ARN` is used instead. As a result: @@ -88,7 +85,6 @@ Each resource (one entry in `samples`) produces one alert. The Alert Key is comp If a resource has neither `FRN` nor `ARN`, Flashduty rejects the whole delivery. ## Status and severity ---- Firefly's Webhook notifications carry no severity. Flashduty sets the severity by event type, and every event is a trigger: @@ -98,7 +94,6 @@ Firefly's Webhook notifications carry no severity. Flashduty sets the severity b | `UnmanagedResource` | Info | ## Title, description, and labels ---- The alert title is `Firefly : ()`, for example `Firefly drift detected: web-1 (aws_instance)`. The description of a `Drift` alert lists each drifted attribute on its own line with its IaC value and its live cloud value. @@ -119,7 +114,6 @@ The alert title is `Firefly : ()`, fo The actor information in Firefly's delivery (`ownerData.userIdentity`) is not written to labels. ## Troubleshooting ---- - **Firefly reports an invalid webhook URL when creating the integration**: Make sure the URL is complete, includes `integration_key`, and **Add custom credentials** is unchecked - **Flashduty returns an invalid parameter error**: Make sure the `integration_key` in the push URL belongs to a Firefly integration diff --git a/en/on-call/integration/alert-integration/alert-sources/fivetran.mdx b/en/on-call/integration/alert-integration/alert-sources/fivetran.mdx index 59ff56c4..62859c33 100644 --- a/en/on-call/integration/alert-integration/alert-sources/fivetran.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/fivetran.mdx @@ -9,7 +9,6 @@ Use Fivetran webhooks to send sync results and connection test results of a conn
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## In Fivetran ---- Fivetran webhooks are created through the [Webhook REST API](https://fivetran.com/docs/developer-resources/webhooks), authenticated with a Fivetran API key and secret using Basic authentication. A webhook is either account-level (covers every connection in the account) or group-level (covers the connections in one group). @@ -82,14 +80,12 @@ Fivetran's **Test a Webhook** call (`POST /v1/webhooks/{webhookId}/test` with bo ## Alert Key ---- Flashduty uses the connection ID (`connector_id` in the webhook) plus the event family (sync or connection test) as the Alert Key. Fivetran documents `connector_id` as "the ID of the connection for which the webhooks are sent", and every sync and connection test of one connection carries the same value. Sync and connection test use separate Alert Keys, so a successful sync does not close a connection test alert that is still unresolved. Changes in the per-sync `sync_id`, the failure reason, or the time do not change the Alert Key. A sync or connection test event without `connector_id` is rejected. ## Status and severity ---- | Event | `data.status` | Status | Flashduty severity | | :--- | :--- | :--- | :--- | @@ -107,7 +103,6 @@ For an ignored delivery, Flashduty returns success without creating an alert or Each `sync_end` is an independent delivery with no progress updates: a triggered alert stays active until the next `SUCCESSFUL` sync of the same connection. If the connection is paused or deleted, the triggered alert does not recover on its own. Close it manually in Flashduty, or configure automatic closing after a timeout for the channel. ## Labels ---- | Label | Source | | :--- | :--- | @@ -125,7 +120,6 @@ Each `sync_end` is an independent delivery with no progress updates: a triggered The alert description comes from the failure reason (`data.reason`) or the connection test message (`data.message`). ## Troubleshooting ---- - **Fivetran returns 400 when creating the webhook**: make sure the URL is HTTPS and reachable by Fivetran. Fivetran sends a test request on both creation and activation, and it must return 2xx. Flashduty answers that test request with 200 and opens a separate Info alert as described above - **An alert does not recover**: make sure the webhook subscribes to `sync_end` and `connection_successful`. An expected reschedule and `CANCELED` do not produce a recovery diff --git a/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx b/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx index 152db1b5..7348570d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/flashcat.mdx @@ -12,7 +12,6 @@ In the Nightingale/Flashcat v8.0.0-beta.7+ version, you can configure the collab
## Prerequisites ---- ### In Nightingale @@ -20,12 +19,10 @@ In the Nightingale/Flashcat v8.0.0-beta.7+ version, you can configure the collab - Your Nightingale server must be able to access the domain api.flashcat.cloud to push alerts to the external network. ## Supported Versions ---- This guide is compatible with **Nightingale V5 and V6** versions. ## Setup Steps ---- ### In Flashduty @@ -161,8 +158,6 @@ Nightingale supports configuring global webhook URLs in both the interface and c ## Silence Detection ---- - In the integration card (edit and preview), the **Silence Detection** (Heartbeat) setting is available below the alert push settings: if no valid event arrives within the configured interval, the system generates a Warning alert. | Setting | Description | @@ -172,7 +167,6 @@ In the integration card (edit and preview), the **Silence Detection** (Heartbeat | **Auto-recover on new event** | Switch, on by default. When the next valid event arrives, the alert raised by silence detection is recovered automatically | ## Severity Mapping ---- Nightingale/Flashcat to Flashduty alert severity mapping: @@ -183,7 +177,6 @@ Nightingale/Flashcat to Flashduty alert severity mapping: | 3 | Info | Info | ## FAQ ----
Why am I not receiving alerts in Flashduty? diff --git a/en/on-call/integration/alert-integration/alert-sources/fleet.mdx b/en/on-call/integration/alert-integration/alert-sources/fleet.mdx index 0f060161..98566ad3 100644 --- a/en/on-call/integration/alert-integration/alert-sources/fleet.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/fleet.mdx @@ -14,7 +14,6 @@ Fleet sends these webhooks once, when the event happens, and never sends a recov
## In Flashduty On-call ---- Get the integration push URL in either of the following ways. @@ -35,7 +34,6 @@ Get the integration push URL in either of the following ways.
## In Fleet ---- Enable the webhooks under **Manage automations** in the Fleet admin UI, or set them through GitOps or the configuration file, as shown below. Use the full Flashduty push URL, including `integration_key`, as `destination_url` for both webhooks. @@ -87,7 +85,6 @@ Hosts run policies at the interval set by `FLEET_OSQUERY_POLICY_UPDATE_INTERVAL` ## Events and recovery ---- | Fleet delivery | Effect in Flashduty | | :--- | :--- | @@ -100,7 +97,6 @@ One delivery can carry many hosts. Flashduty handles them in host ID order and p Fleet does not notify Flashduty when a host is fixed. Turn on [auto-close](/en/on-call/channel/create-edit) for the integration's channel, with a suggested window of 24 hours to 7 days depending on how long you take to handle failing policies. When the same policy fails again on the same host (for example after the policy is reset in Fleet), it merges into the same alert. ## Alert Key ---- - Failing policy: computed from the policy ID (`policy.id`) and the host ID (`hosts[].id`) - Vulnerability: computed from the CVE ID and the host ID @@ -108,7 +104,6 @@ Fleet does not notify Flashduty when a host is fixed. Turn on [auto-close](/en/o Both IDs are Fleet database IDs and stay constant within one Fleet instance. Changes to the policy name, host name, or failing-host counts do not change the Alert Key. A delivery without the policy ID, CVE ID, or host ID is rejected, and the error names the missing field. ## Severity ---- | Source | Condition | Flashduty severity | | :--- | :--- | :--- | @@ -122,7 +117,6 @@ Both IDs are Fleet database IDs and stay constant within one Fleet instance. Cha The policy `critical` option requires a Fleet Premium license; free Fleet rejects it with `option critical requires a premium license`. On free Fleet, every policy alert therefore arrives as Warning. ## Labels ---- | Label | Source | | :--- | :--- | @@ -136,7 +130,6 @@ The policy `critical` option requires a Fleet Premium license; free Fleet reject The policy query, author details, and software installation paths in the payload are not stored as labels. ## Troubleshooting ---- - **Flashduty returns a parameter error**: the message names the missing field. If it says only failing policy and vulnerability webhooks are supported, check whether a host status or activity webhook points at this URL - **No alert arrives**: the policy webhook fires only when a policy changes from passing to failing; a host that keeps failing is not sent again. Hosts run policies every `FLEET_OSQUERY_POLICY_UPDATE_INTERVAL` (default 1 hour), and Fleet posts only after a result changes diff --git a/en/on-call/integration/alert-integration/alert-sources/flowmon-ads.mdx b/en/on-call/integration/alert-integration/alert-sources/flowmon-ads.mdx index 2a43d704..c2c61d86 100644 --- a/en/on-call/integration/alert-integration/alert-sources/flowmon-ads.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/flowmon-ads.mdx @@ -9,7 +9,6 @@ When Flowmon ADS (Anomaly Detection System) detects a network anomaly event, it
## In Flashduty On-call ---- Get the integration email address in either of the two ways below. **In both cases choose the Email integration type**, not Flowmon ADS. @@ -30,7 +29,6 @@ Get the integration email address in either of the two ways below. **In both cas
## Configure Flowmon ADS ---- 1. In Flowmon ADS, open **Email notifications** under **Event Response** and create an email report. Each email report is bound to exactly one perspective 2. Click **Add new email** and add the Flashduty email integration address as a recipient @@ -55,12 +53,10 @@ The body of a per-event email contains these fields: | `Ports involved` | Port numbers related to the event, may be empty | ## Push mode in Flashduty ---- Keep the email integration's default push mode, which creates a new alert for every email: the alert title is the email title and the description is the email body, which contains the fields above. Flowmon ADS sends one email per event and events don't need to be merged, so no rules are needed. ## Limitations ---- - **No recovery email**: Flowmon ADS events are one-time notifications and no recovery email is sent, so alerts do not close on their own. Turn on the [auto-resolve timeout](/en/on-call/channel/create-edit) in the channel that receives this integration; 24 hours is a reasonable start. - **Severity**: in Flashduty these alerts show the Email integration type, and their severity is always Warning; the event priority is in the `Severity` field of the body. You can adjust it with [alert pipelines](/en/on-call/integration/alert-integration/alert-pipelines). diff --git a/en/on-call/integration/alert-integration/alert-sources/flowtriq.mdx b/en/on-call/integration/alert-integration/alert-sources/flowtriq.mdx index c0721768..d0dcd37d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/flowtriq.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/flowtriq.mdx @@ -9,7 +9,6 @@ Use a Flowtriq Webhook alert channel to send DDoS attack events to Flashduty On-
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Flowtriq ---- @@ -58,7 +56,6 @@ Trigger attack detection on a monitored node. Confirm that Flashduty receives an Flowtriq retries a failed delivery up to 3 times (after 10 seconds, 60 seconds, and 5 minutes). Each request times out after 10 seconds, and a non-2xx status code counts as a failure. ## Events and recovery ---- Flowtriq posts to the webhook on every incident event. The event type is in `event_type`: @@ -72,12 +69,10 @@ Flowtriq posts to the webhook on every incident event. The event type is in `eve Other event types, including any Flowtriq adds later, create no alert; Flashduty returns success for them. ## Alert Key ---- Flashduty builds the Alert Key from the incident identity: `incident.uuid` when present, otherwise `incident.id`. Webhook deliveries currently carry the numeric `incident.id` and no `uuid`. The start and end events of one attack share one Alert Key, so the end event recovers the matching alert. An event with neither field is rejected. Changes to the title, severity, or peak traffic do not change the Alert Key. ## Severity mapping ---- | `incident.severity` | Flashduty severity | | :--- | :--- | @@ -89,7 +84,6 @@ Flashduty builds the Alert Key from the incident identity: `incident.uuid` when A recovery event keeps the last severity from the attack. ## Labels ---- | Label | Source | | :--- | :--- | @@ -105,7 +99,6 @@ A recovery event keeps the last severity from the attack. The alert description comes from Flowtriq's AI summary (`ai_summary`). The `attack_start` delivery carries no summary, so the description is empty at that point. ## Troubleshooting ---- - **Flowtriq shows a failed delivery**: confirm the URL is complete, includes `integration_key`, and uses HTTPS. Failed deliveries are listed in the notification log on the incident detail page in Flowtriq - **The alert did not recover**: confirm the Flowtriq channel sent an `attack_end` event. Recovery relies on the start and end events carrying the same `incident.id`; if an alert stays open for a long time, close it manually in Flashduty diff --git a/en/on-call/integration/alert-integration/alert-sources/fluxcd.mdx b/en/on-call/integration/alert-integration/alert-sources/fluxcd.mdx index 7b43ee5e..a6c1c239 100644 --- a/en/on-call/integration/alert-integration/alert-sources/fluxcd.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/fluxcd.mdx @@ -9,7 +9,6 @@ Flux's notification-controller pushes events out through two kinds of objects: a
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Flux ---- You need `kubectl` permissions to create a Secret and the Flux `Provider` and `Alert` objects in the cluster. The examples use the `notification.toolkit.fluxcd.io/v1beta3` API and the `flux-system` namespace; the Provider, Alert, and Secret must be in the same namespace. The cluster must be able to reach the domain of the Flashduty push URL. @@ -113,7 +111,6 @@ Flux has no button that sends a test message. Use a temporary Kustomization inst ## Alert Key ---- Flashduty uses `involvedObject.uid`, the Kubernetes UID of the Flux object, as the Alert Key. Flux's own `pagerduty` Provider uses the same UID as the deduplication key for both trigger and resolve. All failure events of one Flux object land on the same Flashduty alert; changes to the failure reason (`reason`), message, or revision do not change the Alert Key. @@ -123,7 +120,6 @@ Flashduty uses `involvedObject.uid`, the Kubernetes UID of the Flux object, as t Flashduty rejects a request without `involvedObject.uid`. ## Alert lifecycle ---- Flashduty handles each event by its `severity` and `reason` fields: @@ -140,12 +136,10 @@ By default, Flux pushes an event for the same object with the same `message` and **When only `error` events are forwarded**: if the Alert's `eventSeverity` is `error`, or its `exclusionList` filters out success events, Flashduty receives no recovery events and alerts never close on their own. In that case, turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) with **Incident trigger** as the timing start. A timeout of 12 hours is a reasonable default: if the object is still failing, the next failed reconciliation triggers the alert again. ## Severity ---- Flux failure events have a single level, `error`, so all alerts default to **Critical**. For a different severity, append `&severity=Warning` (or `Info`) to the push URL. A recovery event keeps the severity of the original alert. ## Alert content ---- - **Title**: ` /: `, for example `Kustomization apps/webapp: ValidationFailed` - **Description**: the event `message` @@ -154,7 +148,6 @@ Flux failure events have a single level, `error`, so all alerts default to **Cri In `metadata` key names, characters other than `a-z`, `A-Z`, `0-9`, and `_` are replaced with `_` (for example, `kustomize.toolkit.fluxcd.io/revision` sent by older Flux versions becomes `kustomize_toolkit_fluxcd_io_revision`). A key with the same name as a built-in label does not overwrite it. Empty values are not written as labels. ## Troubleshooting ---- - **No alerts arrive**: run `kubectl -n flux-system logs deploy/notification-controller` and look for errors such as `failed to dispatch notification`; run `kubectl -n flux-system get events --field-selector involvedObject.kind=Alert` to see warnings recorded on the Alert - **Alerts arrive for only some objects**: check that the object's `kind` is listed in `eventSources`, and that the object is in the Alert's namespace or the entry sets `namespace` diff --git a/en/on-call/integration/alert-integration/alert-sources/formant.mdx b/en/on-call/integration/alert-integration/alert-sources/formant.mdx index ccec7d5e..7f175be1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/formant.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/formant.mdx @@ -11,7 +11,6 @@ A Formant event is sent once and has no recovery notification, so the alert in F
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure Formant ---- @@ -61,19 +59,16 @@ Make a forwarded event trigger once (for example, take a device offline or push ## Recovery and auto-close ---- Formant events cannot be changed after they trigger, and the webhook is sent once per event. The request body has no field that marks an event as ended or recovered, so the alert in Flashduty does not recover on its own. Each Formant event is a separate Flashduty alert. Close it by hand, or turn on [auto-close](/en/on-call/channel/create-edit) in the channel that receives this integration. We suggest 2 hours; adjust to how quickly your team handles device problems. ## Alert Key ---- The Alert Key is the Formant event ID (`payload.id`). A repeated delivery of the same event merges into the same alert; different events, even from the same event trigger and device, are different alerts. If a request has no event ID, Flashduty generates a random Alert Key, and that alert is not merged either. ## Status and severity ---- The alert status equals its severity; it does not recover. @@ -86,7 +81,6 @@ The alert status equals its severity; it does not recover. | Missing or any other value | Warning | ## Alert content ---- - **Title**: the event `message`; if missing, `Formant event on `; if that is missing too, `Formant event` - **Description**: device ID, stream, datapoint value, event time and the event link in Formant @@ -103,7 +97,6 @@ The alert status equals its severity; it does not recover. | Device tags | Each key and value in the event `tags`; characters such as `.` and `-` in keys become `_`, and a tag never overrides the labels above | ## Troubleshooting ---- - **Flashduty receives nothing**: check that the event's **Actions** tab has the webhook selected under **Webhook forwarding**, and that the webhook URL is the full push URL including `integration_key` - **Flashduty returns a parameter error**: the body is not JSON or has no `payload` object. Use Formant's built-in webhook forwarding and do not rewrite the body diff --git a/en/on-call/integration/alert-integration/alert-sources/fortimonitor.mdx b/en/on-call/integration/alert-integration/alert-sources/fortimonitor.mdx index edabced4..86508d1d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/fortimonitor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/fortimonitor.mdx @@ -9,7 +9,6 @@ Use the FortiMonitor (formerly Panopta) webhook integration to send incident and
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure FortiMonitor ---- @@ -92,7 +90,6 @@ FortiMonitor sends webhook requests from fixed IP addresses: `104.197.35.194/32` ## Payload ---- FortiMonitor POSTs the following form fields, one request per incident and event: @@ -112,14 +109,12 @@ FortiMonitor POSTs the following form fields, one request per incident and event The alert title is `: `. If the instance name is empty, the FQDN is used; if both are empty, the title is `FortiMonitor incident `. ## Alert Key ---- Flashduty uses `outage_id` (the FortiMonitor incident ID) as the Alert Key. The incident, escalation, and clear notifications of one incident carry the same `outage_id`, so they land on the same alert. When the same metric on the same instance fails again after recovering, FortiMonitor opens a new incident ID and Flashduty opens a new alert. Changing the instance name, reason, or severity does not change the Alert Key. If a request has no `outage_id`, or still contains the unexpanded `$outage_id`, Flashduty returns a parameter error, because the clear notification could not be linked to the original alert. ## Status and severity ---- | FortiMonitor `trigger` | Flashduty behavior | | :--- | :--- | @@ -136,7 +131,6 @@ If a request has no `outage_id`, or still contains the unexpanded `$outage_id`, Requests with an empty or unknown `trigger` are rejected. ## FAQ ---- @@ -159,7 +153,6 @@ The Alert Timeline sends a notification only after the incident has lasted until ## Troubleshooting ---- - **Delivery fails**: make sure the Postback URL is the complete push URL and includes `integration_key`. If inbound traffic is restricted, allow the FortiMonitor webhook IP addresses - **Flashduty returns a parameter error**: make sure Payload Type is Form Variables, the variable names match the table above, and `trigger` and `outage_id` are set to `$trigger` and `$outage_id` diff --git a/en/on-call/integration/alert-integration/alert-sources/fortisiem.mdx b/en/on-call/integration/alert-integration/alert-sources/fortisiem.mdx index 0eae561c..8c7b3c0a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/fortisiem.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/fortisiem.mdx @@ -9,7 +9,6 @@ When a rule triggers an incident, FortiSIEM's Incident HTTP Notification POSTs a
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In FortiSIEM ---- @@ -56,14 +54,12 @@ Let a rule trigger a real incident and confirm Flashduty receives an active aler ## Alert Key ---- Flashduty uses the `incidentId` attribute of the `incident` element as the Alert Key. The FortiSIEM documentation defines it as "Unique ID of the incident in FortiSIEM", and describes `status` as "New, Update or Clear"; one `incidentId` is expected across the notifications of one incident. The XML schema comes from the FortiSIEM 6.7.0 Integration API guide; check the first real delivery on your 7.x version against the field list below. Changes to the rule name, severity, repeat count, time, or incident details do not change the Alert Key. Flashduty rejects a request without `incidentId` (HTTP 400), because later updates and recovery could not be matched reliably. ## Status and severity ---- The `status` attribute: @@ -84,7 +80,6 @@ The `severity` attribute accepts `HIGH`, `MEDIUM`, `LOW`, or the matching 0-10 s | Empty or unrecognized | Warning | ## Labels ---- | Label | Source | | :--- | :--- | @@ -97,7 +92,6 @@ The `severity` attribute accepts `HIGH`, `MEDIUM`, `LOW`, or the matching 0-10 s `deviceDetails`, which carries user names and emails, is not written to labels. ## Troubleshooting ---- - **FortiSIEM reports a failed push**: confirm **HTTP(S) Server URL** starts with `https://`, includes the full `integration_key`, and that the FortiSIEM network can reach `api.flashcat.cloud` - **Flashduty returns an invalid-parameter error**: confirm the body is FortiSIEM incident XML (root element `incident`) with an `incidentId` attribute diff --git a/en/on-call/integration/alert-integration/alert-sources/gatus.mdx b/en/on-call/integration/alert-integration/alert-sources/gatus.mdx index 18283a95..b02bdadf 100644 --- a/en/on-call/integration/alert-integration/alert-sources/gatus.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/gatus.mdx @@ -11,14 +11,12 @@ Gatus has no fixed webhook format: you write the request body in its configurati
## In Flashduty On-call ---- Create either a dedicated or shared **Gatus** alert integration and copy its complete Push URL.
## Configure Gatus ---- @@ -81,7 +79,6 @@ Restart or reload Gatus so the configuration takes effect. Make an endpoint cond ## Alert Key ---- Flashduty computes the Alert Key from the endpoint's `group` and `name`. Gatus identifies an endpoint by `_` and provides no separate ID per alert, so the trigger, reminders, and recovery of one endpoint share one Alert Key. An endpoint without a group uses `name` alone. @@ -90,7 +87,6 @@ Flashduty computes the Alert Key from the endpoint's `group` and `name`. Gatus i - Changes to `url`, `description`, or `errors` do not change the Alert Key ## Status and severity ---- | Gatus `[ALERT_TRIGGERED_OR_RESOLVED]` | Flashduty status or severity | | :--- | :--- | @@ -100,7 +96,6 @@ Flashduty computes the Alert Key from the endpoint's `group` and `name`. Gatus i Gatus alerts have no severity field, so a failing endpoint health check is treated as Critical. Empty or other status values are rejected. ## Troubleshooting ---- - **Gatus logs `status code 400`**: confirm `method` is `POST`, the body is valid JSON, and `name` and `status` are not empty. Gatus escapes only double quotes in `[RESULT_ERRORS]`; a double quote, backslash, or line break in an endpoint name, group, or description breaks the JSON, so avoid those characters - **Gatus logs `status code 404` or `401`**: confirm the Push URL is complete and contains `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/gcp-personalized-service-health.mdx b/en/on-call/integration/alert-integration/alert-sources/gcp-personalized-service-health.mdx index 3e9b4594..cfeee37f 100644 --- a/en/on-call/integration/alert-integration/alert-sources/gcp-personalized-service-health.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/gcp-personalized-service-health.mdx @@ -9,7 +9,6 @@ Personalized Service Health writes the Google Cloud events that affect your proj
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the Google Cloud Monitoring integration type** in both, not Personalized Service Health. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Google
## Configure in Google Cloud ---- ### Step 1: Prepare @@ -101,14 +99,12 @@ gcloud logging write --payload-type=json LOG_NAME '{ "category": "INCIDENT", "re Use the Service Health log name for `LOG_NAME`; the Google documentation uses the format `projects/PROJECT_ID/logs/servicehealth.googleapis.com%2Factivity`. ## Enable the auto-resolve timeout ---- For log-based alerting policies, Cloud Monitoring only sends a notification when an incident opens, not when it closes (the API documents the notification prompt of log-based policies as always `OPENED`), so Flashduty receives no recovery notification. Enable the [auto-resolve timeout](/en/on-call/channel/create-edit) on the channel that receives these alerts, choose **Incident trigger** as the window timing start, and start with 24 hours, adjusted to the usual duration of the events you care about. The `autoClose` setting in the alerting policy only decides when the incident closes in Cloud Monitoring (7 days by default for log-based alerts); it does not notify Flashduty. ## Field mapping ---- | Cloud Monitoring field | Flashduty | | :--- | :--- | @@ -123,7 +119,6 @@ The `autoClose` setting in the alerting policy only decides when the incident cl | `incident.policy_user_labels` | Each key becomes a label | ## Troubleshooting ---- - **No alert arrives**: confirm in **Monitoring** → **Incidents** that the incident opened; check whether the log filter matches, and note that notifications are rate limited (the Google documentation gives 20 alerts per policy per day per project as an example) - **The alert does not recover**: log-based alerts send no closure notification, so enable the channel's auto-resolve timeout diff --git a/en/on-call/integration/alert-integration/alert-sources/ghost-inspector.mdx b/en/on-call/integration/alert-integration/alert-sources/ghost-inspector.mdx index 0b3cf6ab..6227fbea 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ghost-inspector.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ghost-inspector.mdx @@ -9,7 +9,6 @@ Use a Ghost Inspector webhook to send test run results to Flashduty On-call. Eac
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Ghost Inspector ---- Ghost Inspector's notification settings have three levels — organization, suite, and test — and each level inherits from the one above by default, though you can override it at any level. Pick whichever level matches how broadly you want the webhook applied; setting it at the organization or suite level covers every test underneath at once. @@ -55,12 +53,10 @@ Ghost Inspector has no separate "send test notification" button: every test run, ## Alert key ---- Flashduty keys the alert on the test's `test._id`, the `data.test._id` field in the webhook body. Ghost Inspector sends the same `test._id` on every run of that test — unlike `data._id`, the id of that individual run's result, which is different every time — so a failing run and the later passing run of the same test reliably map to one alert. Changes to the test name, browser, region, or start/end URL do not change the alert key. ## Status and severity ---- Ghost Inspector has no severity levels, only a pass/fail result: @@ -72,7 +68,6 @@ Ghost Inspector has no severity levels, only a pass/fail result: A request missing the `passing` field is rejected, so Flashduty never treats an indeterminate result as a failure. ## Labels ---- | Label | Source | | :--- | :--- | @@ -86,7 +81,6 @@ A request missing the `passing` field is rejected, so Flashduty never treats an | `passing` | Whether this run passed | ## Troubleshooting ---- - **Flashduty returns a parameter error**: confirm the push URL includes `integration_key`, and the payload includes `data.test._id` and `data.passing` - **The alert never recovers**: confirm the recovery came from the same test, and that the level you configured the webhook at (test, suite, or organization) actually covers it diff --git a/en/on-call/integration/alert-integration/alert-sources/gitguardian.mdx b/en/on-call/integration/alert-integration/alert-sources/gitguardian.mdx index fd6704ae..d852edeb 100644 --- a/en/on-call/integration/alert-integration/alert-sources/gitguardian.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/gitguardian.mdx @@ -9,7 +9,6 @@ Use the Custom webhook destination of GitGuardian to send secret-leak incidents
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure GitGuardian ---- You need permission to manage integrations in the GitGuardian workspace. @@ -81,14 +79,12 @@ Trigger a new incident in the workspace and confirm that Flashduty receives an a ## Alert Key ---- Flashduty uses the incident `id` (`incident.id` in the webhook) as the Alert Key. In GitGuardian's published webhook examples, the New incident, New occurrence, Resolved, Ignored, and Reopened events of the same incident carry the same `incident.id`. Changes to severity, validity, occurrence count, or detector name do not change the Alert Key. Incident events without `incident.id` are rejected. ## Status and severity ---- The alert status follows `action`: `incident_resolved` and `incident_ignored` recover the alert, and every other event in the table above triggers it. A validity, severity, or risk score change on an incident that is already resolved or ignored is ignored and does not re-open the alert. A reopened incident triggers a new alert with the same Alert Key. @@ -104,7 +100,6 @@ The severity follows `incident.severity`: `unknown` means GitGuardian has not rated the incident yet, so Flashduty treats it as Warning. ## Labels ---- | Label | Source | | :--- | :--- | @@ -121,7 +116,6 @@ The severity follows `incident.severity`: | `repository` / `filepath` / `occurrence_url` | Repository, file path, and link of the new occurrence in `new_occurrence` events | ## Troubleshooting ---- - **No alert was created**: confirm the matching event is selected and that the webhook's filtering rules do not exclude the incident. GitGuardian states that webhook delivery is best effort and not guaranteed - **The alert did not recover**: confirm **Resolved** and **Ignored** are selected under **Incident status change** diff --git a/en/on-call/integration/alert-integration/alert-sources/github.mdx b/en/on-call/integration/alert-integration/alert-sources/github.mdx index c4217b11..eb64ef0e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/github.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/github.mdx @@ -14,7 +14,6 @@ Change events such as deployments and code pushes are not part of this integrati
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -35,7 +34,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure GitHub ---- A webhook can be created on a single repository or on an organization (covering every repository in it). A repository webhook requires admin access to the repository; an organization webhook requires the organization owner role. @@ -83,7 +81,6 @@ GitHub does not retry failed deliveries automatically. Use **Redeliver** in **Re ## Events and alert status ---- GitHub puts the event type in the `X-GitHub-Event` request header and the action in the `action` field of the body. Flashduty handles them as follows: @@ -97,7 +94,6 @@ GitHub puts the event type in the `X-GitHub-Event` request header and the action `ping` and other event types (such as a `push` selected by mistake) also get a success response without creating an alert. ## Alert Key ---- - **Security alerts**: the Alert Key is built from the event type, the repository ID (`repository.id`), and the alert number (`alert.number`). The alert number is unique per repository and alert type, and GitHub uses it to address the alert in its API (for example, `/repos/{owner}/{repo}/dependabot/alerts/{alert_number}`). The Alert Key stays the same from creation through fix, dismissal, and reopening, and renaming the repository does not change it. - **Actions failures**: the Alert Key is built from the repository ID, the workflow ID (`workflow_run.workflow_id`), the ID of the repository the run came from (`workflow_run.head_repository.id`), and the branch (`workflow_run.head_branch`). Later runs of the same workflow on the same branch, including **Re-run**, merge into this alert, and any successful run recovers it. Each branch and each workflow gets its own alert; a pull request from a fork never merges with a branch of the same name in your repository. A run without branch information gets its own alert keyed by the run ID (`workflow_run.id`), which recovers only when a **Re-run** of that run succeeds. @@ -105,7 +101,6 @@ GitHub puts the event type in the `X-GitHub-Event` request header and the action Events without `repository.id`, `alert.number`, `workflow_run.id`, or `workflow_run.workflow_id` are rejected. ## When alerts do not recover ---- In these cases no successful run follows, so the alert does not recover on its own: @@ -116,7 +111,6 @@ In these cases no successful run follows, so the alert does not recover on its o We recommend turning on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) with **Incident trigger** as the **Window timing start** and a **Timeout duration** of 24 hours. A failed workflow is normally fixed within a working day. Security alerts recover when they are fixed, dismissed, or closed in GitHub, so a channel that only receives security alerts can leave the timeout off. ## Severity ---- | Event | GitHub field | GitHub value | Flashduty severity | | :--- | :--- | :--- | :--- | @@ -134,7 +128,6 @@ We recommend turning on the channel's [auto-resolve timeout](/en/on-call/channel A recovery event keeps the alert's existing severity. ## Labels ---- | Label | Source | | :--- | :--- | @@ -151,7 +144,6 @@ A recovery event keeps the alert's existing severity. | `run_id` / `run_number` / `run_attempt` / `run_url` / `head_sha` | Workflow run ID, number, attempt, link, and commit | ## Troubleshooting ---- - **Recent Deliveries shows a failure**: open the delivery's **Response**. If it is not `200`, make sure the push URL is complete and includes `integration_key`. GitHub waits at most 10 seconds for a response - **Ping succeeds but no alert arrives**: make sure the four events above are selected and the repository has the matching security features enabled. Cancelled or skipped workflow runs never create alerts, and a successful run only recovers an existing one diff --git a/en/on-call/integration/alert-integration/alert-sources/gitlab.mdx b/en/on-call/integration/alert-integration/alert-sources/gitlab.mdx index a191fdb5..f984d7db 100644 --- a/en/on-call/integration/alert-integration/alert-sources/gitlab.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/gitlab.mdx @@ -9,7 +9,6 @@ Use a GitLab project or group webhook to sync failed pipelines, failed deploymen
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure GitLab ---- GitLab.com, GitLab Self-Managed and GitLab Dedicated all support webhooks. Project webhooks are available on every tier and require the Maintainer or Owner role on the project. Group webhooks require Premium or Ultimate and the Owner role on the group, and send events from every project in the group and its subgroups. @@ -71,7 +69,6 @@ For **Push events** (the default **Test** option) and other events unrelated to ## Alert Key ---- Flashduty builds the Alert Key from the business object, so the trigger and recovery events of one object share one Alert Key: @@ -84,7 +81,6 @@ Flashduty builds the Alert Key from the business object, so the trigger and reco The Alert Key combines the object type with the fields above, so a branch never merges with a tag or an environment of the same name. Renaming or moving the project does not change the Alert Key. A failed or successful event missing these fields is rejected. ## Status and severity ---- | Event | Status | Flashduty severity | | :--- | :--- | :--- | @@ -97,7 +93,6 @@ The Alert Key combines the object type with the fields above, so a branch never | Pipeline `success`, deployment `success`, vulnerability `resolved` / `dismissed` | Recover | - | ## When alerts do not recover automatically ---- These objects never receive a later successful event, so their alerts do not recover automatically: @@ -108,7 +103,6 @@ These objects never receive a later successful event, so their alerts do not rec Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit), set **Window timing start** to **Incident trigger**, and set the timeout to 24 hours. Pipeline and deployment failures are usually fixed within a working day. Vulnerability alerts recover when the vulnerability is resolved or dismissed, so a channel that only receives vulnerability alerts can leave the timeout off. ## Labels ---- | Label | Source | | :--- | :--- | @@ -130,7 +124,6 @@ Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit), s Pipeline variables (`variables`) and user emails never become labels. ## Troubleshooting ---- - **The webhook shows Temporarily disabled or Disabled**: GitLab temporarily disables a webhook after 4 consecutive failed deliveries and permanently disables it after 40. Check that the push URL is complete and includes `integration_key`, then click **Test** to send a test request and re-enable the webhook - **A rejected deployment raised an alert**: when a deployment to a protected environment is rejected, GitLab sends `rejected` and then, after dropping the deployment job, `failed` for the same deployment. Flashduty treats it as a failed deployment; close the alert by hand or let the next successful deployment recover it diff --git a/en/on-call/integration/alert-integration/alert-sources/google-cloud-monitoring.mdx b/en/on-call/integration/alert-integration/alert-sources/google-cloud-monitoring.mdx index fa64c25c..7ec84837 100644 --- a/en/on-call/integration/alert-integration/alert-sources/google-cloud-monitoring.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/google-cloud-monitoring.mdx @@ -8,7 +8,6 @@ Sync Google Cloud Monitoring, Error Reporting, Security Command Center, and Clou
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Google Cloud ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/google-scc.mdx b/en/on-call/integration/alert-integration/alert-sources/google-scc.mdx index bf106e8d..3359060a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/google-scc.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/google-scc.mdx @@ -9,14 +9,12 @@ Google Security Command Center (SCC) publishes new and updated findings to a Pub
## In Flashduty On-call ---- Create either a dedicated or shared **Google Security Command Center** alert integration and copy its complete Push URL.
## Configure Google Cloud ---- You need an organization with Security Command Center enabled and a project to hold the Pub/Sub topic. Creating a notification config requires Security Center Admin (`roles/securitycenter.admin`) on the organization and Project IAM Admin (`roles/resourcemanager.projectIamAdmin`) on the project that holds the topic. @@ -74,14 +72,12 @@ Pub/Sub push subscriptions have no test button. Make SCC produce a finding that ## Alert Key ---- Flashduty uses `finding.name` as the Alert Key, in the form `organizations/{organization ID}/sources/{source ID}/findings/{finding ID}`. In the SCC Finding resource, `name` is the finding's relative resource name, and the notifications for a finding's creation, updates and change to `INACTIVE` all carry the same value. Changes to the title, severity, state, category or event time do not change the Alert Key. A request without `finding.name` is rejected, because later updates and the recovery could not be matched to the alert. ## Status and severity ---- | SCC field | Flashduty status or severity | | :--- | :--- | @@ -98,7 +94,6 @@ The alert title is `category: resource display name` (for example `OPEN_FIREWALL Flashduty also writes these labels: `category`, `resource_name`, `resource_type`, `project`, `location`, `service`, `finding_name`, `finding_state`, `finding_severity`, `finding_class`, `finding_source`, `notification_config_name`, `external_uri`. `securityMarks` is not read. ## Troubleshooting ---- - **Pub/Sub keeps redelivering the same message**: Flashduty returns a 4xx for requests it cannot parse, and Pub/Sub retries with backoff. Check that the push endpoint contains `integration_key` and that payload unwrapping is off. Configure a dead-letter topic on the subscription to avoid endless retries - **Flashduty returns an invalid-parameter error**: the message names the missing field, for example `finding.name is required` means the notification has no finding diff --git a/en/on-call/integration/alert-integration/alert-sources/grafana.mdx b/en/on-call/integration/alert-integration/alert-sources/grafana.mdx index 08f977a3..b0809ea8 100644 --- a/en/on-call/integration/alert-integration/alert-sources/grafana.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/grafana.mdx @@ -8,7 +8,6 @@ Sync Grafana alert events to Flashduty via webhook to achieve automated alert no
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In Grafana ---- Grafana V4~V8 versions enable Legacy Alerting by default, while V9 and later versions enable Grafana Alerting by default. For feature distinctions and activation methods, please refer to the [official documentation](https://grafana.com/docs/grafana/v8.4/alerting/unified-alerting/opt-in/#opt-in-to-grafana-alerting). Follow these steps based on your deployed version. ### Legacy Alerting @@ -83,7 +81,6 @@ Grafana V4~V8 versions enable Legacy Alerting by default, while V9 and later ver 7. Complete ## Status Mapping ---- Legacy Alerting to Flashduty severity mapping: diff --git a/en/on-call/integration/alert-integration/alert-sources/graylog.mdx b/en/on-call/integration/alert-integration/alert-sources/graylog.mdx index a38673b0..d8e372c0 100644 --- a/en/on-call/integration/alert-integration/alert-sources/graylog.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/graylog.mdx @@ -8,7 +8,6 @@ Sync Graylog alert events to Flashduty via webhook for automated alert noise red
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Graylog ----
## I. Graylog Alert Push Configuration diff --git a/en/on-call/integration/alert-integration/alert-sources/guance.mdx b/en/on-call/integration/alert-integration/alert-sources/guance.mdx index 989aab49..3a244ef1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/guance.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/guance.mdx @@ -8,7 +8,6 @@ Sync Guance monitoring alert events to Flashduty via webhook for automated alert
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Dedicated Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Guance ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/hackerone.mdx b/en/on-call/integration/alert-integration/alert-sources/hackerone.mdx index bb69951f..e35b1a66 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hackerone.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hackerone.mdx @@ -9,7 +9,6 @@ Use the webhook of a HackerOne program to send vulnerability reports to Flashdut
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure HackerOne ---- Webhooks are configured per program and inherit the permissions of the user who creates them: that user must be able to see the program's reports and change its settings. @@ -79,14 +77,12 @@ When editing the webhook, you can click **Test request** to send an example requ ## Alert Key ---- Flashduty uses the report ID (`data.report.id` in the webhook) as the Alert Key. Every HackerOne delivery carries the full report, and the same report has the same `data.report.id` when it is submitted, triaged, closed, or reopened. It is also the number in the report URL `https://hackerone.com/reports/`. Changes to the title, state, or severity do not change the Alert Key. Deliveries that contain a report without `data.report.id` are rejected. ## Status and severity ---- The report's current state (`data.report.attributes.state`), not the event name, sets the alert status: @@ -111,7 +107,6 @@ The report severity (`data.report.relationships.severity.data.attributes.rating` When triage changes a report's severity, the alert is updated with the new severity. ## Labels ---- | Label | Source | | :--- | :--- | @@ -126,7 +121,6 @@ When triage changes a report's severity, the alert is updated with the new sever The alert description is the report's vulnerability information (`vulnerability_information`), truncated beyond 8 KB. ## Troubleshooting ---- - **HackerOne shows a failed delivery**: Open the failed request under **Recent deliveries** on the webhook edit page and check Flashduty's reply on the **Response** tab. Make sure the **Payload URL** is complete and includes `integration_key` - **The alert does not recover**: Make sure `report_resolved` and all four `report_closed_as_*` events are checked. Close alerts manually in Flashduty for reports that were closed while those events were not selected diff --git a/en/on-call/integration/alert-integration/alert-sources/harness.mdx b/en/on-call/integration/alert-integration/alert-sources/harness.mdx index 7a7ab6f0..8a69558a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/harness.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/harness.mdx @@ -9,7 +9,6 @@ Use the Webhook method of a Harness pipeline notification rule to sync failed Ha
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Harness ---- Every Harness SaaS edition supports notification rules on a pipeline. You need the **Create/Edit** permission on the pipeline. The steps below configure one pipeline. If centralised notifications are enabled on your account, you can also configure many pipelines at once under **Account Settings → Notification Rules**; choose the events and the notification method the same way. @@ -80,7 +78,6 @@ Run the pipeline so that it fails (for example, run `exit 1` in a Shell Script s ## Alert Key ---- Flashduty builds the Alert Key from the pipeline and stage, so the failure and success events of one object share one Alert Key: @@ -95,7 +92,6 @@ Changes to the display names of pipelines, stages and triggers, to the execution If both pipeline and stage events are selected, one failure raises two alerts: one for the pipeline and one for the failed stage. Select the events of one level only if you need just one. ## Status and severity ---- | Event | Status | Flashduty severity | | :--- | :--- | :--- | @@ -105,7 +101,6 @@ If both pipeline and stage events are selected, one failure raises two alerts: o | `PipelineSuccess`, `StageSuccess` | Recover | - | ## When alerts do not recover automatically ---- In these cases no later success event arrives for the same object, so the alert does not recover automatically: @@ -116,7 +111,6 @@ In these cases no later success event arrives for the same object, so the alert Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit), set **Window timing start** to **Incident trigger**, and set the timeout to 12 hours. Pipeline failures are usually fixed on the same day, and alerts that never recover close when the timeout expires. ## Labels ---- | Label | Source | | :--- | :--- | @@ -134,7 +128,6 @@ Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit), s User emails never become labels. ## Troubleshooting ---- - **No alerts arrive**: Check that the notification rule is enabled, that **Notification Method** is **Webhook**, and that the push URL is complete and includes `integration_key`. With delegate connectivity, check that the delegate can reach the Flashduty push URL - **Alerts don't recover**: Check that **Pipeline Success** (or **Stage Success**) is selected and that the same pipeline has since run successfully diff --git a/en/on-call/integration/alert-integration/alert-sources/healthchecks-io.mdx b/en/on-call/integration/alert-integration/alert-sources/healthchecks-io.mdx index b0499fe4..98362acd 100644 --- a/en/on-call/integration/alert-integration/alert-sources/healthchecks-io.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/healthchecks-io.mdx @@ -11,7 +11,6 @@ Self-hosted Healthchecks needs v3.5 or later, because the template below uses th
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure Healthchecks.io ---- @@ -94,7 +92,6 @@ To verify the full flow, make a check go down (for example, call `https://hc-pin ## Payload fields ---- | Field | Placeholder | Description | Use in Flashduty | | :--- | :--- | :--- | :--- | @@ -110,14 +107,12 @@ To verify the full flow, make a check go down (for example, call `https://hc-pin The alert title is the check name. When the name is empty, Flashduty uses the slug, then `Healthchecks.io check `. Every alert also carries the label `source=healthchecks-io`. ## Alert Key ---- Flashduty uses `$CODE` (`code`, the check UUID) as the Alert Key. The down and up notifications of a check carry the same UUID, so they land on the same alert. Different checks create different alerts even if they share a name. Renaming a check or changing its slug or tags does not change the Alert Key. A check that is deleted and created again gets a new UUID and is no longer linked to the old alert. ## Status and severity ---- Healthchecks.io notifications have no severity. Flashduty maps them as follows: @@ -129,7 +124,6 @@ Healthchecks.io notifications have no severity. Flashduty maps them as follows: An empty or any other `status` is rejected. ## FAQ ---- @@ -152,7 +146,6 @@ Yes. Each Healthchecks.io request times out after 30 seconds. On a connection fa ## Troubleshooting ---- - **Flashduty returns an invalid parameter error**: Confirm the method is POST, the request body is the JSON above, and `code` and `status` are unchanged - **JSON parsing fails**: Check whether a tag contains a double quote or backslash. `$TAGS` is inserted as is, and these characters make the body invalid JSON. Change the tag, or remove the `tags` line from the template diff --git a/en/on-call/integration/alert-integration/alert-sources/hertzbeat.mdx b/en/on-call/integration/alert-integration/alert-sources/hertzbeat.mdx index b043c5ee..5c5d63d7 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hertzbeat.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hertzbeat.mdx @@ -9,7 +9,6 @@ Use the Webhook type of a notice receiver under **Alerting → Notification →
## In Flashduty On-call ---- Get the push URL in either of two ways. @@ -30,7 +29,6 @@ Get the push URL in either of two ways.
## Configure HertzBeat ---- @@ -60,7 +58,6 @@ Flashduty parses only the default Webhook template that ships with HertzBeat. If ## Payload ---- HertzBeat POSTs the default template as JSON. One request can carry several alerts in `alerts`, and Flashduty handles each one: @@ -78,14 +75,12 @@ HertzBeat POSTs the default template as JSON. One request can carry several aler `commonLabels` and `commonAnnotations` are not read. ## Alert Key ---- The HertzBeat payload carries no alert ID. Flashduty builds the Alert Key from `alertname`, `instance` and `defineid` in `alerts[].labels`. In real HertzBeat 1.9.0 deliveries these three values were identical on trigger, repeated notification while firing, and recovery, so all three land on one Flashduty alert. Changing the severity, content or monitor name does not change the Alert Key. A request without `labels.alertname` is rejected with a parameter error, because a recovery could not be tied to its alert. A missing `instance` or `defineid` counts as empty. ## Status and severity ---- | HertzBeat field | Flashduty status or severity | | :--- | :--- | @@ -98,7 +93,6 @@ A request without `labels.alertname` is rejected with a parameter error, because A request with any other `status`, or an empty `alerts`, is rejected. In the default template `commonLabels.severity` is rewritten to decorated text (such as "Critical"), so it is not used for severity. ## FAQ ---- @@ -121,7 +115,6 @@ Flashduty recovers an alert only when HertzBeat sends `resolved`. On HertzBeat 1 ## Troubleshooting ---- - **Flashduty receives no alerts**: confirm the URL is the full push URL (with `integration_key`), a notice policy exists, and the alert matches it - **Flashduty returns a parameter error**: confirm the body is the default HertzBeat template JSON, `status` is `firing` or `resolved`, and every alert has `labels.alertname` diff --git a/en/on-call/integration/alert-integration/alert-sources/hetrixtools.mdx b/en/on-call/integration/alert-integration/alert-sources/hetrixtools.mdx index 1895490d..47fa5901 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hetrixtools.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hetrixtools.mdx @@ -13,7 +13,6 @@ Use the webhook of a HetrixTools contact list to send monitoring notifications t
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -34,7 +33,6 @@ You can get the integration push URL in either of the following ways.
## Configure HetrixTools ---- @@ -70,14 +68,12 @@ Blacklist Monitoring notifications are not sent in real time: HetrixTools batche ## Alert Key ---- **Uptime Monitoring**: Flashduty computes the Alert Key from `monitor_id`, the HetrixTools monitor ID. The `offline` and `online` notifications of a monitor carry the same `monitor_id`, so they land on the same alert. Repeat notifications while the monitor stays offline merge into that alert as well. Changes to the monitor name, target, category, timestamp, or failing locations do not change the Alert Key. A request without `monitor_id` is rejected, because its recovery could not be matched. **Server Monitoring Resource Usage and Blacklist Monitoring**: HetrixTools sends no recovery message for these notifications, so Flashduty creates a separate alert for each notification (and for each IP or domain in a blacklist notification). Close these alerts manually once handled. ## Status and severity ---- Uptime Monitoring notifications are handled by `monitor_status`: @@ -99,7 +95,6 @@ Resource usage severity comes from `resource_usage.resource_type`: Blacklist severity comes from `blacklisted_now`: greater than 0 (still listed) is Warning, and 0 (removed from every blacklist) is Info. ## Alert content ---- **Uptime Monitoring** @@ -120,7 +115,6 @@ Blacklist severity comes from `blacklisted_now`: greater than 0 (still listed) i - **Labels**: `check` (monitor label), `resource` (IP or domain), `source`, `notification` (always `blacklist`), `blacklisted_before`, `blacklisted_now`, `blacklisted_on` (comma-separated), `report_link` ## Troubleshooting ---- - **HetrixTools reports a failed delivery**: make sure the webhook is the full push URL, including `integration_key` - **Flashduty returns a parameter error**: uptime and resource usage notifications need `monitor_id`, and an uptime notification's `monitor_status` must be `offline` or `online`; every item of a blacklist notification needs `monitor` diff --git a/en/on-call/integration/alert-integration/alert-sources/honeybadger.mdx b/en/on-call/integration/alert-integration/alert-sources/honeybadger.mdx index 785a66c1..db66e03a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/honeybadger.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/honeybadger.mdx @@ -9,7 +9,6 @@ Use the Webhook integration of a Honeybadger project to send error (fault), upti
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Honeybadger ---- The Webhook integration is configured per project and is available only on Honeybadger's Team, Business, and Enterprise plans. You need administrative privileges on the project. @@ -78,7 +76,6 @@ The **Test this integration** button on the integration settings page sends an ` ## Alert Key ---- Flashduty builds the Alert Key from the object the event is about, so the trigger and recovery events of the same object share one Alert Key: @@ -93,7 +90,6 @@ Flashduty builds the Alert Key from the object the event is about, so the trigge The Alert Key combines the object type with the ID in the table, so an `up` event for a site does not recover that site's certificate alert, and an error ID never merges with an equal project ID. Changes to the error message, environment, occurrence count, site name, and similar fields do not change the Alert Key. Events without the required ID are rejected. ## Status and severity ---- Honeybadger events carry no severity, so Flashduty sets the status and severity from the event name: @@ -107,7 +103,6 @@ Honeybadger events carry no severity, so Flashduty sets the status and severity `cert_will_expire` and `volume_spike` have no recovery event. Close these alerts manually in Flashduty after handling them. ## Labels ---- | Label | Source | | :--- | :--- | @@ -130,7 +125,6 @@ Honeybadger events carry no severity, so Flashduty sets the status and severity | `url` | Link to the error, check, or check-in page in Honeybadger | ## Troubleshooting ---- - **Webhook is not in the integration list**: Confirm that the account is on the Team plan or higher and that you are a project administrator - **Flashduty returns a parameter error**: Confirm that the URL is complete and includes `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/honeycomb.mdx b/en/on-call/integration/alert-integration/alert-sources/honeycomb.mdx index 7962b476..1776f738 100644 --- a/en/on-call/integration/alert-integration/alert-sources/honeycomb.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/honeycomb.mdx @@ -9,7 +9,6 @@ Use a Honeycomb webhook recipient to send Trigger alerts and SLO burn alerts to
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Honeycomb ---- These steps require a Honeycomb account that can edit integrations in **Team Settings**. Triggers are available on every plan; SLOs and burn alerts require the Pro or Enterprise plan. @@ -156,7 +154,6 @@ To verify the full flow, let the Trigger condition actually fire and confirm tha ## Alert Key ---- Flashduty uses `instance_id` (`.Alert.InstanceID`) as the Alert Key. Honeycomb's template variable reference defines it as the unique identifier of one Trigger or burn alert firing, useful for deduplicating and correlating alerts. Honeycomb's official incident.io template also uses it as the `deduplication_key` and resolves the matching alert on `OK`. @@ -167,7 +164,6 @@ Flashduty uses `instance_id` (`.Alert.InstanceID`) as the Alert Key. Honeycomb's With **Group resolution alerts**, Flashduty also merges notifications by `instance_id` and recovers the alert when a notification with `status` `OK` arrives. The alert description lists the groups currently over the threshold. ## Status and severity ---- Flashduty uses `status` to tell triggers from recoveries, and the `severity` variable to set the severity. @@ -181,7 +177,6 @@ Flashduty uses `status` to tell triggers from recoveries, and the `severity` var When `status` is `OK`, Flashduty recovers the original alert and keeps its last severity. An empty or any other `status` is rejected. ## Labels ---- | Label | Source | | :--- | :--- | @@ -199,7 +194,6 @@ When `status` is `OK`, Flashduty recovers the original alert and keeps its last | `slo_id`, `slo_url` | ID and link of the related SLO (burn alerts only) | ## Troubleshooting ---- - **The Flashduty recipient is not selectable in Honeycomb**: Confirm that the matching alert type is enabled on the **Payload** tab and has a template - **Flashduty returns a parameter error**: Confirm that the template matches the one above and that `instance_id` and `status` are not empty. Honeycomb does not retry 4xx responses diff --git a/en/on-call/integration/alert-integration/alert-sources/hookdeck.mdx b/en/on-call/integration/alert-integration/alert-sources/hookdeck.mdx index 41a4a17b..2b0cc76b 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hookdeck.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hookdeck.mdx @@ -9,7 +9,6 @@ Hookdeck opens an issue when a delivery fails, a source rejects a request, a tra
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Hookdeck ---- Hookdeck sends webhook notifications to a source in your project, and a connection forwards them to a destination. So first create a connection that forwards notifications to Flashduty, then turn on webhook notifications in the project settings. @@ -83,14 +81,12 @@ curl -X POST '' \ ## Alert Key ---- Flashduty uses the Hookdeck issue ID (`issue.id`, such as `iss_...`) as the Alert Key. An issue keeps the same ID when it is opened, acknowledged, resolved, and reopened, so status update notifications apply to the alert created when the issue opened. Changes to the issue's error code, response status, first and last seen times, or connection name do not change the Alert Key. Requests without `issue.id` are rejected. ## Status and severity ---- The severity comes from the issue type (`issue.type`): @@ -114,7 +110,6 @@ The status comes from `issue.status`: Other status values are rejected with a parameter error. Only the `issue.opened` and `issue.updated` topics create alerts; other topics (such as `event.successful`) are accepted and ignored. ## Labels ---- | Label | Source | | :--- | :--- | @@ -134,7 +129,6 @@ Other status values are rejected with a parameter error. Only the `issue.opened` The failed request included in the notification (headers and body) is not written to labels. ## Troubleshooting ---- - **No alerts arrive**: Check that webhook notifications are on and point to the right source, and that the `flashduty` connection is not paused. In Hookdeck, open that connection's events and confirm that Flashduty returned 200 - **The alert does not recover**: Check that `issue.updated` is selected under Webhook topics, and mark the issue Resolved or Ignored in Hookdeck. Dismissing an issue does not change its status diff --git a/en/on-call/integration/alert-integration/alert-sources/hosted-graphite.mdx b/en/on-call/integration/alert-integration/alert-sources/hosted-graphite.mdx index 6cb8eed3..c75a3815 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hosted-graphite.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hosted-graphite.mdx @@ -9,7 +9,6 @@ Use a Hosted Graphite Webhook notification channel to send metric alert triggers
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Hosted Graphite ---- @@ -57,7 +55,6 @@ Hosted Graphite notifications carry no alert ID, so Flashduty tells alerts apart ## Payload ---- Hosted Graphite POSTs these fields as `application/json`. Flashduty parses them directly; no template is needed. @@ -73,14 +70,12 @@ Hosted Graphite POSTs these fields as `application/json`. Flashduty parses them | `timestamp`, `backoff_minutes` | Send time, backoff setting | Not stored | ## Alert Key ---- Flashduty computes the Alert Key as the MD5 of the alert name and metric name joined by a delimiter. The trigger and recovery of one alert on one metric carry the same name and metric, so they land on the same Flashduty alert; alerts with a different name or metric stay separate. Changing the condition or the current value does not change the Alert Key. Hosted Graphite provides no alert ID, so this combination is inferred: two alerts with the same name and metric merge. If `name` is missing, Flashduty returns a parameter error. ## Status and severity ---- Hosted Graphite notifications carry no severity, so Flashduty treats every alert as Warning. @@ -92,7 +87,6 @@ Hosted Graphite notifications carry no severity, so Flashduty treats every alert Requests with an empty or unknown `status` are rejected so they cannot corrupt an alert lifecycle. ## FAQ ---- @@ -109,7 +103,6 @@ No test button was observed for the Webhook channel. Verify by pushing a metric ## Troubleshooting ---- - **Hosted Graphite fails to deliver**: check that the URL is the full push URL including `integration_key` - **Flashduty returns a parameter error**: check that the body is JSON, `name` is not empty, and `status` is `alerting` or `recovered` diff --git a/en/on-call/integration/alert-integration/alert-sources/http-pull.mdx b/en/on-call/integration/alert-integration/alert-sources/http-pull.mdx index 13ae2d64..2ff24d64 100644 --- a/en/on-call/integration/alert-integration/alert-sources/http-pull.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/http-pull.mdx @@ -13,7 +13,6 @@ HTTP Pull is the right choice when your source **cannot send webhooks**, **is qu
## Setup Steps ---- ### In Flashduty @@ -42,7 +41,6 @@ When you need to route alert events to different channels based on the alert pay
## Configuration ---- ### HTTP Request @@ -95,14 +93,12 @@ When pagination is enabled, the response must additionally expose a field for th ``` ## Default Route ---- When creating a "Shared Integration" (under **Integration Center => Alert Events**), you must configure a default route — otherwise newly pulled events will be dropped. After creation, you can add finer-grained rules under **Route**. A "Dedicated Integration" (created under **Configuration → Integrations → Private integration** in a specific channel) is automatically bound to that channel and does not need a separate default route. ## Template Variables ---- The URL and request body support Go template syntax. There is currently **one** built-in variable: diff --git a/en/on-call/integration/alert-integration/alert-sources/huawei-apm.mdx b/en/on-call/integration/alert-integration/alert-sources/huawei-apm.mdx index 03af18b1..f60a5535 100644 --- a/en/on-call/integration/alert-integration/alert-sources/huawei-apm.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/huawei-apm.mdx @@ -8,7 +8,6 @@ Sync Huawei Cloud APM alerts to Flashduty through webhook, to achieve automatic
## In Flashduty ---- You can get an integration push URL through the following 2 methods, choose one of them. ### Use dedicated integration @@ -43,7 +42,6 @@ When you need to route alerts to different channels based on alert payload infor
## In Huawei Cloud ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/huawei-ces.mdx b/en/on-call/integration/alert-integration/alert-sources/huawei-ces.mdx index 4419112b..a97a4a94 100644 --- a/en/on-call/integration/alert-integration/alert-sources/huawei-ces.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/huawei-ces.mdx @@ -8,7 +8,6 @@ Sync Huawei Cloud CES alerts to Flashduty via webhook to achieve automated alert
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In Huawei Cloud CES ----
1. Log in to your Huawei Cloud console, search for `Cloud Eye Service` product, and enter its console @@ -72,7 +70,6 @@ Note: When creating a notification group, Huawei Cloud will send a request to Fl
## Status Mapping ----
Huawei Cloud CES to Flashduty alert severity mapping: diff --git a/en/on-call/integration/alert-integration/alert-sources/huawei-lts.mdx b/en/on-call/integration/alert-integration/alert-sources/huawei-lts.mdx index ccf21cd4..ee6e9dc0 100644 --- a/en/on-call/integration/alert-integration/alert-sources/huawei-lts.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/huawei-lts.mdx @@ -8,7 +8,6 @@ Sync Huawei Cloud Log Tank Service (LTS) alert events to Flashduty via webhook f
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Huawei Cloud ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/hund.mdx b/en/on-call/integration/alert-integration/alert-sources/hund.mdx index 288e2a73..a45b2be1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hund.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hund.mdx @@ -12,7 +12,6 @@ Use Hund status page outgoing webhooks (version 2) to send changes on your statu
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -33,7 +32,6 @@ You can get the integration push URL in either of the following ways.
## In Hund ---- @@ -67,7 +65,6 @@ You can also verify with a real event: create an issue on the status page and an ## Payload ---- Hund sends JSON. `event.kind` is the notification type: @@ -108,7 +105,6 @@ Fields used for component status (`degraded`, `restored`): Every alert also carries the labels `source=hund` and `event` (the notification type). ## Alert Key ---- - Issues: the issue ID. Every notification from creation through updates to resolution lands on the same alert - Components: the component ID. Hund creates a new status object on every state change (one ID for degraded, another for restored), so component alerts are keyed on the component itself, and `degraded` through `restored` for one component lands on the same alert @@ -116,7 +112,6 @@ Every alert also carries the labels `source=hund` and `event` (the notification Issue alerts and component alerts are independent. An issue can affect several components, which may each have their own alert; use the channel's [alert grouping](/en/on-call/channel/noise-reduction) to merge them into one incident. Changing an issue title or a component name does not change the Alert Key. ## Status and severity ---- | Hund notification | Flashduty status or severity | | :--- | :--- | @@ -132,7 +127,6 @@ Issue alerts and component alerts are independent. An issue can affect several c An update that carries a `state_override` takes precedence; otherwise the issue's own value is used. ## FAQ ---- @@ -155,7 +149,6 @@ There is one issue alert, keyed by the issue ID. Each component's `degraded` and ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: the payload has no `event.eventable.id` (issues) or `event.contexts.component.id` (component status) - **An issue alert does not recover**: confirm the issue is marked resolved or ended in Hund and that the subscription includes the matching notification diff --git a/en/on-call/integration/alert-integration/alert-sources/hyperdx.mdx b/en/on-call/integration/alert-integration/alert-sources/hyperdx.mdx index 9b029e69..79687e04 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hyperdx.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hyperdx.mdx @@ -9,7 +9,6 @@ Use a Generic webhook in HyperDX (the UI layer of ClickStack) to send search ale
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure HyperDX ---- Both open-source HyperDX and managed ClickStack in ClickHouse Cloud support Generic webhooks. A self-hosted HyperDX must be able to reach the public domain of the Flashduty push URL. @@ -94,7 +92,6 @@ To verify the full flow, make the alert condition actually match and confirm an ## Alert Key ---- Flashduty uses `event_id` (`{{eventId}}`) as the Alert Key directly. HyperDX's webhook template variable documentation states that `{{eventId}}` stays the same for one alert, group and webhook from trigger to recovery, and HyperDX's own incident.io template uses it as the deduplication key. @@ -104,7 +101,6 @@ Flashduty uses `event_id` (`{{eventId}}`) as the Alert Key directly. HyperDX's w - Changing the alert's **grouped by**, or deleting and recreating the webhook, produces a new `event_id`. Flashduty alerts triggered before the change receive no recovery and must be closed manually ## Status and severity ---- Flashduty uses `state` to decide between trigger and recovery, and `severity` to set the alert severity. @@ -124,7 +120,6 @@ Flashduty uses `state` to decide between trigger and recovery, and `severity` to `severity` is case-insensitive. HyperDX sends a recovery notification only when it previously sent a trigger notification for the alert. While an alert is silenced, HyperDX sends neither trigger nor recovery notifications. ## Labels ---- | Label | Source | | :--- | :--- | @@ -137,7 +132,6 @@ Flashduty uses `state` to decide between trigger and recovery, and `severity` to The alert title comes from `{{title}}` with the 🚨 and ✅ prefixes added by HyperDX removed. The alert description comes from `{{body}}`. ## Troubleshooting ---- - **Flashduty returns a parameter error**: Make sure the webhook body matches the template above, `event_id` and `state` are not empty, and string variables keep their surrounding double quotes - **Test Webhook succeeds but no alert appears**: This is expected. Test data does not create alerts diff --git a/en/on-call/integration/alert-integration/alert-sources/hyperping.mdx b/en/on-call/integration/alert-integration/alert-sources/hyperping.mdx index 925685b0..29cc7e87 100644 --- a/en/on-call/integration/alert-integration/alert-sources/hyperping.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/hyperping.mdx @@ -9,7 +9,6 @@ Use Hyperping's Webhooks integration to send monitor down (`check.down`) and rec
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Hyperping ---- @@ -53,7 +51,6 @@ Hyperping recommends testing with a monitor that returns an error, such as a pag The Webhook card on the Integrations page is marked Pro and needs the Pro plan or higher; during the free trial, clicking it redirects to the Billing page. If you cannot open the configuration, upgrade your plan first. ## Payload ---- Hyperping POSTs JSON. Flashduty parses it directly, with no template to configure: @@ -69,14 +66,12 @@ Hyperping POSTs JSON. Flashduty parses it directly, with no template to configur The alert title is the monitored URL; when the URL is empty it is `Hyperping monitor `. ## Alert Key ---- The Alert Key is `check.monitorUuid`. In the Hyperping documentation, the `check.down` and `check.up` samples carry the same `monitorUuid`, so a monitor's down and recovery notifications land on one alert, and different monitors produce different alerts. Changing the URL, status code, time, or check location does not change the Alert Key. If a request has no `check.monitorUuid`, Flashduty returns a parameter error, because the recovery could not be tied to its alert reliably. A notification whose `event` is neither `check.down` nor `check.up` (for example an event type Hyperping adds later) is ignored and acknowledged, and creates no alert. ## Status and severity ---- Hyperping notifications carry no severity, so a down is treated as Critical. @@ -88,7 +83,6 @@ Hyperping notifications carry no severity, so a down is treated as Critical. A request whose `event` is empty or any other value is rejected, so that a request of unknown state never enters the wrong alert lifecycle. ## FAQ ---- @@ -105,7 +99,6 @@ No. Notifications for the same monitor carry the same `monitorUuid` and merge in ## Troubleshooting ---- - **Hyperping shows a failed delivery**: confirm the webhook URL is the full push URL and includes `integration_key` - **Flashduty returns a parameter error**: confirm the request is a Hyperping JSON notification and that `event` and `check.monitorUuid` are not empty diff --git a/en/on-call/integration/alert-integration/alert-sources/ibm-qradar.mdx b/en/on-call/integration/alert-integration/alert-sources/ibm-qradar.mdx index 8c49fd87..24dcb830 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ibm-qradar.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ibm-qradar.mdx @@ -9,7 +9,6 @@ An IBM QRadar rule can run an email response, and the subject and body of that e
## In Flashduty On-call ---- Get the integration email address in either of the two ways below. **In both cases choose the Email integration type**, not IBM QRadar. @@ -30,7 +29,6 @@ Get the integration email address in either of the two ways below. **In both cas
## Configure in QRadar ---- A rule's email response uses the event or flow templates in `alert-config.xml`. QRadar's documentation describes how to edit them: [Configuring event and flow custom email notifications](https://www.ibm.com/docs/en/qsip/7.4.0?topic=notifications-configuring-event-flow-custom-email). Below is the minimal change that makes the email fit a Flashduty rule. @@ -93,7 +91,6 @@ In the response of each QRadar rule that should notify, enable the email notific ## Configure the push rule in Flashduty ---- QRadar rule emails have no recovery email; one email corresponds to one rule firing. One trigger rule is therefore enough, and the Alert Key is extracted from the email title as "rule name + source IP". @@ -111,7 +108,6 @@ Regex: /^\[QRadar\] (.+)$/ The default rule discards mail so that emails without the `[QRadar]` prefix (for example system notifications) do not create alerts. ## Recovery and deduplication ---- - A QRadar rule response does not send another email when the condition clears, so Flashduty never closes these alerts on its own. Enable the [auto-resolve timeout](/en/on-call/channel/create-edit) on the channel that receives this integration (24 hours suggested), or close alerts manually once handled. - When the same rule fires again for the same source IP, the title and Alert Key are the same, so Flashduty updates the existing alert. To distinguish by destination IP or user, add the matching parameter (such as `${DestinationIP}` or `${UserName}`) to ``. @@ -119,7 +115,6 @@ The default rule discards mail so that emails without the `[QRadar]` prefix (for - An email body over 128 KB is truncated and attachments are dropped; see the [email integration](/en/on-call/integration/alert-integration/alert-sources/email). ## Troubleshooting ---- - **No alerts arrive**: confirm **Deploy Full Configuration** was run, the rule's email response uses the new template, and the QRadar mail server can deliver to the Flashduty email address - **Every alert is discarded**: the email title does not start with `[QRadar] `, which means the rule is not using the new template; check the title of a received email diff --git a/en/on-call/integration/alert-integration/alert-sources/icinga.mdx b/en/on-call/integration/alert-integration/alert-sources/icinga.mdx index b4eeb109..7a65e3d2 100644 --- a/en/on-call/integration/alert-integration/alert-sources/icinga.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/icinga.mdx @@ -9,7 +9,6 @@ Icinga 2 has no built-in webhook notification method. This integration provides
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Icinga 2 ---- The configuration below works with Icinga 2.11 and later. The notification command only needs `curl`, installed on the Icinga 2 node that runs notifications, and that node must be able to reach the Flashduty push URL. @@ -131,7 +129,6 @@ You can also choose **Send custom notification** on the service page to check co Icinga 2 runs the notification command once for each user of a notification. If `users` or `user_groups` contains several users, the same notification is pushed several times. These pushes land on the same alert but create duplicate events. So configure only the `flashduty` user for the Flashduty notifications. ## Alert Key ---- Flashduty computes the Alert Key from the host name `host_name` and the service name `service_name`. Host notifications use an empty service name. Icinga 2 names a service object `host name!service name`, and a service name is unique within its host, so problem and recovery notifications for the same host or service land on the same alert. @@ -140,7 +137,6 @@ Changes to the state, plugin output, display names, host address, or groups do n Flashduty rejects a request that lacks `host_name` or `notification_type`, a host notification that lacks `host_state`, and a service notification that lacks `service_state`. ## Alert lifecycle ---- Icinga 2 sends a recovery notification only after it has sent a problem notification. An alert opened from an acknowledgement, downtime, flapping, or custom notification might never get a recovery notification to close it. So only problem notifications open alerts, and Flashduty handles each notification type `notification_type` as follows: @@ -157,7 +153,6 @@ While a problem lasts, Icinga 2 resends the `PROBLEM` notification every 30 minu The `apply Notification` rules above set no `types` or `states`, so Icinga 2 sends every notification type. When a downtime is removed, Icinga 2 sends the type `DOWNTIMECANCELLED`. Ignored notifications get a success response. ## Severity ---- Severity comes from the current state: `service_state` for service notifications and `host_state` for host notifications. @@ -173,14 +168,12 @@ Severity comes from the current state: `service_state` for service notifications A recovery event takes its severity from the state before the recovery (`service_last_state` or `host_last_state`). ## Alert content ---- - **Title**: ` on ` for service notifications, `Host ` for host notifications. Object names are used when no display name is set - **Description**: the plugin output `service_output` or `host_output` - **Labels**: `host`, `resource` (host name), `service`, `check` (service name, service notifications only), `notification_type`, `state`, `host_display_name`, `host_address`, `host_groups`, `service_display_name` and `service_groups` (service notifications only). Multiple groups are joined with commas ## Troubleshooting ---- - **No notification is sent**: check the object's notification history in Icinga Web, confirm the `flashduty` notification objects exist (run `icinga2 daemon -C --dump-objects` to write the object cache, then `icinga2 object list --type Notification --name '*flashduty'`), and confirm notifications are not disabled on the host or service - **The Icinga 2 log shows `exit code 22`**: `curl` got an HTTP 4xx/5xx response. Confirm that `vars.flashduty_push_url` is the full push URL and includes `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/imperva.mdx b/en/on-call/integration/alert-integration/alert-sources/imperva.mdx index 344afd8e..35c4d181 100644 --- a/en/on-call/integration/alert-integration/alert-sources/imperva.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/imperva.mdx @@ -9,7 +9,6 @@ The Imperva (Thales) Cloud Application and Network Security console has Webhook
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Imperva ---- @@ -61,7 +59,6 @@ Click **Test Webhook** on the connection. Flashduty creates an Info alert titled Imperva's webhook payload has a fixed format and cannot be templated. Imperva may deliver the same event more than once; Flashduty merges repeats under the same Alert Key, so no duplicate alerts appear. ## Events and recovery ---- | Notification subtype | Start event | End event | Flashduty severity | | :--- | :--- | :--- | :--- | @@ -80,7 +77,6 @@ Imperva's webhook payload has a fixed format and cannot be templated. Imperva ma - Other notification types (account, site, billing, subscription, policy changes, range status changes) create no alert; Flashduty acknowledges them and returns success ## Alert Key ---- The Alert Key is computed from the event family, the Imperva account ID, and the object identity. Start and end events read the same fields: @@ -95,7 +91,6 @@ The Alert Key is computed from the event family, the Imperva account ID, and the The title, event time, account name in the payload, and the webhook ID do not take part. A request without `event_type`, or without the object identity of its family, is rejected with an error that names the missing field. ## Labels ---- | Label | Source | | :--- | :--- | @@ -111,7 +106,6 @@ The title, event time, account name in the payload, and the webhook ID do not ta The alert title comes from `event_title` and the description from `event_details.event_body`. ## Troubleshooting ---- - **Test Webhook fails**: Imperva requires the receiver to answer 200 or 201. Check that the push URL is complete, the `integration_key` is valid, and the integration type is Imperva - **No alerts arrive**: check that the notification policy's Recipients use this Webhook Connection and that the event type is in the table above. Event types outside the table create no alert diff --git a/en/on-call/integration/alert-integration/alert-sources/infisical.mdx b/en/on-call/integration/alert-integration/alert-sources/infisical.mdx index b30ca3ee..8062a646 100644 --- a/en/on-call/integration/alert-integration/alert-sources/infisical.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/infisical.mdx @@ -11,7 +11,6 @@ Secret modifications (`secrets.modified`), change requests, and access requests
## In Flashduty On-call ---- You can get the integration Push URL in either of the following two ways. @@ -32,7 +31,6 @@ You can get the integration Push URL in either of the following two ways.
## Configure Infisical ---- @@ -61,7 +59,6 @@ In the channel that receives these alerts, turn on [auto-close timeout](/en/on-c ## Alert Key ---- The Infisical request body has no alert ID, so Flashduty uses the monitored object itself as the Alert Key: @@ -71,7 +68,6 @@ The Infisical request body has no alert ID, so Flashduty uses the monitored obje Repeated failures of one rotation (including manual runs and retries), or one honey token triggered several times from different IPs, merge into the same alert. A change in the error message, project name, source IP, or timestamp does not change the Alert Key. A request missing `project.projectId`, `project.environment`, `project.rotationName`, or `honeyToken.name` is rejected. ## Status and severity ---- | Infisical event | Flashduty severity | Notes | | :--- | :--- | :--- | @@ -83,7 +79,6 @@ Repeated failures of one rotation (including manual runs and retries), or one ho Neither alert has a recovery event. ## Troubleshooting ---- - **Infisical reports a failed webhook**: check that the Push URL is complete and includes `integration_key`, and that the webhook **Type** is **General** (the Slack and Microsoft Teams types send their own message formats) - **No alert after a rotation failure**: check that the webhook's **Environment** matches the rotation's environment, that **Secret Path** matches the rotation's folder (for example `/**`), and that **Secret Rotation Failed** is selected diff --git a/en/on-call/integration/alert-integration/alert-sources/influxdata.mdx b/en/on-call/integration/alert-integration/alert-sources/influxdata.mdx index 775914c9..b8be24af 100644 --- a/en/on-call/integration/alert-integration/alert-sources/influxdata.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/influxdata.mdx @@ -9,7 +9,6 @@ Sync Influxdata alert events to Flashduty via webhook to achieve automated alert
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -44,7 +43,6 @@ Choose this option when you need to route alerts to different channels based on
## In Influxdata ---- Supports Influxdata versions 1.x ~ 2.x, with different configurations for each version as detailed below. - [Version 2.x](#v2) diff --git a/en/on-call/integration/alert-integration/alert-sources/insightidr.mdx b/en/on-call/integration/alert-integration/alert-sources/insightidr.mdx index 78b5f0cd..da762f3b 100644 --- a/en/on-call/integration/alert-integration/alert-sources/insightidr.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/insightidr.mdx @@ -11,7 +11,6 @@ InsightIDR only sends "investigation created". It does not send updates or closu
## In Flashduty On-call ---- You can get the push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the push URL in either of the following ways.
## In Rapid7 InsightIDR ---- @@ -57,7 +55,6 @@ After that, every investigation InsightIDR generates is pushed as one alert. ## Event types ---- | `X-Rapid7-Event` | Effect in Flashduty | | :--- | :--- | @@ -66,17 +63,14 @@ After that, every investigation InsightIDR generates is pushed as one alert. | Any other value | The request is rejected with a parameter error | ## Alert Key ---- Flashduty uses `investigationId`, the fixed ID InsightIDR assigns to each investigation, as the Alert Key. Changes to the title, description, or time do not change it. A request without `investigationId` is rejected. ## Status and severity ---- The InsightIDR payload carries no severity, so every investigation is treated as Warning. To separate levels, adjust them in the integration's **Alert processing** by title or label. ## Labels ---- | Label | Source | | :--- | :--- | @@ -89,12 +83,10 @@ The InsightIDR payload carries no severity, so every investigation is treated as User emails and AD distinguished names (`distinguishedName`) are not written to labels. ## About signatures ---- InsightIDR signs the request body with the Secret (`X-Rapid7-Signature`). Flashduty does not verify it, so the `integration_key` in the push URL is the only credential; keep it private. You can also add custom headers on the exporter; Flashduty does not require them. ## Troubleshooting ---- - **Flashduty receives nothing**: the collector is hosted by you. Confirm it can reach the internet and that the URL is complete and includes `integration_key` - **Parameter error**: a missing `investigationId` means the request is not an investigation; an unsupported event means `X-Rapid7-Event` is neither `idr_investigation_created` nor `test` diff --git a/en/on-call/integration/alert-integration/alert-sources/instana.mdx b/en/on-call/integration/alert-integration/alert-sources/instana.mdx index 8621dba7..b315cbbb 100644 --- a/en/on-call/integration/alert-integration/alert-sources/instana.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/instana.mdx @@ -9,7 +9,6 @@ Use an IBM Instana Generic webhook alert channel to send Instana issues, inciden
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Instana ---- You need permission to configure alert channels and alerts in Instana. First create an alert channel that points to Flashduty, then select that channel in your alert configurations. @@ -89,14 +87,12 @@ An issue raised right after you save the alert configuration may not be delivere ## Alert Key ---- Flashduty uses the Instana issue ID (`issue.id`) as the Alert Key. An issue or incident carries the same `issue.id` when it opens and when it closes, so the close notification recovers the alert created when it opened. Changes to the issue title, severity, start time, or tags do not change the Alert Key. Requests without `issue.id` are rejected. ## Status and severity ---- Flashduty sets the alert severity from the issue's severity (`issue.severity`): @@ -117,7 +113,6 @@ Flashduty sets the alert severity from the issue's severity (`issue.severity`): Any other state value is rejected with a parameter error. ## Labels ---- | Label | Source | | :--- | :--- | @@ -138,7 +133,6 @@ Any other state value is rejected with a parameter error. Instana fills fields that do not apply with `not available`. Those fields do not become labels. ## Troubleshooting ---- - **Test channel reports that the domain is not allowed**: Instana SaaS may restrict the domains alert channels can send to. Contact IBM Instana support to allow the domain of the Flashduty push URL - **Flashduty returns a parameter error**: Make sure the URL is complete and includes `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/instatus.mdx b/en/on-call/integration/alert-integration/alert-sources/instatus.mdx index 85a5ac4f..dfd454f1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/instatus.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/instatus.mdx @@ -9,7 +9,6 @@ Use an Instatus webhook subscriber to send changes on a status page to Flashduty
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Add a webhook subscriber in Instatus ---- @@ -67,7 +65,6 @@ If you publish an incident or update without notifying subscribers, Instatus sen ## Payload ---- Instatus sends one JSON payload each time an incident is added or updated, a component changes status, or a maintenance is added or updated. Flashduty handles the first two: @@ -98,7 +95,6 @@ Instatus sends one JSON payload each time an incident is added or updated, a com Component alert titles look like `Website: major outage`. Every alert also carries the label `source=instatus`, plus `page_url` and `page_status`. The unsubscribe link in the payload (`meta.unsubscribe`) contains a subscription credential, so Flashduty does not write it to the alert. ## Alert Key ---- Flashduty builds the Alert Key per payload kind: @@ -110,7 +106,6 @@ Incident alerts and component alerts are independent. One outage usually produce Renaming an incident or component, or changing the impact, does not change the Alert Key. When the severity rises (for example a component going from `PARTIALOUTAGE` to `MAJOROUTAGE`), Flashduty opens a new alert at the higher severity and keeps the earlier alert open; the recovery delivery closes both. After an alert recovers, a new outage of the same component opens a new alert. ## Status and severity ---- **Component status** @@ -144,7 +139,6 @@ An incident with no affected component falls back to the same mapping applied to Scheduled maintenance (`maintenance` payloads with the status `NOTSTARTEDYET`, `INPROGRESS`, or `COMPLETED`) is planned change. Flashduty returns success and creates no alert. ## FAQ ---- @@ -173,7 +167,6 @@ In Instatus, open the subscriber under **Subscribers → Webhook** and click **U ## Troubleshooting ---- - **No alerts in Flashduty**: check that subscribers were notified when the incident or update was published. Scheduled maintenance and `UNDERMAINTENANCE` never create alerts - **Flashduty returns an invalid parameter error**: check that the push URL is complete (includes `integration_key`) and that the subscriber uses the default payload format. Payloads without `page.id`, an incident ID, or a component ID are rejected diff --git a/en/on-call/integration/alert-integration/alert-sources/intersight.mdx b/en/on-call/integration/alert-integration/alert-sources/intersight.mdx index 3f4b41f2..1dc73b23 100644 --- a/en/on-call/integration/alert-integration/alert-sources/intersight.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/intersight.mdx @@ -9,7 +9,6 @@ Cisco Intersight is Cisco's cloud platform for managing UCS, HyperFlex, and othe
## In Flashduty On-call ---- You can get the push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the push URL in either of the following ways.
## In Cisco Intersight ---- @@ -58,7 +56,6 @@ Subscribe only to `cond.Alarm`. Flashduty rejects pushes for other object types, ## Event types ---- | Push | Effect in Flashduty | | :--- | :--- | @@ -67,12 +64,10 @@ Subscribe only to `cond.Alarm`. Flashduty rejects pushes for other object types, | Request without an alarm (`Operation` `None`, `Event` null) | Creates a separate Info alert that never recovers | ## Alert Key ---- Flashduty uses the alarm's `Moid`, the fixed identifier Intersight assigns to each alarm, as the Alert Key. Creation, updates, and the clear of one alarm share the same Alert Key. Changes to the name, description, severity, or time do not change it, and a request without a `Moid` is rejected. ## Status and severity ---- | Intersight `Severity` | Flashduty severity | | :--- | :--- | @@ -82,7 +77,6 @@ Flashduty uses the alarm's `Moid`, the fixed identifier Intersight assigns to ea | Cleared | Recovery (severity from `OrigSeverity`, Info if it has no valid value) | ## Labels ---- | Label | Source | | :--- | :--- | @@ -96,12 +90,10 @@ Flashduty uses the alarm's `Moid`, the fixed identifier Intersight assigns to ea | `create_time` / `last_transition` | Alarm creation time and time of the last severity change | ## About signatures ---- Intersight signs requests with HMAC using the Secret you set (`Authorization` and `Digest` headers). Flashduty does not verify signatures, so the `integration_key` in the push URL is the only credential. Keep it private. ## Troubleshooting ---- - **Flashduty receives nothing**: confirm the webhook URL is complete and includes `integration_key`, and that Intersight can reach the public internet - **Parameter error returned**: an object type error means the subscription covers an object other than `cond.Alarm`; a missing `Moid` means the push is not an alarm object diff --git a/en/on-call/integration/alert-integration/alert-sources/jdcloud.mdx b/en/on-call/integration/alert-integration/alert-sources/jdcloud.mdx index 957dedd4..e36b0a33 100644 --- a/en/on-call/integration/alert-integration/alert-sources/jdcloud.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/jdcloud.mdx @@ -7,7 +7,6 @@ keywords: ["alert integration", "JD Cloud monitoring integration", "monitoring a
## In Flashduty On-call ---- You can obtain an integration push URL through either of these two methods: ### Using private integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In JD Cloud ---- @@ -97,7 +95,6 @@ Go back to the Flashduty console integration list page. If the latest event time ## Severity mapping ----
JD Cloud Monitoring to Flashduty severity mapping: diff --git a/en/on-call/integration/alert-integration/alert-sources/jfrog-xray.mdx b/en/on-call/integration/alert-integration/alert-sources/jfrog-xray.mdx index aff34b0c..07b21631 100644 --- a/en/on-call/integration/alert-integration/alert-sources/jfrog-xray.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/jfrog-xray.mdx @@ -11,7 +11,6 @@ Xray sends a webhook only when a scan finds violations and sends nothing when an
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure JFrog Xray ---- @@ -67,14 +65,12 @@ The Xray webhook page has no test button. Upload a component with a known vulner ## Recovery and auto-close ---- The Xray violation webhook is sent only when a scan finds violations. The request body has no field that marks a violation as fixed or ignored, so the alert in Flashduty does not recover on its own. Each delivery is a separate Flashduty alert. Close it by hand, or turn on [auto-close](/en/on-call/channel/create-edit) in the channel that receives this integration, set to how quickly your team handles vulnerabilities, for example 7 days. ## Alert Key ---- Xray creates an `alert_id` for each scan of a watch. When one scan matches several policy rules (for example a security policy and a license policy on the same watch), Xray sends one webhook per rule, all with the same `alert_id`. So Flashduty builds the Alert Key from `alert_id`, the watch name `watch_name`, the policy name `policy_name` and the rule name `policy_rule` (joined with an invisible separator, then MD5): @@ -84,7 +80,6 @@ Xray creates an `alert_id` for each scan of a watch. When one scan matches sever - If the body has no `watch_name`, Flashduty returns 400 and names the missing field ## Status and severity ---- The alert status equals its severity; it does not recover. The severity comes from the highest severity in the body, `top_severity`; if it is missing or not one of the values below, the most severe issue decides. @@ -95,7 +90,6 @@ The alert status equals its severity; it does not recover. The severity comes fr | `Low`, `Information`, `Unknown`, missing or any other value | Info | ## Alert content ---- One webhook holds every issue (`issues`) that the scan found under that rule. @@ -114,7 +108,6 @@ One webhook holds every issue (`issues`) that the scan found under that rule. | `artifacts` | Impacted components, most severe first, up to 20 | ## Troubleshooting ---- - **Flashduty receives nothing**: check that the policy rule's **Then** section has **Trigger webhook** selected with this webhook, that the policy is assigned to a watch, and that the watch is active. Xray sends a webhook only for newly found violations; saving a rule does not resend violations that already exist. **Apply on Existing Content** in the row actions of the watch does not resend them either. Upload a new vulnerable component to a watched repository to verify - **Flashduty returns a parameter error**: the body is not JSON, or it has no `watch_name`. Send the Xray violation webhook directly, not through a relay that rewrites the body diff --git a/en/on-call/integration/alert-integration/alert-sources/jiankongbao.mdx b/en/on-call/integration/alert-integration/alert-sources/jiankongbao.mdx index f44e6716..c3a6983e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/jiankongbao.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/jiankongbao.mdx @@ -8,7 +8,6 @@ Sync Jiankongbao alert events to Flashduty via webhook for automated alert noise
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Jiankongbao ---- This integration also covers Cloudwise Jiankongbao (including Jiankongbao 6) URL callback notifications. diff --git a/en/on-call/integration/alert-integration/alert-sources/jumpcloud.mdx b/en/on-call/integration/alert-integration/alert-sources/jumpcloud.mdx index 7f7b26b8..dea18809 100644 --- a/en/on-call/integration/alert-integration/alert-sources/jumpcloud.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/jumpcloud.mdx @@ -9,7 +9,6 @@ Send alerts raised by JumpCloud Insights rules to Flashduty On-call through a Ju
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure JumpCloud ---- @@ -62,14 +60,12 @@ The channel page's **Test Webhook** button only shows a simulated request and re ## Alert Key ---- Flashduty builds the Alert Key from `alert_id`, the ID of the JumpCloud alert. JumpCloud sends the same `alert_id` on every status change of one alert (Open, Acknowledged, Resolved, Auto-Resolved), so the trigger and the recovery land on the same Flashduty alert. Changes to the title, priority, description or update time do not change the Alert Key. A request without `alert_id` is rejected. JumpCloud documents that a new event after the threshold is reached updates the existing alert; those updates all fold into the same Flashduty alert. ## Status and severity ---- | JumpCloud `status` | Flashduty status | | :--- | :--- | @@ -86,7 +82,6 @@ JumpCloud documents that a new event after the threshold is reached updates the A recovery keeps the severity of the last payload. ## Labels ---- | Label | Source | | :--- | :--- | @@ -103,7 +98,6 @@ A recovery keeps the severity of the last payload. The alert title comes from `alert_title` and the description from `description`. ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: check that the URL is complete and includes `integration_key`, and that the request body is JSON - **An alert does not recover**: check that Alert Resolution is on in the rule and that the channel is enabled diff --git a/en/on-call/integration/alert-integration/alert-sources/juniper-mist.mdx b/en/on-call/integration/alert-integration/alert-sources/juniper-mist.mdx index 31095edb..b5b82d5a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/juniper-mist.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/juniper-mist.mdx @@ -9,7 +9,6 @@ Use webhooks in Juniper Mist to send alarms from the `alarms` topic to Flashduty
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Juniper Mist ---- @@ -76,7 +74,6 @@ The webhook only sends alarm types that are enabled. Enable the types you need i ## Alert Key ---- One delivery can carry several alarm events (the `events` array). Flashduty handles each event on its own. @@ -93,7 +90,6 @@ The paired types are: AP, switch, and WAN Edge offline and reconnect (`device_do Several critical-port alarms on the same switch or gateway share one Alert Key, and so do the two nodes of an HA cluster. ## Status and severity ---- | Event | Status | | :--- | :--- | @@ -115,7 +111,6 @@ Severity comes from `severity`: A recovery event keeps its own severity. ## Labels ---- | Label | Source | | :--- | :--- | @@ -132,7 +127,6 @@ A recovery event keeps its own severity. The alert title is `type: device or hostname`, for example `device down: d420b02000fa`. The description comes from `reasons`, `text`, `suggestion`, and `count`. ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: confirm the URL is complete and includes `integration_key`, and that the body is a Mist `alarms` topic payload - **An alert does not recover**: confirm the matching recovery type is enabled in Mist too (for example, if AP offline is enabled, also enable AP reconnected). Check each type's default enablement in `alarm_defs` diff --git a/en/on-call/integration/alert-integration/alert-sources/kapacitor.mdx b/en/on-call/integration/alert-integration/alert-sources/kapacitor.mdx index 22218d09..2469ed5d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/kapacitor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/kapacitor.mdx @@ -9,7 +9,6 @@ Kapacitor's [post event handler](https://docs.influxdata.com/kapacitor/v1/refere
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the InfluxData integration type** in both. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Influx
## Configure in Kapacitor ---- Use any one of the three ways below. Always enter the full push URL, including `?integration_key=...`. @@ -90,7 +88,6 @@ Then run `kapacitor define-topic-handler flashduty.yaml` and use `.topic('cpu-al Adding a `post` handler in the Chronograf 1.x Alert Rule Builder uses this same Kapacitor handler; see the [InfluxData integration](/en/on-call/integration/alert-integration/alert-sources/influxdata) for those steps. ## Field mapping ---- | Kapacitor field | Flashduty | | :--- | :--- | @@ -105,14 +102,12 @@ Adding a `post` handler in the Chronograf 1.x Alert Rule Builder uses this same For any other `level`, Flashduty rejects the event with `level ... is not supported`. ## Recovery and deduplication ---- - When the level returns to `OK`, Kapacitor sends an event with `level` `OK`, and Flashduty closes the alert with the same `id`. Do not use `.noRecoveries()` on `alert()`, or Kapacitor sends no recovery events. - The default `id` is `{{ .Name }}:{{ .Group }}` (measurement name and group). If you set a custom `.id()`, make sure the trigger and the recovery of one object use the same value. - To see Flashduty's error in the Kapacitor log, add `.captureResponse()` to `.post()` (`capture-response: true` for a topic handler); the response is logged when the status is not 2xx. ## Troubleshooting ---- - **Flashduty returns `Invalid parameters`**: the push URL is incomplete, `integration_key` is missing, or the integration type is not InfluxData - **`level ... is not supported`**: the `level` in the body is not `CRITICAL`, `WARNING`, `INFO` or `OK`; make sure the original Kapacitor alert data is sent, not a forwarded or rewritten body diff --git a/en/on-call/integration/alert-integration/alert-sources/keep.mdx b/en/on-call/integration/alert-integration/alert-sources/keep.mdx index 8d67112e..6089e5f5 100644 --- a/en/on-call/integration/alert-integration/alert-sources/keep.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/keep.mdx @@ -44,7 +44,6 @@ Choose this method when you need to route alerts to different channels based on ## In Keep ---- ### Field Definitions diff --git a/en/on-call/integration/alert-integration/alert-sources/kener.mdx b/en/on-call/integration/alert-integration/alert-sources/kener.mdx index e93294d9..01842faa 100644 --- a/en/on-call/integration/alert-integration/alert-sources/kener.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/kener.mdx @@ -11,7 +11,6 @@ Kener's webhook body is a template you write in the trigger. This page provides
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Kener ---- You need Kener 4.x and an account that can manage triggers and alert configurations in the admin console. The Kener server must be able to reach the Flashduty push URL. @@ -87,14 +85,12 @@ Kener renders the template without JSON escaping. The built-in default template ## Alert Key ---- Flashduty uses the Kener `alert_id` as the Alert Key. Kener creates an alert record when a monitor reaches the failure threshold and updates the same record when it recovers, so the trigger and the recovery carry the same `alert_id`. If the same monitor goes down again, Kener creates a new `alert_id`, which is a new alert in Flashduty. Changes to the monitor name, severity, status, or value do not change the Alert Key. A request without `alert_id` is rejected. `alert_id` is unique only within one Kener instance, so connect only one Kener instance to each Flashduty integration. ## Status and severity ---- | `alert_status` | Flashduty status | | :--- | :--- | @@ -110,7 +106,6 @@ Changes to the monitor name, severity, status, or value do not change the Alert The alert title combines the monitor identifier, the alert type, and the value, for example `my-api STATUS: DOWN`. ## Labels ---- | Label | Source | | :--- | :--- | @@ -124,7 +119,6 @@ The alert title combines the monitor identifier, the alert type, and the value, | `alert_url` | Link to the monitor page in Kener | ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: Confirm the URL is complete and includes `integration_key`, and that the trigger uses the template on this page. The response names the missing field - **The Kener trigger test fails**: The test result shows the HTTP status code or network error. Confirm the Kener server can reach the Flashduty push URL diff --git a/en/on-call/integration/alert-integration/alert-sources/kentik.mdx b/en/on-call/integration/alert-integration/alert-sources/kentik.mdx index c6651faa..80e89032 100644 --- a/en/on-call/integration/alert-integration/alert-sources/kentik.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/kentik.mdx @@ -9,7 +9,6 @@ Use a Kentik Custom Webhook notification channel to send alerts to Flashduty On-
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Kentik ---- Creating a notification channel requires the Administrator role in Kentik; Members can only view channels. @@ -97,7 +95,6 @@ Do not use this channel for mitigation methods or Insights notifications: these ## Alert Key ---- Flashduty uses the Kentik alert ID (`AlarmID`, shown as **Alert ID** in Kentik) as the Alert Key. Every state-change notification of one Kentik alert, from Active to Cleared, carries the same alert ID, so they merge into one alert, and the clear notification closes it. @@ -107,7 +104,6 @@ Flashduty uses the Kentik alert ID (`AlarmID`, shown as **Alert ID** in Kentik) - When one notification carries several events, each event maps to its own alert. A notification with no events is accepted but creates no alert ## Status and severity ---- The status comes from `IsActive`: @@ -129,7 +125,6 @@ The severity comes from the event importance (`Importance`, 0 to 7). For alert p | Other or empty | - | Info | ## Labels ---- | Label | Source | | :--- | :--- | @@ -145,7 +140,6 @@ The severity comes from the event importance (`Importance`, 0 to 7). For alert p The alert title is the Kentik event description (`Description`), such as `Alarm for DDoS Protect Policy Active`. ## Troubleshooting ---- - **Flashduty returns a parameter error**: make sure the URL is complete and includes `integration_key`, the channel type is **Custom Webhook**, and the template matches the one above - **`AlarmID is required`**: the channel is used for mitigation or Insights notifications, or the template was changed. Use the channel only for alert policies and Synthetics tests diff --git a/en/on-call/integration/alert-integration/alert-sources/komodor.mdx b/en/on-call/integration/alert-integration/alert-sources/komodor.mdx index e1cf5da1..a8c1ea4c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/komodor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/komodor.mdx @@ -9,7 +9,6 @@ Use the webhook notification channel of Komodor Realtime Health Monitors to send
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -46,13 +45,11 @@ Choose this method when you need to route alerts to different channels based on
## Prerequisites ---- - The Komodor Agent is installed in your Kubernetes cluster, and the cluster appears in the Komodor console. - Your account can edit Komodor **Health Policies**. ## In Komodor ---- @@ -89,7 +86,6 @@ Deploy monitor notifications describe a rollout (successful or failed), not a he ## Alert Key ---- Flashduty builds the Alert Key from the `monitorType`, `cluster`, `namespace`, and `resourceName` fields. For one kind of issue on one resource, the `open` and `closed` messages carry the same four values, so they merge into one alert and the `closed` message recovers it. @@ -98,7 +94,6 @@ Flashduty builds the Alert Key from the `monitorType`, `cluster`, `namespace`, a - Node issues have no namespace; an empty `namespace` still produces a valid Alert Key. ## Status and severity ---- Komodor webhook notifications carry no severity field, so Flashduty uses Critical for every issue. @@ -110,7 +105,6 @@ Komodor webhook notifications carry no severity field, so Flashduty uses Critica If `status` has any other value, or `monitorType`, `cluster`, or `resourceName` is missing, Flashduty returns an error and Komodor records a failed delivery. ## Labels ---- | Label | Source | | :--- | :--- | @@ -126,7 +120,6 @@ If `status` has any other value, or `monitorType`, `cluster`, or `resourceName` The alert title is ` issue on (/)`, and the description contains the issue details and the Komodor link. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/kscloud-monitor.mdx b/en/on-call/integration/alert-integration/alert-sources/kscloud-monitor.mdx index 598cfba6..919b6201 100644 --- a/en/on-call/integration/alert-integration/alert-sources/kscloud-monitor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/kscloud-monitor.mdx @@ -9,7 +9,6 @@ Sync metric and event alerts from Kingsoft Cloud Monitoring to Flashduty On-call
## In Flashduty On-call ---- You can obtain an integration push URL through either of the following methods. ### Use a dedicated integration @@ -44,7 +43,6 @@ Choose this method when you need to route alerts to different channels based on
## In Kingsoft Cloud ---- @@ -64,7 +62,6 @@ Return to the integration list in the Flashduty console. If the integration card ## Status and severity ---- Metric alerts support both firing and recovery notifications. Event alerts only send firing events and do not have corresponding recovery events. diff --git a/en/on-call/integration/alert-integration/alert-sources/kuvasz.mdx b/en/on-call/integration/alert-integration/alert-sources/kuvasz.mdx index fac22c76..38234328 100644 --- a/en/on-call/integration/alert-integration/alert-sources/kuvasz.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/kuvasz.mdx @@ -9,7 +9,6 @@ Kuvasz is an open-source, self-hosted uptime and SSL certificate monitor. Its **
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Kuvasz ---- Kuvasz integrations are configured only in the YAML configuration file, and you must restart the Kuvasz container after changing it. @@ -68,7 +66,6 @@ Make a monitor fail (for example, create an HTTP monitor that points to a URL re ## Alert Key ---- Flashduty uses the monitor type plus `monitorId` as the Alert Key. Each Kuvasz monitor has a fixed numeric ID, and the down (`*_DOWN`) and up (`*_UP`) messages of one monitor carry the same `monitorId`, so they land on the same Flashduty alert. @@ -79,7 +76,6 @@ Flashduty uses the monitor type plus `monitorId` as the Alert Key. Each Kuvasz m Flashduty rejects requests that have no `monitorId`. ## Alert lifecycle ---- Flashduty handles messages by the `type` field: @@ -96,19 +92,16 @@ Flashduty handles messages by the `type` field: Other types are ignored as well. `DNS_RECORDS_CHANGED` has no recovery message, so turn on [auto-close after timeout](/en/on-call/channel/create-edit) for the channel, start the timer from **Incident triggered**, and set about 24 hours. ## Severity ---- Kuvasz messages carry no severity. Down events and `SSL_INVALID` mean the service is unavailable and are fixed at **Critical**; `SSL_WILL_EXPIRE` and `DNS_RECORDS_CHANGED` are fixed at **Warning**. A recovery event keeps the original alert's severity. ## Alert content ---- - **Title**: the monitor name - **Description**: the event text Kuvasz generates (`eventDetails`) - **Labels**: `check` (monitor name), `monitor_id`, `monitor_type`, `monitor_name`, `monitor_urn`, `monitor_detail` (relative path of the monitor's details page), `event_type` (Kuvasz `type`), and `source` (always `kuvasz`) ## Troubleshooting ---- - **The test event created no alert**: this is expected; test events only verify connectivity - **4xx or an invalid `integration_key` error**: check that `url` is the full push URL and the integration is not disabled diff --git a/en/on-call/integration/alert-integration/alert-sources/lacework.mdx b/en/on-call/integration/alert-integration/alert-sources/lacework.mdx index 42ea7ed5..64cfde50 100644 --- a/en/on-call/integration/alert-integration/alert-sources/lacework.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/lacework.mdx @@ -9,7 +9,6 @@ Use a Lacework FortiCNAPP custom webhook alert channel to send compliance change
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In FortiCNAPP ---- @@ -66,14 +64,12 @@ Run **Test Integration** on the channel in the channel list (where available), o ## Alert Key ---- Flashduty builds the Alert Key from `lacework_account` and `event_id` in the request body. The FortiCNAPP documentation describes `event_id` as "The FortiCNAPP ID for the event". Repeated deliveries of one event (for example one notification per resource when the channel groups issues by resources) land on the same Flashduty alert, and each event opens its own alert. Changes to the title, severity, description or time do not change the Alert Key. A request without `event_id` opens an alert of its own. A request with none of `event_id`, `event_title` and `event_description` is rejected with a parameter error. ## Status and severity ---- The FortiCNAPP webhook has no status field, so every request is a trigger event. `event_severity` ranges from 1 to 5, with 1 the highest. @@ -87,7 +83,6 @@ The FortiCNAPP webhook has no status field, so every request is a trigger event. The alert title is `event_title` and the description is `event_description`. Alert labels include the Lacework account (`lacework_account`), event source (`event_source`), event type (`event_type`), event ID, raw severity, recommendation ID (`rec_id`, compliance events only), event time and event link. ## Troubleshooting ---- - **No alert arrives**: check that an alert rule uses the channel and that its severities, resource groups and alert categories cover the alert; a disabled channel delivers nothing - **The channel cannot be saved**: the webhook URL must be `https` and include the full `integration_key` query parameter diff --git a/en/on-call/integration/alert-integration/alert-sources/langsmith.mdx b/en/on-call/integration/alert-integration/alert-sources/langsmith.mdx index edef70dd..ebee9e38 100644 --- a/en/on-call/integration/alert-integration/alert-sources/langsmith.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/langsmith.mdx @@ -11,7 +11,6 @@ LangSmith's documentation describes no "resolved" notification: once the metric
## In Flashduty On-call ---- You can get the integration push URL in either of two ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of two ways.
## Configure in LangSmith ---- @@ -60,7 +58,6 @@ A LangSmith webhook has no recovery notification: after the metric falls back, n ## Payload ---- LangSmith POSTs these fields as `application/json`, and Flashduty parses them directly: @@ -82,19 +79,16 @@ LangSmith POSTs these fields as `application/json`, and Flashduty parses them di The alert title is the rule name; if it is empty, `LangSmith alert ` is used. ## Alert Key ---- Flashduty uses `alert_rule_id` as the Alert Key. LangSmith documents it as the UUID identifying the alert, and every firing of one rule carries the same `alert_rule_id`, so repeated notifications while the metric stays above the threshold merge into one alert and different rules stay separate. Changing the rule name, threshold or metric value does not change the Alert Key. A request without `alert_rule_id`, or with the all-zero UUID that LangSmith uses for test notifications, is treated as a test notification: Flashduty returns success and creates no alert. ## Status and severity ---- LangSmith notifications carry no severity, so Flashduty treats every one as Warning. A threshold breach does not mean the service is down, so the default is not Critical. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/lark-alert.mdx b/en/on-call/integration/alert-integration/alert-sources/lark-alert.mdx index 3cd4c4fa..54b9a349 100644 --- a/en/on-call/integration/alert-integration/alert-sources/lark-alert.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/lark-alert.mdx @@ -9,7 +9,6 @@ Generate a unique Feishu robot address in Flashduty, and synchronize the occurre
## Operation Steps ---- ### Create Lark Bot Compatible Integration @@ -76,12 +75,10 @@ By default, the system always creates new alerts for each message, but you can s - When Feishu message type is Text, Flashduty will generate a default alert title "Feishu Alert" ## Severity Mapping ---- Currently, all alerts pushed to Flashduty through the Feishu(lark) integration are set to Warning severity. However, you can customize the severity using the [alert pipeline](/en/on-call/integration/alert-integration/alert-pipelines). ## Alibaba Cloud Message Center ----
The "Robot Reception" feature in Alibaba Cloud's account Message Center can push account, product, and security notices to a custom webhook. Its data format can reuse the Feishu robot protocol, so it connects directly to the Lark Bot Compatible integration on this page. diff --git a/en/on-call/integration/alert-integration/alert-sources/last9.mdx b/en/on-call/integration/alert-integration/alert-sources/last9.mdx index 333b66ac..d28453a8 100644 --- a/en/on-call/integration/alert-integration/alert-sources/last9.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/last9.mdx @@ -9,7 +9,6 @@ Last9's webhook notification channel sends PagerDuty Events API v2 JSON to the U
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the PagerDuty Compatible integration type** in both, not Last9. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the PagerD
## Configure in Last9 ---- 1. In Last9, go to **Notification Channels** and click **Add Channel** → **Webhook** 2. Enter the full push URL copied above as the webhook URL, including `?integration_key=...` @@ -39,7 +37,6 @@ Get an integration push URL in either of the two ways below. **Choose the PagerD Last9 detects URLs for Microsoft Teams, Flock, Google Chat, Telegram, Jira and Zenduty and switches to their own formats. A Flashduty push URL is not one of them, so Last9 sends the generic format described here. ## Field mapping ---- | Last9 field | Flashduty | | :--- | :--- | @@ -53,7 +50,6 @@ Last9 detects URLs for Microsoft Teams, Flock, Google Chat, Telegram, Jira and Z | `links`, `images` | Labels keyed by the link text (or `link_N`, `img_N`) | ## Recovery and deduplication ---- - When Last9 sends a notification with `event_action` set to `resolve`, Flashduty closes the alert with the same `dedup_key`. - `severity` must be one of `critical`, `error`, `warning`, `info`; Flashduty rejects other values. @@ -61,7 +57,6 @@ Last9 detects URLs for Microsoft Teams, Flock, Google Chat, Telegram, Jira and Z - Last9's documentation does not describe test-button behavior. After the first setup, verify with a real alert that both the trigger and the recovery show up in Flashduty. ## Troubleshooting ---- - **Flashduty returns `Invalid parameters`**: the push URL is incomplete and lacks `integration_key`, or the integration type is not PagerDuty Compatible - **Alerts do not recover**: confirm Last9 sent a `resolve` notification and that its `dedup_key` matches the trigger diff --git a/en/on-call/integration/alert-integration/alert-sources/level.mdx b/en/on-call/integration/alert-integration/alert-sources/level.mdx index 5c2b644a..0aa706ff 100644 --- a/en/on-call/integration/alert-integration/alert-sources/level.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/level.mdx @@ -9,7 +9,6 @@ Use webhooks in Level (level.io) to send device alerts to Flashduty On-call. Lev
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Level ---- @@ -55,12 +53,10 @@ Level's documentation does not say whether the webhook has a test button or what ## Alert Key ---- Flashduty uses `data.id` (the Level alert ID) as the Alert Key, so `alert_active` and `alert_resolved` for the same alert share one Alert Key. Changes to the alert name, description, severity, or device hostname do not change it. Level's `event_id` identifies an event and stays the same across retries and manual re-runs; Flashduty does not use it as the Alert Key. Requests without `data.id` are rejected. ## Status and severity ---- | Event type | Status | | :--- | :--- | @@ -82,7 +78,6 @@ Severity comes from `data.severity`: A recovery event keeps the alert's existing severity. ## Labels ---- | Label | Source | | :--- | :--- | @@ -98,7 +93,6 @@ A recovery event keeps the alert's existing severity. The alert title is `hostname: alert name`, and the description comes from `data.description` and `data.payload`. ## Troubleshooting ---- - **Flashduty returns a parameter error**: check that the URL is complete and includes `integration_key`, and that the request body is in Level's webhook format - **Alerts do not recover**: check that the webhook has `alert_resolved` selected diff --git a/en/on-call/integration/alert-integration/alert-sources/librenms.mdx b/en/on-call/integration/alert-integration/alert-sources/librenms.mdx index e49dafce..f7722fb1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/librenms.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/librenms.mdx @@ -9,7 +9,6 @@ LibreNMS pushes alerts through an alert transport of type **API**: every time an
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure LibreNMS ---- The steps below need LibreNMS 25.7.0 or later: the body template escapes text fields with the `json_encode` filter, which is available from 25.7.0. @@ -106,7 +104,6 @@ Then make a rule really trigger (for example, make a monitored device unreachabl ## Alert Key ---- Flashduty uses `alert_id` as the Alert Key. `alert_id` is the row ID in the LibreNMS `alerts` table, which holds exactly one row per device and alert rule, and every trigger, change, and recovery notification carries the same value. The LibreNMS PagerDuty transport uses it as its dedup key too. So notifications for the same rule on the same device land on one alert, and a new trigger after recovery opens a new alert. @@ -115,7 +112,6 @@ Changes to the severity, rule name, host name, or alert message do not change th Flashduty rejects requests without `alert_id` or `state`. ## Alert lifecycle ---- Flashduty handles notifications by the `state` field: @@ -133,7 +129,6 @@ Rules that use an Operation (LibreNMS 26.4.0 and later) send only trigger, ackno When **Acknowledgement alerts** is on for a rule, LibreNMS sends a notification with `state` `2` when the alert is acknowledged. Acknowledgements neither open nor close a Flashduty alert, and ignored notifications get a success response. ## Severity ---- The severity comes from the **Severity** of the alert rule: @@ -147,7 +142,6 @@ The severity comes from the **Severity** of the alert rule: Recovery notifications carry the same rule severity, and the recovery event keeps it. ## Alert content ---- - **Title**: ` on `. When the rule name is empty, `LibreNMS rule ` is used instead - **Description**: the alert message `msg` rendered from the LibreNMS alert template. The default template includes the title, severity, time, and faulty items @@ -156,7 +150,6 @@ Recovery notifications carry the same rule severity, and the recovery event keep Empty fields are not written as labels. ## Troubleshooting ---- - **The test fails with `Transport delivery failed with 401` and `integration_key is required`**: put `integration_key` in **Options**, not in the **API URL** - **The test fails with `Transport delivery failed with 400`**: if the response shows `{{ $name|json_encode }}` unrendered, LibreNMS is older than 25.7.0 and does not know the `json_encode` filter; upgrade it. Otherwise make sure the fields with `|json_encode` have no extra quotes and that **Send as form** is unchecked diff --git a/en/on-call/integration/alert-integration/alert-sources/limacharlie.mdx b/en/on-call/integration/alert-integration/alert-sources/limacharlie.mdx index 5cfe092f..7395844a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/limacharlie.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/limacharlie.mdx @@ -11,7 +11,6 @@ LimaCharlie sends a detection once, when the rule matches, and sends no recovery
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure LimaCharlie ---- @@ -63,14 +61,12 @@ For an end-to-end check, let a D&R rule match once and confirm the alert arrives ## Alert Key ---- Flashduty uses the detection's `detect_id` as the Alert Key. The LimaCharlie documentation defines it as the unique detection identifier. A resent detection keeps its `detect_id` and merges into the same alert, and different detections become separate alerts. `cat` (the detection name), `priority`, and timestamps are not part of the Alert Key. A request that has `cat` but no `detect_id` is rejected with a parameter error. ## Severity ---- LimaCharlie provides only an optional integer `priority` (0 to 10) with no defined levels. The Flashduty mapping is: @@ -82,7 +78,6 @@ LimaCharlie provides only an optional integer `priority` (0 to 10) with no defin | 0, missing, or not a number | Warning | ## Field mapping ---- | Flashduty | LimaCharlie field | | :--- | :--- | @@ -93,12 +88,10 @@ LimaCharlie provides only an optional integer `priority` (0 to 10) with no defin The matched event (`detect`) and the extracted IOCs (`detect_data`) are not copied into labels. ## Alerts do not recover ---- A detection is a one-shot event and LimaCharlie sends no recovery. In the channel that receives this integration, turn on the [auto-resolve timeout](/en/on-call/channel/create-edit). 24 hours is a reasonable start; adjust it to how quickly your team handles detections. ## Troubleshooting ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/loadster.mdx b/en/on-call/integration/alert-integration/alert-sources/loadster.mdx index 283c79be..b1988efd 100644 --- a/en/on-call/integration/alert-integration/alert-sources/loadster.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/loadster.mdx @@ -9,7 +9,6 @@ Use the Loadster webhook integration to send monitor failure (**Monitor Fails**)
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Loadster ---- @@ -60,7 +58,6 @@ Make a monitor fail (for example, point an HTTP Request Monitor at a URL that re ## Payload ---- Loadster POSTs the following fields as JSON. Flashduty parses them directly, so no template is needed: @@ -76,12 +73,10 @@ Loadster POSTs the following fields as JSON. Flashduty parses them directly, so When the monitor name is empty, the alert title is `Loadster monitor `. ## Alert Key ---- Flashduty uses `monitor.id` as the Alert Key. The failure and recovery notifications of one monitor carry the same `monitor.id`, so they land on the same alert. Renaming the monitor does not change the Alert Key. The top-level `id` of the request is a new UUID for every notification and is not part of the Alert Key. ## Status and severity ---- Loadster notifications carry no severity, so Flashduty maps them as follows: @@ -93,7 +88,6 @@ Loadster notifications carry no severity, so Flashduty maps them as follows: Notifications without `monitor.id` (for example, load test started and finished notifications) are acknowledged and ignored without creating an alert. The Loadster webhook has no test button. ## FAQ ---- @@ -110,7 +104,6 @@ The Loadster webhook applies to the whole account. To separate monitors, use rou ## Troubleshooting ---- - **Loadster does not push**: confirm webhooks are enabled and saved under **Account → Integrations → Webhooks**, and that both URLs are the complete push URL containing `integration_key` - **Flashduty returns a parameter error**: confirm the request body contains `monitor.id` and `cycle.status` diff --git a/en/on-call/integration/alert-integration/alert-sources/loggly.mdx b/en/on-call/integration/alert-integration/alert-sources/loggly.mdx index 5ac70e74..f03502e7 100644 --- a/en/on-call/integration/alert-integration/alert-sources/loggly.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/loggly.mdx @@ -13,7 +13,6 @@ Loggly's alert feature is available only on paid plans (Standard, Pro); the free
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -34,7 +33,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Loggly ---- @@ -89,7 +87,6 @@ Loggly's HTTP Endpoints has no separate test-delivery button. Make the saved sea ## Alert Key ---- Flashduty keys the alert on the Loggly account subdomain (`owner_subdomain`) combined with the alert-definition ID. The alert-definition ID is parsed from `edit_alert_link` (the alert's edit-page URL) — the number after `/alerts/edit/`, for example `8188` in `.../alerts/edit/8188`. @@ -98,12 +95,10 @@ A request is rejected if `edit_alert_link` is missing, or is not shaped like `/a Repeated notifications from the same alert definition while its condition holds merge into one Flashduty alert instead of opening a new one each time; changes to the alert name, hit count, time window, or query do not affect the Alert Key. ## Severity ---- Loggly's HTTP Endpoints notification carries no severity field, so every alert triggers at **Warning**. A saved search crossing its hit-count threshold is not on its own an outage signal; raise the severity with an alert rule in Flashduty if a given saved search warrants it. ## Labels ---- | Label | Source | | :--- | :--- | @@ -118,7 +113,6 @@ Loggly's HTTP Endpoints notification carries no severity field, so every alert t | `num_hits` | Number of log lines matched in this check window | ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/logicmonitor.mdx b/en/on-call/integration/alert-integration/alert-sources/logicmonitor.mdx index 5eae67e4..bdea7a0d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/logicmonitor.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/logicmonitor.mdx @@ -9,7 +9,6 @@ LogicMonitor pushes alerts through a **Custom HTTP Delivery** integration: every
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure LogicMonitor ---- The steps below need a LogicMonitor user who can manage **Integrations**, **Escalation Chains**, and **Alert Rules**. @@ -112,7 +110,6 @@ Make a datapoint cross its alert threshold (for example, temporarily lower the t ## Alert Key ---- Flashduty uses `alert_id` (`##ALERTID##`, for example `LMD12345`) as the Alert Key. The LogicMonitor docs state that all alerts on one resource (or website), LogicModule, instance, and datapoint combination share the same alert ID, so the raise, severity change, and clear notifications land on one Flashduty alert. A new alert after a clear opens a new Flashduty alert. @@ -121,7 +118,6 @@ Changes to the severity, value, threshold, or alert message do not change the Al Flashduty rejects requests without `alert_id` or `alert_status`, or where either field is still the unreplaced `##ALERTID##` or `##ALERTSTATUS##`. ## Alert lifecycle ---- Flashduty handles each notification by its `alert_status` field (`##ALERTSTATUS##`): @@ -136,7 +132,6 @@ Flashduty handles each notification by its `alert_status` field (`##ALERTSTATUS# If you select **Acknowledged** in the integration, LogicMonitor sends an `ack` notification when an alert is acknowledged. An acknowledgement neither opens nor closes a Flashduty alert, and ignored notifications return success. ## Severity ---- The severity comes from the `level` field (`##LEVEL##`), case-insensitive: @@ -150,7 +145,6 @@ The severity comes from the `level` field (`##LEVEL##`), case-insensitive: The clear notification carries the level of the alert that cleared, and the recovery event keeps that severity. ## Alert content ---- - **Title**: ` on `, where the resource is the host name, or the website name for website alerts. Without a DataSource and datapoint, the title is the resource name; with none of them, it is `LogicMonitor alert ` - **Description**: the alert message rendered by `##MESSAGE##`, as configured in the LogicModule @@ -159,7 +153,6 @@ The clear notification carries the level of the alert that cleared, and the reco Empty fields are not written as labels. When a field does not apply to the alert type (for example, website alerts have no datapoint), LogicMonitor may leave a placeholder such as `##DATAPOINT##` as-is; Flashduty treats it as empty. ## Troubleshooting ---- - **Test Alert Delivery fails**: make sure **URL** is the full push URL including the `integration_key` parameter, and that **HTTP Method** is `HTTP Post` - **Flashduty says the body is not valid JSON**: make sure **Alert Data** uses **Raw** with the **JSON** format, and that every `##TOKEN##` in the template is inside double quotes diff --git a/en/on-call/integration/alert-integration/alert-sources/logpoint.mdx b/en/on-call/integration/alert-integration/alert-sources/logpoint.mdx index e0dbec1f..66718a83 100644 --- a/en/on-call/integration/alert-integration/alert-sources/logpoint.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/logpoint.mdx @@ -11,14 +11,12 @@ Logpoint sends a notification only when the rule triggers and sends nothing when
## In Flashduty On-call ---- Create either a dedicated or shared **Logpoint** alert integration and copy its complete Push URL.
## Configure Logpoint ---- The Logpoint HTTP Notification has no fixed payload; the body comes from the Jinja template you enter. Flashduty parses only the template below. @@ -69,12 +67,10 @@ Trigger the alert rule (or wait for it to match) and confirm Flashduty receives ## Alert Key ---- Flashduty uses `alertrule_id` (`{{alertrule_id}}`) as the Alert Key. The Logpoint documentation defines it as the ID of the alert. When the same rule triggers again it merges into the alert that is still open. `incident_id` changes on every trigger, so it is kept only as a label. Changes to the rule name, risk level or number of matching logs do not change the Alert Key. ## Status and severity ---- Flashduty maps severity from `risk_level` (`{{risk_level}}`): @@ -88,12 +84,10 @@ Flashduty maps severity from `risk_level` (`{{risk_level}}`): The Logpoint documentation does not list every `risk_level` value; its examples use `medium` and `high`, and `critical` and `low` are inferred from the risk options in the rule editor. ## Alerts do not recover ---- Logpoint sends no recovery notification. In the channel that receives this integration, turn on the [auto-resolve timeout](/en/on-call/channel/create-edit). 24 hours is a reasonable start; adjust it to how quickly your team handles alerts. ## Troubleshooting ---- - **Logpoint sends no request**: confirm Notification Trigger is **Automatic** and the rule is enabled and actually matching - **Flashduty returns a parameter error**: confirm the Body is valid JSON and keeps `alertrule_id`; double quotes in a log source or rule name break the JSON diff --git a/en/on-call/integration/alert-integration/alert-sources/logrocket.mdx b/en/on-call/integration/alert-integration/alert-sources/logrocket.mdx index 7728f7d3..7e5eb3f1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/logrocket.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/logrocket.mdx @@ -9,7 +9,6 @@ Use the Webhook alert type of a LogRocket Timeseries chart to send metric alerts
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure LogRocket ---- @@ -54,12 +52,10 @@ Push the metric past the threshold and confirm Flashduty receives an active aler The Issues Alerts webhook (new severe issues) uses a different message format and carries no alert ID, so it cannot be tied to a recovery. Flashduty acknowledges it and creates no alert. ## Alert Key ---- The Alert Key is the `alert_id` LogRocket sends. LogRocket documents that this ID stays the same across multiple triggerings and resolutions of the same alert, so the trigger and recovery events share one Alert Key. Editing the alert's threshold, interval, or chart location does not change it. Requests without `alert_id` are rejected. ## Status and severity ---- | LogRocket `status` | Flashduty status | Flashduty severity | | :--- | :--- | :--- | @@ -69,7 +65,6 @@ The Alert Key is the `alert_id` LogRocket sends. LogRocket documents that this I The LogRocket webhook carries no severity, and a metric crossing a threshold is not the same as an outage, so every alert is Warning. Any other `status` value is rejected. ## Labels ---- | Label | Source | | :--- | :--- | @@ -86,7 +81,6 @@ The LogRocket webhook carries no severity, and a metric crossing a threshold is The alert title and description come from `reason`, which LogRocket fills with the alert name you entered. Without `reason` the title is `LogRocket alert `. ## Troubleshooting ---- - **Flashduty returns an invalid parameter error**: check that the URL is complete and includes `integration_key`, and that the request comes from a Timeseries chart alert rather than Issues Alerts - **The alert does not recover**: check that the resolved notification is sent to the same URL and that its `alert_id` matches the one sent on trigger diff --git a/en/on-call/integration/alert-integration/alert-sources/logz-io.mdx b/en/on-call/integration/alert-integration/alert-sources/logz-io.mdx index ff36504f..7a235c8f 100644 --- a/en/on-call/integration/alert-integration/alert-sources/logz-io.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/logz-io.mdx @@ -11,7 +11,6 @@ A Logz.io Custom Endpoint only fires while the alert condition is met — there
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure Logz.io ---- @@ -87,7 +85,6 @@ A Logz.io Custom Endpoint has no recovery event: once the alert condition return ## Alert Key ---- Flashduty uses `alert_definition_id` as the Alert Key. Logz.io's own documentation describes it as the "Unique alert ID" (the alert definition's ID), as opposed to `alert_event_id`, the "Unique ID of the triggered alert instance" — which changes on every notification. So repeated firings of the same alert definition (including the repeat after the wait period ends, and escalation notifications across severity thresholds) land on the same Flashduty alert, while different alert definitions stay separate. @@ -96,7 +93,6 @@ Logz.io's Custom Endpoint variables do not expose the value of a group-by field. Changes to the title, description, severity, or timeframe never change the Alert Key. A request without `alert_definition_id` is rejected. ## Severity ---- | Logz.io `alert_severity` | Flashduty severity | | :--- | :--- | @@ -109,14 +105,12 @@ Changes to the title, description, severity, or timeframe never change the Alert `alert_severity` corresponds to the severity threshold (`severityThresholdTiers`) configured on the Logz.io alert; the value is matched case-insensitively. An empty or unlisted value is rejected. Because the Custom Endpoint never sends a recovery event, the alert status always equals the severity above — there is no "recovered" state. ## Alert content ---- - **Title**: `alert_title`; falls back to `Logz.io alert` when empty - **Description**: `alert_description` - **Labels**: `check` (the title), `source` (fixed to `logz_io`), `alert_definition_id`, `alert_event_id`, `account_id`, `account_name`, `alert_tags`, `alert_timeframe_start`, `alert_timeframe_end`, `alert_app_url`, `vendor_severity` (the raw `alert_severity` value) ## Troubleshooting ---- - **Flashduty returns a parameter error**: make sure the message body is valid JSON, `alert_definition_id` and `alert_severity` are not empty, and the `Content-Type: application/json` header is set - **A real alert never arrives (the test always shows failed, which is expected)**: make sure the alert's **Notification endpoints** include this Custom Endpoint, and that the alert condition actually triggered diff --git a/en/on-call/integration/alert-integration/alert-sources/mackerel.mdx b/en/on-call/integration/alert-integration/alert-sources/mackerel.mdx index 7066bdd2..bbf30a03 100644 --- a/en/on-call/integration/alert-integration/alert-sources/mackerel.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/mackerel.mdx @@ -9,7 +9,6 @@ Use a Mackerel Webhook notification channel to send Mackerel alerts to Flashduty
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Mackerel ---- @@ -60,14 +58,12 @@ A new channel is added to the default notification group, which receives every n ## Alert Key ---- Flashduty uses the Mackerel alert's `alert.id` as the Alert Key. A Mackerel alert keeps the same ID from the moment it opens, through status changes, until it closes, so these notifications merge into one Flashduty alert. When the same monitor fires again after its alert closed, Mackerel creates a new alert ID and Flashduty creates a new alert. Changes to the monitor name, message, metric value, or host status do not change the Alert Key. Alert notifications without `alert.id` are rejected. ## Status and severity ---- | Mackerel `alert.status` | `alert.isOpen` | Status | Flashduty severity | | :--- | :--- | :--- | :--- | @@ -80,7 +76,6 @@ When the same monitor fires again after its alert closed, Mackerel creates a new Mackerel ranks Unknown at the same level as Critical, so Flashduty maps it to Critical. Closing an alert manually, deleting its monitor, retiring its host, or deleting its service all close the alert (`alert.isOpen` is `false`), and Flashduty recovers the alert. ## Labels ---- | Label | Source | | :--- | :--- | @@ -101,7 +96,6 @@ Mackerel ranks Unknown at the same level as Critical, so Flashduty maps it to Cr The alert `message` and the monitor `memo` are written to the alert description. ## Troubleshooting ---- - **Flashduty returns a parameter error**: Make sure the URL is complete and includes `integration_key` - **No alerts arrive**: Make sure the channel subscribes to the alert (`alert`) event, the channel's notification group includes the monitor, the host status is `working` (Mackerel does not send alert notifications for hosts in `standby`, `maintenance`, or `poweroff`), and the monitor's notifications are not muted diff --git a/en/on-call/integration/alert-integration/alert-sources/meraki.mdx b/en/on-call/integration/alert-integration/alert-sources/meraki.mdx index 1c34b67d..a8ac0812 100644 --- a/en/on-call/integration/alert-integration/alert-sources/meraki.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/meraki.mdx @@ -8,7 +8,6 @@ Sync Meraki alert events to Flashduty via webhook for automated alert noise redu
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Meraki ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/metoro.mdx b/en/on-call/integration/alert-integration/alert-sources/metoro.mdx index 00335079..595fba44 100644 --- a/en/on-call/integration/alert-integration/alert-sources/metoro.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/metoro.mdx @@ -11,14 +11,12 @@ You write the Metoro webhook body yourself in **Body Template**, and Metoro subs
## In Flashduty On-call ---- Create either a dedicated or shared **Metoro** alert integration and copy its complete Push URL.
## Configure Metoro ---- @@ -65,7 +63,6 @@ Metoro has no separate test button. Let an alert that uses this webhook fire for ## Alert Key ---- Flashduty uses `alert_fire_uuid` (Metoro's `$alert_fire_uuid`, the UUID of one fire instance) as the Alert Key. Metoro's own Rootly integration guide pairs firing and resolved notifications on this same field (identifier `$.metoro_alert_fire_uuid`, state field `resolved`), and states that for alerts with a group by, each group value has its own `$alert_fire_uuid` while `$alert_uuid` is the same for all of them. @@ -74,7 +71,6 @@ Flashduty uses `alert_fire_uuid` (Metoro's `$alert_fire_uuid`, the UUID of one f - Changes to `description`, `value`, and similar fields don't change the Alert Key ## Status and severity ---- | Metoro `$alert_state` | Flashduty status or severity | | :--- | :--- | @@ -84,7 +80,6 @@ Flashduty uses `alert_fire_uuid` (Metoro's `$alert_fire_uuid`, the UUID of one f Metoro alerts have no severity field, so every alert is treated as Warning. An empty or other state value is rejected. To distinguish severity, adjust it with rules in the Flashduty channel. ## Troubleshooting ---- - **Metoro reports a webhook failure (400)**: confirm the Body Template is valid JSON and that `alert_fire_uuid` and `state` are not empty. Metoro escapes variables automatically for JSON requests, so don't add escaping yourself - **404 or 401**: confirm the Push URL is complete and includes `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/mezmo.mdx b/en/on-call/integration/alert-integration/alert-sources/mezmo.mdx index 7dc194f9..6c093d2b 100644 --- a/en/on-call/integration/alert-integration/alert-sources/mezmo.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/mezmo.mdx @@ -13,7 +13,6 @@ Mezmo's own docs say `autoresolve` "only applies to PagerDuty" — the Webhook c
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -34,7 +33,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Mezmo ---- @@ -89,12 +87,10 @@ Click the **Test** link at the top of the Alert panel and confirm Flashduty retu ## Alert Key ---- Mezmo's Webhook Alert request body has no alert id, View id, or dedup key — none of the [12 documented body tokens](https://docs.mezmo.com/docs/webhook-alert-integration#body-tokens) (`name`, `matches`, `lines`, `level`, `url`, `query`, `app`, `host`, `tag`, `line`, `line_objects`, `first_line_object`) is an identifier. The View name and the query it runs are the check's identity across repeated matches — the docs define `query` as "the query of the View to which this alert is attached" — so Flashduty keys on `MD5(view_name, query)`: repeated matches of the same View and query merge into the same alert (the first matched line, match count, level, and other fields changing does not change this key); a different View, or the same View with an edited query, opens its own alert. ## Severity ---- Mezmo's own docs describe `{{ level }}` only as "Severity level (info, warn, error, etc)" — the first matched log line's level — without a full enumeration. Flashduty maps it using the table below; any value not listed, including an empty one (the log line had no parsed level), is treated as **Warning**: @@ -106,7 +102,6 @@ Mezmo's own docs describe `{{ level }}` only as "Severity level (info, warn, err | Empty or any other unrecognized value | Warning | ## Labels ---- | Label | Source | | :--- | :--- | @@ -122,7 +117,6 @@ Mezmo's own docs describe `{{ level }}` only as "Severity level (info, warn, err The alert title is the View name; the description leads with the raw text of the first matched log line (`{{ line }}`), followed by the query. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/microsoft-defender-for-cloud.mdx b/en/on-call/integration/alert-integration/alert-sources/microsoft-defender-for-cloud.mdx index c8dccac6..9bae8a9c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/microsoft-defender-for-cloud.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/microsoft-defender-for-cloud.mdx @@ -11,7 +11,6 @@ If the same tenant already sends Defender for Cloud alerts to Microsoft Sentinel
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the Standard Alert Event integration type** in both, not Microsoft Defender for Cloud. @@ -32,7 +31,6 @@ Get an integration push URL in either of the two ways below. **Choose the Standa
## Configure in Microsoft Defender for Cloud ---- You need the **Security admin** role or **Owner** on the resource group; creating and editing Logic Apps needs **Logic App Contributor**. @@ -54,7 +52,6 @@ You need the **Security admin** role or **Owner** on the resource group; creatin You can also open a single security alert and click **Trigger logic app** to run the Logic App for that alert manually. ## HTTP action ---- Fields of the HTTP action: @@ -107,7 +104,6 @@ In the designer, the same values map to these dynamic contents (outputs of the * | Labels `product_name`, `vendor_name` | Product Name, Vendor Name | `ProductName`, `VendorName` | ## Field mapping ---- | Defender for Cloud field | Flashduty | | :--- | :--- | @@ -119,12 +115,10 @@ In the designer, the same values map to these dynamic contents (outputs of the * | Alert Uri | Label `alert_url`, which opens the alert details in the Azure portal | ## Recovery and deduplication ---- Defender for Cloud workflow automation runs the Logic App only when an alert is created or triggered and sends nothing when the alert is dismissed, so alerts from this integration do not recover automatically. Enable [auto-resolve timeout](/en/on-call/channel/create-edit) on the channel that receives this integration, with a suggested window of 3 days or the time your team usually takes to handle alerts; you can also close alerts manually in Flashduty. ## Troubleshooting ---- - **Flashduty returns `InvalidParameter`**: check that `event_status` is one of the capitalized `Critical`, `Warning`, `Info`, and that `title_rule` is not empty - **The Logic App is missing from the workflow automation list**: the list shows only Consumption Logic Apps that use a Defender for Cloud connector; click **Refresh** after creating it diff --git a/en/on-call/integration/alert-integration/alert-sources/microsoft-sentinel.mdx b/en/on-call/integration/alert-integration/alert-sources/microsoft-sentinel.mdx index 0cef2c21..90b628e5 100644 --- a/en/on-call/integration/alert-integration/alert-sources/microsoft-sentinel.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/microsoft-sentinel.mdx @@ -11,7 +11,6 @@ Sentinel incidents also include alerts from Microsoft security products such as
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the Standard Alert Event integration type** in both, not Microsoft Sentinel. @@ -32,7 +31,6 @@ Get an integration push URL in either of the two ways below. **Choose the Standa
## Configure in Microsoft Sentinel ---- There are two parts: create a Logic App that starts with the **Microsoft Sentinel incident** trigger (called a playbook in Sentinel), then create automation rules that run it. @@ -54,7 +52,6 @@ In Microsoft Sentinel, go to **Configuration** → **Automation** (in the Defend If the playbook appears grayed out in the list, Sentinel has no permission on its resource group: click **Manage playbook permissions**, select the resource group and click **Apply** (this needs the **Owner** role on the resource group). ## HTTP action ---- Fields of the HTTP action: @@ -105,7 +102,6 @@ In the designer, the same values map to these dynamic contents (outputs of the M | Labels `workspace`, `resource_group` | Workspace Name, Resource Group Name | `workspaceInfo.WorkspaceName`, `workspaceInfo.ResourceGroupName` | ## Field mapping ---- | Sentinel field | Flashduty | | :--- | :--- | @@ -117,7 +113,6 @@ In the designer, the same values map to these dynamic contents (outputs of the M | Incident URL and others | Labels of the same name; `incident_url` opens the incident from the alert details | ## Recovery and deduplication ---- - When the incident is closed (**Status** becomes `Closed`), the Logic App sends an event with `event_status` set to `Ok`, and Flashduty closes the alert with the same Alert Key. - Sentinel also fires **When incident is updated** when alerts, comments or tags are added. The update rule above runs only on status or severity changes; if you remove those conditions, every update is pushed, and repeated events with the same Alert Key merge into the original alert. @@ -125,7 +120,6 @@ In the designer, the same values map to these dynamic contents (outputs of the M - An incident that groups several Sentinel alerts is pushed as one Flashduty alert; the title and description come from the incident itself. ## Troubleshooting ---- - **Flashduty returns `InvalidParameter`**: check that `event_status` is one of the four capitalized values and that `title_rule` is not empty - **The HTTP action returns a 4xx about authentication or routing**: the push URL lacks `integration_key`, or it is not the push URL of a Standard Alert Event integration diff --git a/en/on-call/integration/alert-integration/alert-sources/moesif.mdx b/en/on-call/integration/alert-integration/alert-sources/moesif.mdx index 0c8493e1..297b3756 100644 --- a/en/on-call/integration/alert-integration/alert-sources/moesif.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/moesif.mdx @@ -11,7 +11,6 @@ Moesif notifies only when an alert triggers and has no recovery notification, so
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can get the integration push URL in either of the following ways.
## Configure Moesif ---- @@ -65,26 +63,22 @@ The **Notification Throttle** of a channel or rule and **Silencing alerts** stop ## Recovery and auto-close ---- Moesif notifies only when a rule triggers. The request body has no alert ID and no field that marks a recovery, so the alert in Flashduty does not recover on its own. Each Moesif notification is a separate Flashduty alert. Close it by hand, or turn on [auto-close](/en/on-call/channel/create-edit) in the channel that receives this integration. We suggest twice the rule's evaluation period, for example 30 minutes for a 15-minute rule. ## Alert Key ---- The request has no field that identifies the same alert across notifications, so Flashduty generates a random Alert Key for each notification. Different notifications never merge into one alert. ## Status and severity ---- Moesif alerts carry no severity. The alert in Flashduty is always **Warning**; its status equals its severity and it does not recover. A notification whose `type` is not `alert` (for example another kind of notification sent to the same channel) is ignored and creates no alert. ## Alert content ---- - **Title**: the alert rule name `name`. When the notification has a single group value, it is appended, for example `Latency per user: user-1`. Without a rule name the title is `Moesif alert` - **Description**: the rule condition `metric`, then each group value with its current value and, for dynamic alerts, its direction; up to 20 are listed @@ -100,7 +94,6 @@ A notification whose `type` is not `alert` (for example another kind of notifica | `feature_count` | Number of group values, when the notification has more than one | ## Troubleshooting ---- - **Flashduty receives nothing**: check that the rule is on and selects the channel in **Send To**, and that the channel's Webhook URL is the full push URL including `integration_key`. In Moesif **Alert History**, check that the rule triggered and was not suppressed by a throttle or silencing - **Flashduty returns a parameter error**: the body is not JSON, or has neither `name` nor `metric_values`. Use Moesif's built-in webhook channel and do not rewrite the body diff --git a/en/on-call/integration/alert-integration/alert-sources/mongodb-atlas.mdx b/en/on-call/integration/alert-integration/alert-sources/mongodb-atlas.mdx index 93c3cf46..33288d70 100644 --- a/en/on-call/integration/alert-integration/alert-sources/mongodb-atlas.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/mongodb-atlas.mdx @@ -9,7 +9,6 @@ Use the webhook integration of a MongoDB Atlas project to send Atlas alerts to F
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure MongoDB Atlas ---- Configuring the webhook integration requires the `Project Owner` role on the project or the `Organization Owner` role. Editing alert settings requires `Project Owner` or `Project Alerts Manager`. @@ -74,14 +72,12 @@ Atlas requires the webhook URL to be reachable from the internet and to return 2 ## Alert Key ---- Flashduty uses the alert `id` in the request body as the Alert Key. The Atlas documentation defines `id` as the unique identifier of the alert. The open, update, acknowledge, close, and cancel notifications of one alert carry the same `id`, so they land on the same Flashduty alert. Changes to `status`, `currentValue`, `humanReadable`, or the timestamps do not change the Alert Key. Flashduty rejects a request without `id`, because it could not be matched to its recovery. ## Status and severity ---- Atlas sets the alert state in the `X-MMS-Event` request header: @@ -112,7 +108,6 @@ Atlas evaluates host conditions on each node of a replica set, and each node's a An informational alert is a point-in-time event. Each notification carries a new `id`, and Atlas never sends a close notification for it. These alerts do not recover automatically in Flashduty: close them by hand, or turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit). ## Alert content ---- - **Title**: `metricName`, or `eventTypeName` when it is empty, followed by ` on ` when a resource is known, for example `CONNECTIONS on Cluster0` - **Description**: `humanReadable`, which contains the project name, organization name, and alert details @@ -121,7 +116,6 @@ An informational alert is a point-in-time event. Each notification carries a new The acknowledging user `acknowledgingUsername` and the acknowledgement comment are not written to labels. ## Troubleshooting ---- - **The Atlas Activity Feed shows failed deliveries**: check that **Webhook URL** is the full push URL including `integration_key` - **Flashduty returns a parameter error**: check that no **Webhook Body Template** is set and that the body contains `id` diff --git a/en/on-call/integration/alert-integration/alert-sources/monitive.mdx b/en/on-call/integration/alert-integration/alert-sources/monitive.mdx index d5353d0c..09570fc2 100644 --- a/en/on-call/integration/alert-integration/alert-sources/monitive.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/monitive.mdx @@ -9,7 +9,6 @@ Use a Monitive (uptimemonitoring.com) monitor webhook to send down (`monitor.dow
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## In Monitive ---- Monitive webhooks are set per monitor, and each monitor has one webhook slot. Set the webhook on every monitor you want to send to Flashduty. @@ -65,7 +63,6 @@ Every Monitive delivery carries an `X-UptimeMonitoring-Signature` (HMAC-SHA256) ## Payload ---- Monitive POSTs the following fields as `application/json`. Flashduty parses them directly; no template is needed: @@ -82,14 +79,12 @@ Monitive POSTs the following fields as `application/json`. Flashduty parses them The alert title is the monitor name; if it is empty, the monitored URL is used, then `Monitive monitor `. ## Alert Key ---- Flashduty uses `monitor_id` as the Alert Key. Down, flapping, and recovery notifications of one monitor carry the same `monitor_id`, so they land on the same alert; different monitors produce different alerts even when their names and URLs match. Renaming the monitor or changing its URL or reason does not change the Alert Key. `delivery_id` differs for every state change, so it is not part of the Alert Key. A request without `monitor_id` is rejected with a parameter error, because its recovery could not be matched to the original alert. A request whose `event` is none of the three values is acknowledged and ignored without creating an alert. ## Status and severity ---- Monitive notifications carry no severity. A down monitor is an outage signal and maps to Critical; flapping maps to Warning. @@ -100,7 +95,6 @@ Monitive notifications carry no severity. A down monitor is an outage signal and | `monitor.up` | Recovery, keeping the alert's last severity | ## FAQ ---- @@ -123,7 +117,6 @@ Webhooks are included in the free plan, with one webhook per monitor and up to 5 ## Troubleshooting ---- - **Flashduty receives no alert**: query `GET /api/v1/webhook-deliveries?monitor_id=` in Monitive and check the delivery status and response code - **Flashduty returns a parameter error**: confirm the body is Monitive's JSON and `monitor_id` is not empty diff --git a/en/on-call/integration/alert-integration/alert-sources/monte-carlo.mdx b/en/on-call/integration/alert-integration/alert-sources/monte-carlo.mdx index 9b2a3bf7..edc65845 100644 --- a/en/on-call/integration/alert-integration/alert-sources/monte-carlo.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/monte-carlo.mdx @@ -9,7 +9,6 @@ Use Monte Carlo's Webhook notification channel to send custom-rule breaches and
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Monte Carlo ---- @@ -61,12 +59,10 @@ Monte Carlo's official docs don't publish a webhook connectivity test button, an ## Alert Key ---- Flashduty uses `payload.incident_id` as the Alert Key. Both example payloads in Monte Carlo's official docs (custom rule breach, volume anomaly) carry this field, and `payload.url` in the same payload is always `https://getmontecarlo.com/incidents/` — the address Monte Carlo's own console uses to locate that incident — which is how the docs imply this field stays the same throughout the incident's lifecycle. A request missing `incident_id` is rejected. ## Status and severity ---- Alert status is decided by `payload.alert_feedback`: it recovers when the value is `fixed`, `expected`, `no_action_needed`, or `false_positive`, and stays active for every other value (`investigating`, `no_status`, `work_in_progress`, and so on). @@ -81,7 +77,6 @@ Alert severity is decided by `payload.declared_alert_severity`, which only appea | Empty or never declared (the default) | Warning | ## Labels ---- | Label | Source | | :--- | :--- | @@ -100,7 +95,6 @@ Alert severity is decided by `payload.declared_alert_severity`, which only appea Monte Carlo's official docs describe the audience owner field as an email address; Flashduty does not write email addresses into labels, for privacy. ## Troubleshooting ---- - **Monte Carlo reports the webhook call failed**: confirm the push URL is complete and includes `integration_key` - **Flashduty returns a parameter error**: confirm the audience is configured as a Webhook channel, and that Monte Carlo isn't sending a custom payload — Flashduty only parses the official fixed format diff --git a/en/on-call/integration/alert-integration/alert-sources/nagios.mdx b/en/on-call/integration/alert-integration/alert-sources/nagios.mdx index c30da774..effc314e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/nagios.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/nagios.mdx @@ -7,7 +7,6 @@ keywords: ["alert integration", "Nagios alert events", "monitoring alerts", "dat
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -42,7 +41,6 @@ Choose this method when you need to route alerts to different channels based on
## In Nagios ----
@@ -217,7 +215,6 @@ systemctl restart nagios
## Status Mapping ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/netbeez.mdx b/en/on-call/integration/alert-integration/alert-sources/netbeez.mdx index 1efa7119..23c8322a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/netbeez.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/netbeez.mdx @@ -9,7 +9,6 @@ Use the NetBeez webhook integration to send network monitoring alerts and incide
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure NetBeez ---- @@ -60,7 +58,6 @@ Make a Target or Agent fail (for example, temporarily disable an Agent), confirm ## Payload fields ---- NetBeez POSTs `application/json` with a single `data` field: an object for a single notification, an array for an aggregate notification. Flashduty parses it directly, so no template is needed. @@ -81,7 +78,6 @@ NetBeez POSTs `application/json` with a single `data` field: an object for a sin The alert title is "object name: message". The object name is the first non-empty of `target`, `wifi_profile`, `agent` and `destination`. ## Alert Key ---- - Alert notifications use `alert_dedup_id`. NetBeez documents that the open and cleared notifications of one alert share it, so grouping by it is enough. - Incident notifications use the object type, the object ID and `incident_ts`. `incident_ts` is always the incident start time and is the same in the open and cleared notifications. NetBeez also suggests correlating incidents by `incident_id`, but the cleared example in its documentation carries a different `incident_id` from the open one, so Flashduty does not depend on it and keeps `incident_id` only as a label. @@ -90,7 +86,6 @@ The alert title is "object name: message". The object name is the first non-empt If an alert notification has no `alert_dedup_id`, or an incident notification has no object ID or `incident_ts`, Flashduty returns a parameter error because the cleared notification could not be matched to its alert reliably. ## Status and severity ---- | NetBeez notification | Flashduty status or severity | | :--- | :--- | @@ -103,7 +98,6 @@ If an alert notification has no `alert_dedup_id`, or an incident notification ha NetBeez documents only that open alerts have a `severity` of at most 5 with names such as `alert` and `critical`, and does not publish a full table, so only 1 and 2 map to Critical. To change a severity, rewrite it with a rule under the channel's **Configuration**. ## FAQ ---- @@ -126,7 +120,6 @@ No. NetBeez retries on non-2xx responses, the Alert Key of an event does not cha ## Troubleshooting ---- - **NetBeez fails to deliver**: confirm the webhook URL is the full push URL and includes `integration_key` - **Flashduty returns a parameter error**: confirm the body has `data`, alerts carry `alert_dedup_id`, and incidents carry an object ID and `incident_ts` diff --git a/en/on-call/integration/alert-integration/alert-sources/netdata.mdx b/en/on-call/integration/alert-integration/alert-sources/netdata.mdx index 711e8eff..535912e1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/netdata.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/netdata.mdx @@ -11,7 +11,6 @@ This integration works with the open-source Netdata Agent, including Docker depl
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -48,14 +47,12 @@ Choose this method when you need to route alerts to different channels based on
## Prerequisites ---- - **Network**: the host running the Netdata Agent must be able to reach the Flashduty push URL (for example `https://api.flashcat.cloud`). - **curl**: the notification script sends requests with `curl`. The official Netdata packages and Docker image already include it. - **Permissions**: you need to be able to edit files in the Netdata configuration directory (usually `/etc/netdata`). ## In Netdata ---- @@ -148,7 +145,6 @@ The test command sends WARNING, CRITICAL, and CLEAR notifications in turn. When ## Alert Key ---- Flashduty builds the Alert Key from the `host`, `chart`, and `alarm` fields. @@ -161,7 +157,6 @@ Changes to the alert status, value, description, or duration do not change the A The `alarm_id` in Netdata notifications is unique only within one Agent (the test command, for example, sends `alarm_id` `1` on every Agent), so Flashduty does not use it. ## Status and severity ---- Netdata sends notifications only for the WARNING, CRITICAL, and CLEAR states. @@ -176,7 +171,6 @@ When an alert rises from WARNING to CRITICAL, Flashduty opens a new Critical ale Netdata sends CLEAR only when an alert changes from WARNING or CRITICAL to CLEAR. ## Labels ---- | Label | Source | | :--- | :--- | @@ -193,7 +187,6 @@ Netdata sends CLEAR only when an alert changes from WARNING or CRITICAL to CLEAR The alert title is `: `. Older Netdata versions that do not send `summary` use the alert name instead. ## FAQ ---- diff --git a/en/on-call/integration/alert-integration/alert-sources/new-relic.mdx b/en/on-call/integration/alert-integration/alert-sources/new-relic.mdx index 2d5e8967..61fd4e55 100644 --- a/en/on-call/integration/alert-integration/alert-sources/new-relic.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/new-relic.mdx @@ -9,14 +9,12 @@ Use a New Relic Workflow webhook to send Issues to Flashduty On-call. One New Re
## In Flashduty On-call ---- Create either a dedicated or shared **New Relic** alert integration and copy its complete Push URL.
## Configure New Relic ---- @@ -68,14 +66,12 @@ Open a real Issue and confirm an active Flashduty alert. Change its priority or ## Alert Key and Issue merges ---- Flashduty uses `issue_id` (`issueId`) directly as the Alert Key. Titles, priorities, policies, conditions, entities, and `incident_ids` do not affect it. `incident_ids` is the list of Alert Events aggregated into the Issue and is stored only as context. For `trigger_event=MERGE_REQUEST`, Flashduty updates the surviving Issue identified by the payload's `issue_id`. This version does not invoke Flashduty's internal alert merge operation or infer and close a source Issue. ## Status and severity ---- | New Relic value | Flashduty status or severity | | :--- | :--- | @@ -89,7 +85,6 @@ For `trigger_event=MERGE_REQUEST`, Flashduty updates the surviving Issue identif New Relic warning thresholds create `HIGH` priority Alert Events, so `HIGH` maps to Flashduty Warning. Use an [Alert Processing Pipeline](/en/on-call/integration/alert-integration/alert-pipelines) for a different mapping. ## Add custom labels ---- Add a top-level `custom_labels` object to send more Workflow variables: diff --git a/en/on-call/integration/alert-integration/alert-sources/nobl9.mdx b/en/on-call/integration/alert-integration/alert-sources/nobl9.mdx index 678bf86c..71bc3155 100644 --- a/en/on-call/integration/alert-integration/alert-sources/nobl9.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/nobl9.mdx @@ -9,7 +9,6 @@ Use the Nobl9 Webhook alert method to sync alerts fired by SLO alert policies to
## In Flashduty On-call ---- Get the integration push URL in either of two ways. @@ -30,7 +29,6 @@ Get the integration push URL in either of two ways.
## Configure in Nobl9 ---- @@ -77,7 +75,6 @@ Use the template above. Nobl9's default fields do not include `alert_id`, and Fl ## Payload ---- | Field | Meaning | In Flashduty | | :--- | :--- | :--- | @@ -89,12 +86,10 @@ Use the template above. Nobl9's default fields do not include `alert_id`, and Fl | `alert_policy_conditions_text`, `slo_details_link` | Trigger conditions, SLO details link | Description | ## Alert Key ---- Flashduty uses `alert_id` (Nobl9 docs: "Unique identifier of the alert") as the Alert Key. Repeated deliveries for the same Nobl9 alert merge into one Flashduty alert. ## Severity ---- | Nobl9 `severity` | Flashduty severity | | :--- | :--- | @@ -104,7 +99,6 @@ Flashduty uses `alert_id` (Nobl9 docs: "Unique identifier of the alert") as the | Other or empty | Warning | ## FAQ ---- @@ -115,7 +109,6 @@ No. The Nobl9 Webhook documentation has no recovery notification. Enable auto-cl ## Troubleshooting ---- - **Nobl9 test fails**: a test request without `alert_id` is rejected, which is expected; otherwise confirm the URL is the full push URL starting with `https://` and includes `integration_key` - **Flashduty returns a parameter error**: confirm the template contains `"alert_id": "$alert_id"` diff --git a/en/on-call/integration/alert-integration/alert-sources/nodeping.mdx b/en/on-call/integration/alert-integration/alert-sources/nodeping.mdx index a7043fd4..10063e04 100644 --- a/en/on-call/integration/alert-integration/alert-sources/nodeping.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/nodeping.mdx @@ -9,7 +9,6 @@ Use a webhook contact method on a NodePing contact to send check down (`down`) a
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure NodePing ---- @@ -65,7 +63,6 @@ Keep the request method at **GET** and do not add custom Query Strings or a Body ## Payload ---- NodePing sends a GET request with the following fields appended to the push URL's query string. Flashduty parses them directly, with no template to configure: @@ -86,14 +83,12 @@ NodePing sends a GET request with the following fields appended to the push URL' The alert title is the check name. If the name is empty, Flashduty uses the check target, then `NodePing check `. ## Alert Key ---- Flashduty uses the check `uuid` as the Alert Key. Down and up notifications for the same check carry the same `uuid`, so they land on the same alert. Different checks produce different alerts even when their names and targets are the same. Changing the check name, target, or result code does not change the Alert Key. `_id` identifies a single check result and changes on every notification, so it is not used to correlate alerts. A request without `uuid` is rejected with a parameter error, because its recovery could not be matched to the original alert reliably. ## Status and severity ---- NodePing notifications have no severity, so Flashduty treats them all as Critical. @@ -106,7 +101,6 @@ NodePing notifications have no severity, so Flashduty treats them all as Critica `first` means monitoring has started and this webhook is registered as a notification target. It does not describe an outage, so Flashduty only returns success. Requests whose `event` is empty or has any other value are rejected, so that a request with an unknown state never enters the wrong alert lifecycle. ## FAQ ---- @@ -129,7 +123,6 @@ Confirm that the check is enabled, the webhook contact method is not muted, and ## Troubleshooting ---- - **NodePing fails to deliver**: Confirm that the URL is the complete push URL including `integration_key`, and that the request method is GET - **Flashduty returns a parameter error**: Confirm that no custom Query Strings or Body are set, and that `uuid` and `event` are present diff --git a/en/on-call/integration/alert-integration/alert-sources/ns1.mdx b/en/on-call/integration/alert-integration/alert-sources/ns1.mdx index fc1bf66a..eb7b3dfa 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ns1.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ns1.mdx @@ -9,14 +9,12 @@ Use an NS1 Connect webhook notifier to send monitoring job `down` and `up` state
## In Flashduty On-call ---- Create either a dedicated or shared **NS1** alert integration and copy its complete Push URL.
## Configure NS1 Connect ---- @@ -49,7 +47,6 @@ Make the monitored endpoint genuinely unreachable and confirm Flashduty receives ## Alert Key ---- Flashduty uses the monitoring job ID, `job_document.id`, as the Alert Key. NS1's official example of the `down` body carries the full `job_document`, whose `id` is the job ID. The down, repeated, and up notifications of one job share it. @@ -62,7 +59,6 @@ NS1's official documentation shows the full `down` body only; its `up` example i ## State and severity ---- NS1 sends no severity. @@ -75,12 +71,10 @@ NS1 sends no severity. `state` is case-insensitive. ## Labels ---- Flashduty keeps the labels `check` (job name), `resource` (`host`, `url`, or `domain` from `config`), `job_id`, `job_type`, `region`, `state`, and `notify_list` for troubleshooting and routing on the alert page. ## Troubleshooting ---- - **The alert does not recover**: confirm **Notify failback** is enabled on the monitoring job. If you cannot enable it, turn on [auto-close timeout](/en/on-call/channel/create-edit) for the channel with a duration of 1 hour and the timer starting at incident trigger - **NS1 reports a webhook failure**: confirm the Push URL is complete and includes `integration_key` diff --git a/en/on-call/integration/alert-integration/alert-sources/ntopng.mdx b/en/on-call/integration/alert-integration/alert-sources/ntopng.mdx index 3d2f50ec..0b34c61c 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ntopng.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ntopng.mdx @@ -9,7 +9,6 @@ Use an ntopng Webhook endpoint to send ntopng alerts to Flashduty On-call. For h
## In Flashduty On-call ---- Create either a dedicated or shared **ntopng** alert integration and copy its complete Push URL. @@ -30,7 +29,6 @@ Create either a dedicated or shared **ntopng** alert integration and copy its co
## In ntopng ---- @@ -61,7 +59,6 @@ Trigger a host alert (for example, let a host breach one of ntopng's threshold c ## Alert Key ---- The `engage` and `release` messages for one alert carry the same interface ID (`ifid`), entity type (`entity_id`), entity value (`entity_val`), alert type (`alert_id`), and subtype (`subtype`). Flashduty builds the Alert Key from these five fields. ntopng itself tells engaged alerts apart by entity value, alert type, and subtype. The score (`score`), timestamps, host name, and check period change between messages and are not part of the Alert Key. @@ -70,7 +67,6 @@ A flow alert has `action` set to `store` and each one becomes its own alert. Whe If an `engage` or `release` message lacks `alert_id`, `entity_id`, or `entity_val`, Flashduty returns a parameter error that names the field. ## Severity ---- ntopng derives severity from `score`; Flashduty maps it as follows. A missing or non-numeric `score` is treated as Info. @@ -81,7 +77,6 @@ ntopng derives severity from `score`; Flashduty maps it as follows. A missing or | Below 50 | None, Info, Notice | Info | ## Recovery and testing ---- - **`release`**: closes the alert with the same Alert Key and keeps the severity it had before the release. - **`store` (flow alerts) and any alert without a release message**: does not recover on its own. Turn on [auto-close](/en/on-call/channel/create-edit) in the integration or channel, with a suggested duration of 24 hours. @@ -90,7 +85,6 @@ ntopng derives severity from `score`; Flashduty maps it as follows. A missing or A request carries at most 10 alerts (ntopng's per-request limit). Flashduty creates one event per alert and keeps the order of the request. ## Troubleshooting ---- - **ntopng reports a delivery failure**: confirm the webhook URL is complete, includes `integration_key`, and that the ntopng server can reach `api.flashcat.cloud`. ntopng retries a failed delivery 3 times - **Flashduty returns a parameter error**: check that the body is JSON and that every `engage` and `release` alert has `alert_id`, `entity_id`, and `entity_val` diff --git a/en/on-call/integration/alert-integration/alert-sources/nut.mdx b/en/on-call/integration/alert-integration/alert-sources/nut.mdx index 70a17aac..bba27824 100644 --- a/en/on-call/integration/alert-integration/alert-sources/nut.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/nut.mdx @@ -9,7 +9,6 @@ The NUT (Network UPS Tools) `upsmon` daemon can run the script set by `NOTIFYCMD
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the Standard Alert Event integration type** in both, not NUT. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Standa
## Configure in NUT ---- ### Step 1: Create the notification script @@ -120,7 +118,6 @@ NOTIFYTYPE=ONLINE UPSNAME=ups@localhost /usr/local/bin/nut-flashduty.sh "UPS ups In Flashduty you should first see the alert `UPS ups@localhost: on battery` and then see it recover. ## Recovery and deduplication ---- - `ONBATT`, `LOWBATT` and `ONLINE` share the Alert Key `nut::power`: `ONBATT` triggers the alert, a following `LOWBATT` raises it to Critical, and `ONLINE` recovers it - `COMMBAD`, `NOCOMM` and `COMMOK` share `comm`; `ALARM` and `NOTALARM`, `OVER` and `NOTOVER`, and `BYPASS` and `NOTBYPASS` are also paired @@ -128,7 +125,6 @@ In Flashduty you should first see the alert `UPS ups@localhost: on battery` and - Alerts of several UPS units do not affect each other: the Alert Key contains `UPSNAME` ## Troubleshooting ---- - **No alert arrives**: confirm the `NOTIFYFLAG` of the event type in `upsmon.conf` includes `EXEC` and that `upsmon -c reload` was run - **The script works by hand but no alert arrives when upsmon triggers it**: `NOTIFYCMD` must be the full path of the script and the user `upsmon` runs as must be able to execute it; `curl -fsS` prints failures to stderr, which `upsmon` may not record, so run the script by hand to see them diff --git a/en/on-call/integration/alert-integration/alert-sources/obkio.mdx b/en/on-call/integration/alert-integration/alert-sources/obkio.mdx index 4d0329f6..975a5584 100644 --- a/en/on-call/integration/alert-integration/alert-sources/obkio.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/obkio.mdx @@ -9,7 +9,6 @@ Use the organization-level webhook notification of Obkio to send network monitor
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## In Obkio ---- The webhook is configured at the organization level and requires permission to change the organization's advanced parameters. @@ -63,14 +61,12 @@ The Obkio documentation describes no test delivery. Flashduty only handles deliv ## Alert Key ---- Flashduty uses `data.alert_id` from the webhook as the Alert Key. Obkio's example lists `alert_id` (the alert) separately from `notification_id` (this notification); the notification ID differs on every delivery, so it is not part of the Alert Key. The Obkio documentation does not say whether `alert_id` stays the same across notifications for one alert. If it changes, each notification becomes its own alert and auto-close cleans them up. Changes to the event type, severity, or description never change the Alert Key. A delivery without `data.alert_id` is rejected. ## Status and severity ---- Flashduty sets the severity from `data.severity` (the Obkio levels, see [Notifications](https://obkio.com/docs/notifications/)): @@ -86,7 +82,6 @@ Flashduty sets the severity from `data.severity` (the Obkio levels, see [Notific The Obkio documentation does not say whether the `ok` level is ever sent. If it is, the alert with that `alert_id` recovers. ## Labels ---- | Label | Source | | :--- | :--- | @@ -101,7 +96,6 @@ The Obkio documentation does not say whether the `ok` level is ever sent. If it The title comes from `event_description`, such as `High latency: 118.32 ms`. ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: the message names the missing field (`data.alert_id`). Check that Webhook Type is `Obkio` - **Obkio keeps retrying**: confirm the URL is complete and includes `integration_key`; Obkio stops retrying once it gets a 2xx response diff --git a/en/on-call/integration/alert-integration/alert-sources/observium.mdx b/en/on-call/integration/alert-integration/alert-sources/observium.mdx index a1c49163..a39f7277 100644 --- a/en/on-call/integration/alert-integration/alert-sources/observium.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/observium.mdx @@ -9,7 +9,6 @@ Observium pushes alerts through a contact of type **Webhook JSON**: every time a
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Observium ---- The **Webhook JSON** transport ships with the Observium Community Edition; no subscription is needed. Screen names below follow Observium CE 26.1. @@ -125,7 +123,6 @@ Then make a checker fire for real (for example, make a monitored device unreacha ## Alert Key ---- Flashduty uses `ALERT_ID` as the Alert Key for alert checker alerts. `ALERT_ID` is the row ID in the Observium `alert_table` table, which holds exactly one row per alert checker and entity, and every alert, reminder, and recovery notification carries the same value. So notifications for the same checker on the same entity land on one alert, and a new failure after recovery opens a new alert. @@ -136,7 +133,6 @@ For syslog alerts, `ALERT_ID` is the syslog rule ID and no recovery is ever sent Flashduty rejects requests without `ALERT_STATE` or `ALERT_ID`, or whose `ALERT_STATE` is not a value in the table below. ## Alert lifecycle ---- Flashduty handles notifications by the `ALERT_STATE` field: @@ -150,7 +146,6 @@ Flashduty handles notifications by the `ALERT_STATE` field: `ALERT_STATE` carries Observium's fixed state names and is not affected by `$config['alerts']['status_name']`. Custom names appear in `ALERT_STATE_NAME`, which Flashduty does not read. ## Severity ---- The severity comes from `ALERT_SEVERITY`: @@ -164,7 +159,6 @@ The severity comes from `ALERT_SEVERITY`: For alert checkers the severity is the checker's **Severity** (`Critical` or `Warning`); for syslog alerts it is the syslog priority of the log line. Recovery notifications carry the same checker severity, and the recovery event keeps it. ## Alert content ---- - **Title**: ` on `. When the entity is not the device itself (for example a port or a sensor), `()` is appended. When the checker message is empty, `Observium alert ` is used instead - **Description**: `CONDITIONS` (the failed conditions), `METRICS` (current metric values), and `DURATION`, one per line @@ -173,7 +167,6 @@ For alert checkers the severity is the checker's **Severity** (`Critical` or `Wa Empty fields and `%TAG%` placeholders left unreplaced by the template (such as `ENTITY_*` in syslog notifications) are not written to labels. ## Troubleshooting ---- - **Observium records notifications as failed and Flashduty receives duplicate events**: the contact's **Transport** is **Webhook**. Change it to **Webhook JSON** - **Flashduty returns 400 with `ALERT_STATE is required` or `ALERT_ID is required`**: the contact's JSON template lacks that field. Restore the default template diff --git a/en/on-call/integration/alert-integration/alert-sources/oceanbase.mdx b/en/on-call/integration/alert-integration/alert-sources/oceanbase.mdx index dac8d8ae..d931009e 100644 --- a/en/on-call/integration/alert-integration/alert-sources/oceanbase.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/oceanbase.mdx @@ -8,7 +8,6 @@ Sync OceanBase alert events to Flashduty via webhook for automated alert noise r
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In OceanBase ----
diff --git a/en/on-call/integration/alert-integration/alert-sources/oci-monitoring.mdx b/en/on-call/integration/alert-integration/alert-sources/oci-monitoring.mdx index 9065c322..b1f78f1a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/oci-monitoring.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/oci-monitoring.mdx @@ -9,7 +9,6 @@ Use an HTTPS (Custom URL) subscription on an OCI Notifications topic to send Ora
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -34,7 +33,6 @@ OCI HTTPS subscription URLs cannot contain query parameters, so this integration ## Configure OCI ---- @@ -75,14 +73,12 @@ OCI HTTPS subscription URLs cannot contain query parameters, so this integration ## Alert Key ---- Flashduty uses the `dedupeKey` of the alarm message as the Alert Key. OCI defines `dedupeKey` as the unique identifier of the alarm (grouped message) or of the metric stream in the alarm (split message), and says to use it to group messages that belong to the same alarm. The `OK_TO_FIRING`, `REPEAT`, `FIRING_TO_OK`, and `RESET` messages of one alarm carry the same `dedupeKey`, so they update the same Flashduty alert. Changes to the title, body, severity, time, or metric values do not change the Alert Key. An alarm message without a `dedupeKey` is rejected. ## Status and severity ---- | OCI `type` | Flashduty status | | :--- | :--- | @@ -101,7 +97,6 @@ Changes to the title, body, severity, time, or metric values do not change the A A recovery keeps the alert's severity. An empty or unknown `severity` is treated as Warning; an unknown `type` is rejected. ## Alert labels ---- Flashduty writes the following fields to alert labels for routing and troubleshooting: @@ -112,7 +107,6 @@ Flashduty writes the following fields to alert labels for routing and troublesho The alarm `body` and `alarmSummary` go into the alert description. ## Troubleshooting ---- - **The subscription stays Pending**: Check that the URL is the complete push URL, with the integration key in the path and no query parameters. Then delete the subscription and create it again with the correct URL. A confirmation link is valid for 3 days; after it expires, recreate the subscription as well - **Flashduty returns a ConfirmationURL error**: Flashduty only visits https confirmation links on Oracle Cloud domains such as `oraclecloud.com`. Make sure the request comes from OCI Notifications diff --git a/en/on-call/integration/alert-integration/alert-sources/odown.mdx b/en/on-call/integration/alert-integration/alert-sources/odown.mdx index 8c629846..5713cac6 100644 --- a/en/on-call/integration/alert-integration/alert-sources/odown.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/odown.mdx @@ -9,7 +9,6 @@ Use an Odown webhook channel to send check down (`ALERT_FAILURE`), recovery (`AL
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Odown ---- @@ -57,7 +55,6 @@ Let a check actually fail (for example, point it at an unreachable address tempo ## Payload ---- Odown POSTs each event as JSON. Flashduty parses it directly, so no template is needed: @@ -78,7 +75,6 @@ Odown POSTs each event as JSON. Flashduty parses it directly, so no template is The alert title is the check name, or the monitored URL when the name is empty. SSL expiry alert titles start with `SSL certificate expiring:`. ## Alert Key ---- - Down and recovery: Flashduty uses `check.id` as the Alert Key. `ALERT_FAILURE` and `ALERT_RECOVERY` for the same check carry the same `check.id`, so they land on one alert, while different checks produce different alerts. Renaming a check or a change in status code or run location does not change the Alert Key. - SSL expiry: the Alert Key is `check.id` plus `:ssl_expiry`. It is separate from the check's down alert, so a recovery does not close the certificate alert, and repeated expiry notices for one check merge into one alert. @@ -86,7 +82,6 @@ The alert title is the check name, or the monitored URL when the name is empty. A request without `check.id` is rejected with a parameter error, because a recovery could not be matched to its alert. ## Status and severity ---- Odown notifications carry no severity. @@ -99,12 +94,10 @@ Odown notifications carry no severity. A request with an empty or unknown `event` is rejected, so a request whose state is unclear never lands in the wrong alert lifecycle. ## Turn on the auto-resolve timeout for one-shot alerts ---- An SSL expiry notice has no matching close notification, so these alerts do not recover automatically in Flashduty. Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) and set it to 7 days, or close the alert by hand after you renew the certificate. ## FAQ ---- @@ -121,7 +114,6 @@ No. Notifications for one check carry the same `check.id` and merge into one ale ## Troubleshooting ---- - **Odown reports a failed delivery**: check that the webhook URL is the complete push URL and includes `integration_key` - **Flashduty returns a parameter error**: check that the request is an Odown JSON notification with non-empty `check.id` and `event` diff --git a/en/on-call/integration/alert-integration/alert-sources/ofelia.mdx b/en/on-call/integration/alert-integration/alert-sources/ofelia.mdx index 3fc31dca..8d7322a4 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ofelia.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ofelia.mdx @@ -11,7 +11,6 @@ This page covers the webhook feature of [netresearch/ofelia](https://github.com/
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Ofelia ---- Ofelia talks to the Docker API even when it only runs `job-local` jobs, so the Ofelia container must mount `/var/run/docker.sock`; without it Ofelia exits at startup. With `docker run`, add `-v /var/run/docker.sock:/var/run/docker.sock:ro`. @@ -101,7 +99,6 @@ Make a job fail once (for example, temporarily change its command to `false`) an ## Alert Key ---- Flashduty builds the Alert Key from `host.hostname` and `job.name`, joined by a separator that cannot appear in either, then hashed with MD5. In our verification, failed and successful runs of the same job carried the same hostname and job name. `execution.id` differs on every run, so it is not part of the Alert Key. @@ -111,7 +108,6 @@ Flashduty builds the Alert Key from `host.hostname` and `job.name`, joined by a - If `job.name` is missing, Flashduty returns 400 rather than writing a failure and its recovery to the wrong alert ## Status and severity ---- | Ofelia `execution.status` | Flashduty handling | | :--- | :--- | @@ -124,7 +120,6 @@ A job skipped by `no-overlap` means the previous run is still going, so the job' Repeated failures update the same alert. If a job stops running altogether (deleted or disabled), its alert does not recover. Close it manually, or turn on [auto-close after timeout](/en/on-call/channel/create-edit) for the channel. ## Alert content ---- - **Title**: `Ofelia job "" failed`, or `Ofelia job "" succeeded` on recovery - **Description**: `execution.error`, followed by `execution.stderr` on a new line @@ -133,7 +128,6 @@ Repeated failures update the same alert. If a job stops running altogether (dele The job command and stdout never reach labels or the description, because a command can carry credentials. ## Troubleshooting ---- - **Flashduty receives nothing**: confirm the job has `webhooks = flashduty` and look for `Webhook error` in the Ofelia log. Ofelia retries a failed webhook 3 times by default, 5 seconds apart - **Failures arrive but never recover**: confirm the webhook has `trigger = always` and that the hostname did not change between runs diff --git a/en/on-call/integration/alert-integration/alert-sources/ohdear.mdx b/en/on-call/integration/alert-integration/alert-sources/ohdear.mdx index 26123e69..c95cefc5 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ohdear.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ohdear.mdx @@ -9,7 +9,6 @@ Use the webhook in your Oh Dear team settings to send uptime, performance, broke
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure Oh Dear ---- The Oh Dear webhook is configured per team, and events from every monitor in the team go to the same URL. @@ -56,7 +54,6 @@ Oh Dear treats only HTTP 200 as delivered. Any other status, including a 301 or ## How events map to alerts ---- Oh Dear pushes every event, and you cannot filter event types on the Oh Dear side. Flashduty handles them as follows: @@ -84,7 +81,6 @@ Monitor added (`monitorAddedNotification`) and any event type Oh Dear adds later ## Alert Key ---- - Checks with a recovery event: the Alert Key is computed from `run.check_id` (the ID of one kind of check under a monitor in Oh Dear). The trigger and recovery events of one check share an Alert Key, and different monitors, or different checks of the same monitor, never merge - Events without a recovery event: the Alert Key is computed from the event's `uuid`. Oh Dear keeps the same `uuid` when it retries an event, so a retry does not create a duplicate alert, while each new event creates its own alert @@ -92,7 +88,6 @@ Monitor added (`monitorAddedNotification`) and any event type Oh Dear adds later Changes to the monitor name, URL, time, or run ID do not change the Alert Key. A push without `run.check_id` (checks with a recovery event) or without `uuid` (events without one) is rejected. ## Status and severity ---- Oh Dear events carry no severity, so Flashduty decides by event: @@ -105,7 +100,6 @@ Oh Dear events carry no severity, so Flashduty decides by event: An uptime `...UptimeCheckRecovered` event with `run.result` set to `warning` means partial connectivity (the primary checker failed, the secondary succeeded, and the site still counts as online). Flashduty treats it as a recovery too. ## Labels ---- | Label | Source | | :--- | :--- | @@ -118,7 +112,6 @@ An uptime `...UptimeCheckRecovered` event with `run.result` set to `warning` mea | `url` | Link to the matching report in Oh Dear | ## Troubleshooting ---- - **No alerts arrive**: check that `integration_key` in the URL is correct, and look at the request's response status in Oh Dear's webhook log - **An alert does not recover**: check that Oh Dear has sent the matching recovery event. Certificate expiry, DNS record changes, and scheduled task events have none and must be closed manually diff --git a/en/on-call/integration/alert-integration/alert-sources/okta.mdx b/en/on-call/integration/alert-integration/alert-sources/okta.mdx index 046a2a7e..fce80cdb 100644 --- a/en/on-call/integration/alert-integration/alert-sources/okta.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/okta.mdx @@ -14,7 +14,6 @@ Only super administrators can create and configure event hooks, and each Okta or
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -35,7 +34,6 @@ You can get the integration push URL in either of the following ways.
## Configure Okta ---- @@ -87,14 +85,12 @@ Preview sends real events from your org's System Log, and Flashduty cannot tell ## Configure auto-resolve timeout ---- Breached credential and suspicious activity alerts have no recovery notification and never close on their own. In the channel that receives these alerts, turn on the [auto-resolve timeout](/en/on-call/channel/create-edit), set **Window timing start** to **Incident trigger**, and set the timeout to 24 hours: responders get one working day to confirm and reset the credential, and unhandled incidents do not stay open indefinitely. Account lockout alerts are closed by unlock events and do not depend on this setting. ## Payload fields ---- The `data.events` array in one delivery may carry several events. Flashduty processes them one by one in order of each event's `published` time. Each event is an Okta System Log record, and Flashduty uses the following fields: @@ -112,7 +108,6 @@ The `data.events` array in one delivery may carry several events. Flashduty proc The alert title has the form `: `, for example `Okta account locked: Jane Doe`. Every alert also carries the label `source=okta`. ## Alert Key ---- Flashduty builds the Alert Key from the event category and the user ID: @@ -122,7 +117,6 @@ Flashduty builds the Alert Key from the event category and the user ID: - A new breached credential or suspicious activity event for a user whose alert is still open merges into that alert ## Status and severity ---- The `severity` that Okta records does not reflect urgency (an account lockout is recorded as `DEBUG`, for example), so Flashduty maps severity by event type: @@ -135,7 +129,6 @@ The `severity` that Okta records does not reflect urgency (an account lockout is | Other event types | Ignored; no alert | ## FAQ ---- @@ -158,7 +151,6 @@ Okta times out after 3 seconds and retries at most once on a 5xx response or a t ## Troubleshooting ---- - **Verify fails**: make sure the URL is the full push URL, including `integration_key` - **Flashduty returns an invalid parameter error**: an event that should create an alert has no user (neither `target` nor `actor` contains an object of type `User`). This usually happens with sample data in Preview diff --git a/en/on-call/integration/alert-integration/alert-sources/open-falcon.mdx b/en/on-call/integration/alert-integration/alert-sources/open-falcon.mdx index 8f785ba5..35dd248a 100644 --- a/en/on-call/integration/alert-integration/alert-sources/open-falcon.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/open-falcon.mdx @@ -8,7 +8,6 @@ Sync Open-Falcon alert events to Flashduty via webhook to achieve automated aler
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this option when you need to route alerts to different channels based on
## In Falcon ---- Configure webhooks for each alert rule.
@@ -64,7 +62,6 @@ Similarly, you can configure the same push URL for Expressions alert rules.
## Status Mapping ----
Open-Falcon to Flashduty alert severity mapping: diff --git a/en/on-call/integration/alert-integration/alert-sources/opennms.mdx b/en/on-call/integration/alert-integration/alert-sources/opennms.mdx index d82f32e3..45f06a47 100644 --- a/en/on-call/integration/alert-integration/alert-sources/opennms.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/opennms.mdx @@ -9,7 +9,6 @@ OpenNMS Horizon uses notices to tell operators about events in the network. This
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure OpenNMS ---- This integration uses the OpenNMS webhook notification strategy `WebhookNotificationStrategy`, which requires **OpenNMS Horizon 36.0.3 or later**. Earlier versions do not have this strategy, so upgrade first. Below, `$OPENNMS_HOME` is the OpenNMS installation directory, `/opt/opennms` in the official container image. The OpenNMS server must be able to reach the Flashduty push URL. @@ -149,7 +147,6 @@ OpenNMS has no button to test a notification command on its own. ## Alert Key ---- Flashduty uses the OpenNMS notice ID `notice_id` (`${noticeid}`) as the Alert Key. The notice ID stays the same when an escalation step resends the notice and when OpenNMS sends the resolution notice after a recovery event auto-acknowledges it, so all of these land on the same alert. @@ -160,7 +157,6 @@ Notice IDs are unique only within one OpenNMS instance. Use a separate integrati Flashduty rejects a request that lacks `notice_id`, and OpenNMS logs the failed push in `notifd.log`. ## Alert lifecycle ---- OpenNMS configures auto-acknowledgement (`auto-acknowledge`) for outage events in `notifd-configuration.xml`: when the recovery event arrives, OpenNMS acknowledges the matching outage notice and sends the original notice again to its original recipients, with `RESOLVED: ` in front of the subject and text. Flashduty checks whether the subject starts with `RESOLVED:`: @@ -183,7 +179,6 @@ To push other notices that have no auto-acknowledgement (for example, threshold When the event's alarm is cleared by its clearing event, OpenNMS acknowledges the notice and sends the resolution notice. After the change, reload Notifd as in the first step. For notices that still get no resolution notice, turn on the [auto-resolve timeout](/en/on-call/channel/create-edit) in the channel that receives this integration's alerts, set **Window timing start** to **Incident trigger**, and set the timeout to 24 hours. ## Severity ---- Severity comes from `severity` in the request, which is the OpenNMS event severity that `%severity%` resolves to in the optional step: @@ -201,14 +196,12 @@ Severity comes from `severity` in the request, which is the OpenNMS event severi In a resolution notice, `severity` is the numeric severity id OpenNMS stores (for example `5` for `Minor` and `6` for `Major`). Flashduty converts ids 1–7 back to severity names, so the recovery event keeps the severity the alert was triggered with. ## Alert content ---- - **Title**: the notice subject `subject` without the `RESOLVED: ` prefix; `OpenNMS notice #` when the subject is empty - **Description**: the notice text `message` without the `RESOLVED: ` prefix - **Labels**: `notice_id`, `event_id`, `event_uei`, `node_id`, `interface`, `service`, `severity` (the severity name; the numeric id in a resolution notice is converted to its name). Labels with empty values are not added ## Troubleshooting ---- The log messages below are in `$OPENNMS_HOME/logs/notifd.log`. diff --git a/en/on-call/integration/alert-integration/alert-sources/openobserve.mdx b/en/on-call/integration/alert-integration/alert-sources/openobserve.mdx index 8fe2570f..c45ae274 100644 --- a/en/on-call/integration/alert-integration/alert-sources/openobserve.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/openobserve.mdx @@ -9,7 +9,6 @@ An OpenObserve webhook destination has no fixed request body: the body is the te
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure OpenObserve ---- You need permission to manage alert templates and destinations. @@ -84,14 +82,12 @@ The template must contain `org_name`, `stream_name`, and `alert_name`; Flashduty ## Alert Key ---- Flashduty computes the Alert Key from `org_name`, `stream_type`, `stream_name`, and `alert_name`, so the trigger, repeated triggers, and recovery of one OpenObserve alert share an Alert Key. Changes to the level, result count, threshold, trigger time, or `episode_id` do not change it; an empty `stream_type` counts as an empty value. A request without `org_name`, `stream_name`, or `alert_name` is rejected. Renaming an OpenObserve alert, stream, or organization produces a new Alert Key. ## Status and severity ---- | `alert_level` | Flashduty severity | | :--- | :--- | @@ -101,12 +97,10 @@ Renaming an OpenObserve alert, stream, or organization produces a new Alert Key. An `alert_status` of `resolved` recovers the alert; any other value triggers it. Before OpenObserve 1.1, `{alert_status}`, `{alert_level}`, and `{episode_id}` are not substituted and arrive as the literal template text. Flashduty treats them as empty, so the alert triggers as Warning. ## Recovery ---- Flashduty receives a recovery request, and closes the alert automatically, only with OpenObserve 1.1 or later and recovery notifications enabled on the alert. Otherwise every firing is an independent one-shot notification with no recovery request. For these alerts, set **auto-close after timeout** on the Flashduty integration or channel with a suitable duration, or the alert stays active. ## Labels ---- | Label | Source | | :--- | :--- | @@ -123,7 +117,6 @@ Flashduty receives a recovery request, and closes the alert automatically, only The template does not contain `{rows}`, so Flashduty does not receive the log rows the query returned. ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: Check that the URL is complete and includes `integration_key`, that the template contains `org_name`, `stream_name`, and `alert_name`, and that the template is valid JSON - **The alert does not recover**: Check that OpenObserve is 1.1 or later and that the alert has recovery notifications enabled; otherwise configure auto-close after timeout diff --git a/en/on-call/integration/alert-integration/alert-sources/opensearch.mdx b/en/on-call/integration/alert-integration/alert-sources/opensearch.mdx index c5ec7cf7..e0ab4bd1 100644 --- a/en/on-call/integration/alert-integration/alert-sources/opensearch.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/opensearch.mdx @@ -11,7 +11,6 @@ Each trigger of each monitor maps to one Flashduty alert: while the trigger cond
## In Flashduty On-call ---- You can obtain an integration push URL in either of the following ways. @@ -32,7 +31,6 @@ You can obtain an integration push URL in either of the following ways.
## Configure OpenSearch ---- The Alerting and Notifications plugins must be installed (OpenSearch ships with both), and you need permission to create notification channels and monitors. @@ -95,14 +93,12 @@ Triggers of per query and per cluster metrics monitors run their actions only wh ## Alert Key ---- Flashduty computes the Alert Key from the monitor ID and the trigger ID, which are `monitor_id` and `trigger_id` in the template. Every notification from the same trigger of the same monitor uses the same Alert Key and merges into one alert; different triggers and different monitors each get their own alert. Changes to the monitor name, trigger name, severity, hit count, or time period do not change the Alert Key. A notification with an empty `monitor_id` or `trigger_id` is rejected with an invalid-parameter error. The template does not use `ctx.alert.id`: when a trigger runs its action for the first time, OpenSearch has not created the alert yet, so the variable is empty. ## Status and severity ---- The trigger's **Severity level** ranges from 1 (highest) to 5 (lowest). Flashduty maps it as follows: @@ -116,7 +112,6 @@ The trigger's **Severity level** ranges from 1 (highest) to 5 (lowest). Flashdut Every notification is a trigger. Flashduty never recovers an alert because of an OpenSearch notification; recovery comes from auto-close, or you can close the alert manually in Flashduty. ## Labels ---- | Label | Source | | :--- | :--- | @@ -129,7 +124,6 @@ Every notification is a trigger. Flashduty never recovers an alert because of an | `error` | Error message when the trigger could not get results or evaluate its condition | ## Troubleshooting ---- - **Flashduty returns an invalid-parameter error**: make sure Message holds the complete template with values for both `monitor_id` and `trigger_id`, and that the URL is complete and includes `integration_key` - **The notification fails in OpenSearch**: click **Send test message** on the channel in **Notifications → Channels** to see the error. Common causes are a cluster that cannot reach `api.flashcat.cloud` or a domain listed in `host_deny_list` diff --git a/en/on-call/integration/alert-integration/alert-sources/openstatus.mdx b/en/on-call/integration/alert-integration/alert-sources/openstatus.mdx index af0e063e..0d6ad522 100644 --- a/en/on-call/integration/alert-integration/alert-sources/openstatus.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/openstatus.mdx @@ -9,7 +9,6 @@ Use an OpenStatus Webhook notification channel to send monitor alerts to Flashdu
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure OpenStatus ---- @@ -65,7 +63,6 @@ OpenStatus sends an `error` notification only after at least half of the monitor ## Alert Key ---- Flashduty computes the Alert Key from `monitor.id` (the OpenStatus monitor ID). The `error`, `degraded`, and `recovered` notifications for a monitor carry the same `monitor.id`, so they land on the same alert: when the monitor goes from error to degraded, the alert is updated to Warning, and it closes when the monitor recovers. @@ -76,7 +73,6 @@ Changes to the monitor name, URL, status code, latency, error message, or check ## Status and severity ---- | OpenStatus `status` | Flashduty handling | Severity | | :--- | :--- | :--- | @@ -88,14 +84,12 @@ Changes to the monitor name, URL, status code, latency, error message, or check An empty or any other `status` is rejected so that a request whose state cannot be determined never lands in the wrong alert lifecycle. ## Alert content ---- - **Title**: the monitor name `monitor.name`, or `OpenStatus monitor ` when it is empty - **Description**: `errorMessage` - **Labels**: `check` (monitor name), `resource` (monitor URL `monitor.url`), `source` (always `openstatus`), `monitor_id`, `status`, `status_code`, `latency_ms` ## Troubleshooting ---- - **Send Test fails**: make sure **Webhook URL** is the full push URL and includes `integration_key` - **Flashduty returns a parameter error**: make sure the request has `monitor.id` and `status`. This integration accepts only the JSON format of the OpenStatus Webhook channel diff --git a/en/on-call/integration/alert-integration/alert-sources/opmanager.mdx b/en/on-call/integration/alert-integration/alert-sources/opmanager.mdx index 077b4815..8a14ad4d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/opmanager.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/opmanager.mdx @@ -8,7 +8,6 @@ Sync OpManager alert events to Flashduty via webhook for automated alert noise r
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -43,7 +42,6 @@ Choose this method when you need to route alerts to different channels based on
## In OpManager ----
## I. OpManager Alert Push Configuration diff --git a/en/on-call/integration/alert-integration/alert-sources/opnsense.mdx b/en/on-call/integration/alert-integration/alert-sources/opnsense.mdx index b91d3a28..19f27a7d 100644 --- a/en/on-call/integration/alert-integration/alert-sources/opnsense.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/opnsense.mdx @@ -9,7 +9,6 @@ OPNsense monitors services with the **Monit** module (**Services → Monit**) an
## In Flashduty On-call ---- Get the integration email address in either of the two ways below. **In both cases choose the Email integration type**, not OPNsense. @@ -30,7 +29,6 @@ Get the integration email address in either of the two ways below. **In both cas
## Configure OPNsense ---- 1. **SMTP**: go to **Services → Monit → Settings**, enable Monit under **General Settings**, and enter the SMTP server address, port and credentials 2. **Recipient**: under **Alert Settings**, add an alert and set **Recipient** to the Flashduty email integration address @@ -43,7 +41,6 @@ Subject: [$HOST] [$SERVICE] $EVENT 4. **Recovery notifications**: Monit sends a recovery email in the same format when a service recovers. Leave **Not on** off so that every event, including recovery, is emailed ## Configure push rules in Flashduty ---- In the title `[$HOST] [$SERVICE] $EVENT`, `$HOST` and `$SERVICE` are the same in the failure email and the recovery email; only `$EVENT` differs. The rules use the first two parts as the Alert Key, so a recovery email closes the matching alert. @@ -68,7 +65,6 @@ Regex: /^\[(.+?)\] \[(.+?)\] / The close rule comes before the trigger rule. The Alert Key is the host name plus the service name, so repeated failures of the same service on the same host merge into one alert. The default rule discards mail that was not sent in the format above (for example from other alerts that have no **Mail format** set) so it does not create alerts that can never close on their own. ## Events in the email title ---- `$EVENT` is Monit's description of the event. Failures and recoveries come in pairs: @@ -81,7 +77,6 @@ The close rule comes before the trigger rule. The Alert Key is the host name plu | nonexist | `Does not exist` | `Exists` | ## Limitations ---- - **Type and severity**: in Flashduty these alerts show the Email integration type, and their severity is always Warning. You can adjust it with [alert pipelines](/en/on-call/integration/alert-integration/alert-pipelines) based on the title. - **Other events**: Monit events not in the table above are handled as trigger alerts. If an event type has no matching recovery email, turn on the [auto-resolve timeout](/en/on-call/channel/create-edit) in the channel that receives this integration; 24 hours is a reasonable start. diff --git a/en/on-call/integration/alert-integration/alert-sources/opsgenie.mdx b/en/on-call/integration/alert-integration/alert-sources/opsgenie.mdx index 2b1cb913..1abe4f52 100644 --- a/en/on-call/integration/alert-integration/alert-sources/opsgenie.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/opsgenie.mdx @@ -9,7 +9,6 @@ Flashduty implements alert creation and closing from the Opsgenie Alert API, wit
## In Flashduty On-call ---- You can get the push URL in either of two ways. @@ -30,7 +29,6 @@ You can get the push URL in either of two ways.
## Push URL ---- The push URL has this format, with `integration_key` as part of the path: @@ -51,7 +49,6 @@ Supported endpoints: A successful request returns HTTP 202 and `{"result": "Request will be processed", "took": 0, "requestId": "..."}`, the same as Opsgenie. ## Configure in Prometheus Alertmanager ---- Add `opsgenie_configs` to a receiver in `alertmanager.yml` and set `api_url` to the push URL: @@ -75,7 +72,6 @@ receivers: - The Update Message and Update Description requests sent with `update_alerts: true` are accepted and ignored; the title and description update with the next Create request ## Configure in Grafana ---- @@ -112,7 +108,6 @@ Grafana sends alert labels in `tags` as `key:value`, and Flashduty turns them ba The contact point's **Test** button uses a new alias on every press, so each press opens a separate Warning alert in Flashduty that never recovers on its own. Close it by hand. ## Other tools ---- Any tool that lets you change the Opsgenie API URL and closes alerts by alias works with this integration: replace the API URL with the push URL (with or without `v2/alerts`, depending on how the tool appends paths), and send Close requests with `identifierType=alias`. @@ -123,14 +118,12 @@ Not supported: - **Aliases that contain `/`**: the alias is part of the URL path, so such requests match no endpoint ## Alert Key ---- The request's `alias` is the Alert Key. Opsgenie defines alias as the "client-defined identifier of the alert, that is also the key element of Alert De-Duplication" ([Alert API](https://docs.opsgenie.com/docs/alert-api#create-alert)). Create requests with the same alias merge into one alert, and a Close request recovers that alert by alias. Alertmanager and Grafana both use a hash of the alert group as the alias, which stays the same from trigger to recovery. Without `alias`, every Create request opens a new alert that no Close request can recover. ## Field mapping ---- | Opsgenie field | In Flashduty | | :--- | :--- | @@ -146,7 +139,6 @@ Without `alias`, every Create request opens a new alert that no Close request ca `responders`, `visibleTo`, `actions`, `user` and `note` are ignored; assignment and notifications follow the Flashduty channel's settings. ## Severity ---- | Opsgenie `priority` | Flashduty severity | | :--- | :--- | @@ -157,7 +149,6 @@ Without `alias`, every Create request opens a new alert that no Close request ca Any other value returns 422. Recovery comes from the Close request, not from `priority`. ## Troubleshooting ---- - **404**: the Alertmanager `api_url` is missing the trailing `/`, or the Grafana Alert API URL is missing `/v2/alerts` - **401**: the `integration_key` in the push URL is wrong, or the integration is disabled diff --git a/en/on-call/integration/alert-integration/alert-sources/opsview.mdx b/en/on-call/integration/alert-integration/alert-sources/opsview.mdx index bd067382..4859e229 100644 --- a/en/on-call/integration/alert-integration/alert-sources/opsview.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/opsview.mdx @@ -9,7 +9,6 @@ Opsview supports custom notification methods: when it notifies, it runs the scri
## In Flashduty On-call ---- Get an integration push URL in either of the two ways below. **Choose the Standard Alert Event integration type** in both, not Opsview. @@ -30,7 +29,6 @@ Get an integration push URL in either of the two ways below. **Choose the Standa
## Configure in Opsview ---- ### Step 1: Create the notification script @@ -136,14 +134,12 @@ Opsview notifications are driven by each user's Notification Profile, so every u You can also create a shared profile under Shared Notification Profiles and assign it to several users. ## Recovery and deduplication ---- - A host or service always uses the same Alert Key, so repeated problem notifications (for example from Opsview's re-notification interval) only update the same alert, and the `RECOVERY` notification recovers it - When a service goes from WARNING to CRITICAL, the severity is updated on the same alert - Acknowledgement (`ACKNOWLEDGEMENT`), flapping (`FLAPPING*`) and downtime (`DOWNTIME*`) notifications are ignored by the script and produce no event in Flashduty ## Troubleshooting ---- - **No alert arrives**: confirm the Notification Profile selects `Flashduty` and **Apply Changes** was run; check in Opsview's **Notifications View** whether the notification was sent; test the script on its own with `test_notifications` - **The test works but real alerts are not pushed**: in a real notification the script reads the environment variables Opsview passes; add `{ date; echo "Called with $@"; env; echo; } >> /tmp/env.txt` to the top of the script (the debugging method given in the Opsview documentation) to see what it actually receives diff --git a/en/on-call/integration/alert-integration/alert-sources/ossec.mdx b/en/on-call/integration/alert-integration/alert-sources/ossec.mdx index 9bcdd65a..c847d882 100644 --- a/en/on-call/integration/alert-integration/alert-sources/ossec.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/ossec.mdx @@ -9,7 +9,6 @@ The OSSEC server (ossec-maild) can send alerts by email to the recipients you co
## In Flashduty On-call ---- You can get the integration email address in either of the two ways below. **Choose Email as the integration type** in both cases, not OSSEC. @@ -30,7 +29,6 @@ You can get the integration email address in either of the two ways below. **Cho
## Configure the push mode in Flashduty ---- OSSEC sends one email when an alert is generated and never sends a recovery email, so no "close alert" rule is needed. Set **Push Mode** to **Trigger or Update Alert Based on Email Subject**: emails with the same title (same host, same log source, same level, same rule description) are merged into the one open alert, and emails with different titles each create a separate alert. @@ -39,7 +37,6 @@ The title format is described in [Email subject format](#email-subject-format). OSSEC does not send recovery notifications. Enable [auto-resolve timeout](/en/on-call/channel/create-edit) on the channel that receives this integration, with a suggested window of 24 hours, or close alerts manually once handled. ## Configure OSSEC ---- All configuration below is done in `/var/ossec/etc/ossec.conf` on the OSSEC server. Agents need no configuration because alerts are generated only on the server. @@ -110,7 +107,6 @@ By default OSSEC batches alerts that arrive close together into a single email, ## Email subject format ---- OSSEC emails use the full subject by default (internal option `maild.full_subject=0`, the default value): @@ -129,7 +125,6 @@ The location is "(agent name) agent IP", or the server name for alerts from the The email body starts with `OSSEC HIDS Notification.`, followed by the alert time, `Received From` (the alert source), `Rule: fired (level ) -> ""`, the source IP / user when present, and the triggering log excerpt (`Portion of the log(s)`). In Flashduty, the alert title is the email subject and the description is the email body. ## Limitations ---- - **No recovery**: an OSSEC alert is a one-time event. Alerts in Flashduty do not resolve automatically; rely on [auto-resolve timeout](/en/on-call/channel/create-edit) or close them manually. - **Severity**: the Email integration sets every alert to Warning. The subject carries the OSSEC level (`Level N`), so you can adjust severity by level with an [Alert Pipeline](/en/on-call/integration/alert-integration/alert-pipelines). diff --git a/en/on-call/integration/alert-integration/alert-sources/pagerduty.mdx b/en/on-call/integration/alert-integration/alert-sources/pagerduty.mdx index e454952d..12981ff5 100644 --- a/en/on-call/integration/alert-integration/alert-sources/pagerduty.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/pagerduty.mdx @@ -11,7 +11,6 @@ Similarly, for alert systems that already support pushing events to PagerDuty (s
## In Flashduty ---- You can obtain an integration push URL through either of these two methods: ### Using Private Integration @@ -46,7 +45,6 @@ Choose this option when you need to route alerts to different channels based on
## In your alerting system ---- ### Request URL ``` diff --git a/en/on-call/integration/alert-integration/alert-sources/pandora-fms.mdx b/en/on-call/integration/alert-integration/alert-sources/pandora-fms.mdx index f262f6bb..7a00a55b 100644 --- a/en/on-call/integration/alert-integration/alert-sources/pandora-fms.mdx +++ b/en/on-call/integration/alert-integration/alert-sources/pandora-fms.mdx @@ -9,7 +9,6 @@ Use a custom Pandora FMS alert command to send module alert triggers and recover
## In Flashduty On-call ---- You can get the integration push URL in either of the following ways. @@ -30,7 +29,6 @@ You can get the integration push URL in either of the following ways.
## Configure Pandora FMS ---- Pandora FMS alert actions run a command on the Pandora FMS server. The steps below create an alert command that pushes with `curl`, create an action that uses the command, and then add the action to module alerts. @@ -105,7 +103,6 @@ The action's **Field 2** must be `alert_recovered` in the **Recovery** column. I ## Pushed content ---- The command POSTs the following fields as an `application/x-www-form-urlencoded` form: @@ -130,7 +127,6 @@ The command POSTs the following fields as an `application/x-www-form-urlencoded` The alert title is `