repeat_interval 是 Alertmanager 路由中定义同一告警组在首次通知后、问题未恢复且无状态变化时再次发送聚合通知的时间间隔，需与 group_interval 协同配置，且须小于数据保留期并确保系统时间同步。

重复告警频率不是靠“关掉”来控制的，而是通过 Alertmanager 的 repeat_interval 与配套参数协同调节的。它不决定“是否重发”，而决定“多久重发一次”——前提是问题未恢复、且该组告警没有新增或状态变化。

repeat_interval 是什么

它是 Alertmanager 路由（route）中的一项时间配置，定义：同一组告警在首次通知成功后，若问题持续存在且组内无新告警加入、也无告警恢复，需等待多久才再次发送聚合通知。

关键点：

• 只对已发送过的告警组生效
• 触发条件是“静默期满 + 无变更”，不是每过 X 小时就盲目重发
• 它的作用对象是“告警组”，不是单条告警实例

必须配合 group_interval 使用

group_interval 控制的是“同一组内，两次聚合通知之间的最小间隔”。如果 repeat_interval 小于 group_interval，Alertmanager 不会报错，但实际重发行为会被 group_interval 截断——即：即使 repeat_interval 设为 10m，只要 group_interval 是 30m，那至少得等满 30 分钟才可能重发。

合理搭配示例：

• 高优先级告警（如 service_down）：group_interval: 1m，repeat_interval: 15m
• 中低优先级（如 disk_usage_high）：group_interval: 5m，repeat_interval: 2h
• 避免设为 0s（验证失败）或小于 group_interval（逻辑失效）

分组策略直接影响重发节奏

repeat_interval 是否有效，取决于告警是否稳定落在同一组里。如果一个服务的多个指标（CPU、内存、请求延迟）被分到不同组，那它们各自按自己的 repeat_interval 发送，看似“重复”，实则是多个独立组在轮播。

建议做法：

• 用 group_by 显式绑定业务维度，例如 [service, environment] 或 [job, instance]
• 把易波动的指标（如瞬时错误率）和长稳型指标（如服务存活）分开路由，避免互相干扰重发周期
• 对关键故障，可配合 inhibit_rules 抑制衍生告警，让 repeat_interval 只作用于真正需要持续提醒的主告警

别忽略数据保留与实效性匹配

如果 repeat_interval 设置为 48h，但 Prometheus 的数据保留期（--storage.tsdb.retention.time）只有 24h，那么部分历史告警状态可能已丢失，导致 Alertmanager 误判为“新告警”，引发非预期重发。

检查要点：

• repeat_interval ≤ 数据保留时间 × 0.8（留出安全余量）
• 确认 Prometheus 和 Alertmanager 的系统时间同步（NTP），否则时间判断失准
• 升级 Alertmanager 到 v0.26+ 版本，修复了早期版本中 group_interval 与 webhook 超时耦合的问题