用途：设计 API 平台如何向外部消费者传达运行状态与事故信息，产出的是沟通实践，而非监控栈（测量归可观测性工具）。
主要能力：1) 状态与组件建模：采用 Investigating、Identified、Monitoring、Resolved 四阶段事故生命周期；组件严重度按影响广度分为 Degraded Performance、Partial Outage、Major Outage，页面视觉状态上限四种；顶层状态取最差组件并按固定混合规则聚合；组件粒度按用户心智模型而非内部架构划分，区域事故按区域呈现。2) 状态接入监控：页面状态直接绑定健康检查、延迟阈值与在线率数据，由监控自动开启事故，人工只做充实，并保留工作流级探针。3) 渠道选择：状态页为拉取渠道，配合邮件/RSS 订阅为推送；开发者场景可升级 Webhook，有合同 SLA 的企业客户可上短信；无企业受众的短信渠道应删除；跨基础设施的带外冗余优先级最高但成本最大。4) 事故沟通：遵循尽早、频繁（每次给出下次更新时间）、精确、跨渠道一致、共情认责，用平实语言命名事故。5) 复盘政策：默认发布状态页摘要复盘，重大事故升级为完整公开复盘，价值高但需法务与沟通审批。6) SLA/SLO 报告：区分 SLI（测量指标）、SLO（内部目标）、SLA（有后果的合同承诺）。
使用方式：先提出澄清问题（是否已有状态页、是否由监控设定状态、读者构成、合同 SLA、是否共享基础设施、上次事故消费者如何得知、截止期与投入上限），再按七步工作流依次设计。
限制：需注意降级性能在 SLA 计算中通常计为 0% 停机；不要用自定义状态词；不要仅凭基础设施指标判断；未提供具体价格、平台或效果数据。