我们如何通知或告警您
只有正确的人收到通知，故障检测才有意义。我们发送到您的团队常用的渠道，以及在需要系统优先响应时发送到您的系统。
通知渠道
每个渠道收到相同的消息：哪个监控、从何时开始以及原因。每个地址只需添加一次，然后在规则中命名。
-
Email 每个套餐
发送到任意地址的消息，发送前需确认一次，确保告警不会指向他人的收件箱。
-
Webhook (POST) 每个套餐
包含以下所有字段的JSON正文，发送到您的URL。用于自动化：创建工单、通知值班人员、切换状态灯。
-
Webhook (GET) 每个套餐
相同字段作为查询参数，适用于只能接收GET请求的接收方。
-
PagerDuty 入门及以上套餐
通过Events API v2报告事件，故障时打开，恢复时关闭，由PagerDuty的升级机制接管。缓慢或丢失的检查会作为警告，而非严重告警。
-
Slack 专业和商业套餐
通过webhook发送到频道的消息，红色表示故障，绿色表示恢复。
-
Microsoft Teams 专业和商业套餐
通过webhook发送到Teams频道的相同消息。
-
Discord 专业和商业套餐
通过频道webhook发送到Discord频道的相同消息。
-
Telegram 专业和商业套餐
通过您的机器人发送到聊天中的相同消息。
谁在何时收到通知
先确认
不会仅凭一个探测器的结果发送通知。故障需得到其他两个大陆探测器的确认才会被认定为故障，因此告警表示站点确实宕机，而非中间网络问题。
规则和升级
规则定义谁会收到哪个监控的通知以及故障开始后多久通知。将值班表放入联系人组，并为每个成员设置延迟，一个规则即可成为升级机制，监控恢复时自动停止。
恢复时通知一次
所有收到故障通知的人都会收到故障结束的通知，并附上故障持续时间。我们不会为了告知故障结束而打扰您。
提前测试
每个地址都有一个按钮，可以通过与真实告警相同的路径发送测试消息，措辞确保不会被误认为真实故障。
webhook，用于您的系统
Webhook地址是您的URL。我们会在确认故障时、恢复时以及您按下测试按钮时调用它。POST以JSON格式发送字段作为请求体；GET以查询参数发送字段。URL会加密存储，之后不会完整显示，因为持有它的人可以向其发送请求。
| 字段 | 包含内容 |
|---|---|
| reason | 故障时为down，恢复时为recovery，按下测试按钮时为test |
| monitor | 监控名称 |
| monitor_id | 其ID，与仪表盘地址中的ID相同 |
| target | 监控内容：URL、主机或名称 |
| type | 检查类型，简短名称如https、dns或ssl_cert |
| cause | 故障原因，简短描述（如果已知） |
| error_class | 同样内容的简短名称，程序可据此分支，如timeout、connection或certificate_expired |
| started | 故障开始时间，包含时区 |
| confirmed_at | 故障确认时间 |
| confirmed_from | 确认故障的大陆名称列表。在2026年9月之前为单一名称 |
| degraded | 当监控变慢或丢包而非故障时为true |
| resolved | 故障结束时间，恢复时为ISO 8601时间戳 |
| duration | 故障持续时间，恢复时以文字表示 |
| incident_id | 事件ID，故障和恢复时相同 |
无内容的字段在JSON中为null，GET请求中会省略。响应状态低于400即可。其他状态视为发送失败，将在30秒、2分钟和10分钟后重试，最终放弃：未在15分钟内送达的警报已成历史，而非新闻。