IncidentRelay v2.3.1 的工作示例，于 检查。下面的名称、标识符和时间是说明性的；在使用生产凭据之前在测试部署中验证它们。
业务示例 · 设置 · 工作示例 · 验收检查 · 限制和失败模式
业务示例：SaaS 客户跨时区工作
说明性场景，而非客户案例研究。以下指标是针对您的试点的建议，不是衡量节省的结果，也不是 IR 包含每个报告仪表板的声明。
情况和风险。B2B SaaS 团队为欧洲和北美的客户提供服务。一位客户的下午工作时间与另一位工程师的晚上时间重叠，而通常的响应人员正在休假。如果没有商定的时间表，团队就会依赖最先注意到聊天的人。风险是无主停机以及下班员工的反复中断。
IR 工作流程。就人员覆盖范围达成一致，然后用基本轮换和工作日层来表示。将假期替换记录为覆盖并配置单独的备份升级目标。检查移交和未来的差距。对于计划的计费部署，请使用服务范围的维护时段，同时不相关的服务继续通知。
需要验证的运营效益。使支持和工程的责任可预测，包括休假和交接。计划的工作不应要求将整个公司的警报流静音。
衡量内容。查看未来指定时间段内未覆盖的时间，例如接下来的 14 天、最后一刻的手动移交以及团队响应目标内的确认。将每位工程师的夜间通知与实际人员配置时间表进行比较；仅靠平衡的日历并不能显示工作量。
边界。日历被填满并不会产生额外的员工或证明有人可以做出回应。 IR 不保证合同响应时间或根据 ACK 计算客户可用性。将人员配置决策、SLO 监控和客户沟通纳入更广泛的运营流程中。
在优化工作日之前过夜
假设 SRE 团队在工作日轮班和夜间轮班中拥有计费可靠性。在一次循环中，创建优先级为 10 且覆盖范围不受限制的 24/7 的基础层。添加优先级为 20 的图层，仅限于周一至周五的 09:00-18:00 Europe/Berlin。使用真实的活跃会员并验证生成的日历。
最高优先级的活动层为受让人提供服务；覆盖优先于图层。他们不是两个同时响应者。为备份覆盖配置单独的升级目标或轮换。如果没有活动图层并且没有应用覆盖，则没有受让人。请参阅旋转和图层规则。
在计划部署期间暂停计费通知
通过界面创建服务范围的窗口，或使用经过身份验证且有权修改范围的管理 API 会话将此配置提交到 POST /api/maintenance-windows。入口路由令牌不是管理凭证。将 42 替换为您的实际结算服务 ID，并选择未来的测试时段。
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}这些时间戳是所选时区的挂钟时间，而不是省略了 Z 的 UTC 值。在此窗口期间，传入的账单警报仍然可见，但通知、提醒和升级会暂停。其他服务应该不受影响。此行为不是 suppress_incident（阻止新警报组）或 pause_escalation_only（保持通知启用状态）。
测试边界，而不仅仅是轮班的中间
- 在周末和夏令时过渡期间的 09:00 和 18:00 前后检查作业。添加临时覆盖并确认其获胜，然后将其删除。
- 打开完整的待命运行状况检查。查看其检查的未来窗口、差距、不活跃成员和可用的交付方法。绿色摘要并不是永久覆盖或发送到手机的证明。
- 在维护期间发送计费和不相关的服务测试事件。确认账单可见但安静，并且不相关的服务仍会通知。要包含尚未解决的警报，请明确启用将窗口应用于现有警报的选项；默认情况下它是关闭的。
- 当窗口结束时，继续计费。启用重新激活后，验证正常通知是否恢复，而无需重播每个错过的提醒。确认实际响应者收到并可以确认。
安静的服务不是恢复的服务
维护并不修复服务、撤回已发送的消息或暗示解决方案。默认启用最后重新激活；禁用它会在窗口结束后保留维护效果。重叠的窗口可以使警报保持安静，直到释放最后一个适用的活动或保留的效果。请查看维护指南中的这些控件。
将 SLO 计算和消耗率检测保留在监控堆栈中。 IR 路由并协调产生的信号。 AlertGroup 拥有技术确认、解决方案、通知和升级； 事件是一个单独的操作工作流程。将多个警报组链接到一个事件并不会合并它们的技术历史记录。在 v2.3.1 中，响应者和利益相关者仍然属于 AlertGroups。测试两个生命周期，而不是将事件状态更改视为警报组 ACK。