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