StatusChange（监控状态变化）和 EarlyWarningSignal（早期预警，服务尚未确认故障）。每个 StatusGator 监控对应一条告警：监控变为 down、warn 或 maintenance 时触发，变回 up 时恢复。
在 Flashduty On-call
您可通过以下两种方式获取集成推送地址，任选其一即可。
使用专属集成
- 进入 Flashduty 控制台，选择 协作空间，打开一个协作空间
- 选择 配置 → 集成数据 → 专属集成，点击 新增一个集成
- 选择 StatusGator，点击 保存
- 打开生成的集成卡片，复制 推送地址
使用共享集成
- 进入 Flashduty 控制台，选择 集成中心 → 告警事件
- 选择 StatusGator，填写集成名称
- 配置默认路由并选择协作空间；创建后可在 路由 中增加更多规则
- 点击 保存，复制生成的 推送地址
在 StatusGator 中配置
1
添加 Webhook 集成
- 登录 StatusGator，在页面顶部进入 Integrations
- 选择 Webhooks，点击 Add
- 将 Flashduty 集成的完整推送地址粘贴为 Webhook URL，点击 Save
2
发送测试通知并验证
保存后在 Webhook 集成页面点击 Test integrations，选择状态、监控和 Webhooks 集成，点击 Send test。无论选择哪种状态，Flashduty 都会新建一条标题为
StatusGator test notification 的 Info 级别独立告警，不会改动该监控自身的告警；它没有恢复事件，请手动关闭。真实的状态变化取决于被监控服务自身的故障，无法按需触发。推送内容
StatusGator 以 JSON 格式 POST 事件，请求体固定，不可自定义，Flashduty 直接解析，无需配置模板：
告警标题为
<监控名称>: <message>；message 为空时为 <监控名称> is <status>。
Alert Key
StatusChange 使用 monitor.id 作为 Alert Key。StatusGator 的请求体没有事件或故障 ID，监控是唯一稳定的业务对象：同一个监控的 down、warn、up 通知落在同一条告警上，不同监控生成不同的告警。修改消息、组件、名称或时间不会改变 Alert Key。
EarlyWarningSignal 使用由固定前缀和 monitor.id 计算的独立 Alert Key，不会与该监控的状态告警合并；同一个监控重复的早期预警会合并为一条告警。
请求中缺少 monitor.id 时，Flashduty 会返回参数错误，因为无法可靠地把恢复通知关联到原告警。
状态和告警等级
type 或 status 为空或为其他值的请求会被拒绝，避免把无法判断状态的请求写入错误的告警生命周期。
早期预警不会自动恢复
EarlyWarningSignal 是单次通知，StatusGator 不会发送对应的恢复事件，Flashduty 也不会在服务恢复时关闭它。请开启协作空间的超时自动关闭，建议设置为 1 小时。
常见问题
测试通知会创建告警吗？
测试通知会创建告警吗？
会。Test integrations 发送的通知的
message 为 Test message for <看板名称>。Flashduty 只识别这一条完全一致的消息，并用独立的 Alert Key 新建一条 Info 告警，因此测试不会创建或关闭真实监控的告警。该告警没有恢复事件，请手动关闭。监控恢复后告警没有关闭怎么办？
监控恢复后告警没有关闭怎么办？
确认恢复时仍使用同一个 Webhook 集成，并在 StatusGator 的 Logs 标签页中检查
status 为 up 的投递是否返回 200。恢复通知与故障通知的 monitor.id 必须相同。StatusGator 会重试失败的投递吗？
StatusGator 会重试失败的投递吗？
会。非连接类失败最多重试 20 次，历时约 24 天，间隔从几秒增长到超过一天，之后丢弃。
排查问题
- StatusGator 显示投递失败或停用了 Webhook：确认 Webhook URL 是完整的推送地址，且包含
integration_key - Flashduty 返回参数错误：确认请求是 3.0 版本的 JSON 通知，且
type、monitor.id、status符合上文要求 - 收到的告警重复或无法恢复：检查是否同时保留了旧的 2.0 版本 Webhook