XHealth 状态表示检查任务的执行结果。判断业务是否恢复前，应确认最近一次检查已经完成并成功，而不是只看到任务不再报错或容器正在运行。
状态含义
| 状态 | 解释 |
|---|---|
| Pending | 等待执行，尚无本轮成功结果 |
| Running | 检查正在执行 |
| Passed | 最近完成的检查通过 |
| Failed | 检查失败，结合错误和日志分析 |
| Settled | 本轮已结束或收敛，但不能据此认定检查通过 |
状态显示采用当前界面的本地化文字。记录完成时间，避免把很早以前的成功当作当前健康状态。
建议排查顺序
- 检查应用实际副本是否运行，是否正处于部署或重启过程。
- 核对检查方法、目标端口和执行间隔。
- 打开应用日志，选择 XHealth 对应来源，查看本轮输出。
- 区分运行工具失败与业务断言失败。
- 修正后等待新的完整检查结果，并验证真实客户端访问。
常见失败
| 现象 | 优先检查 |
|---|---|
| Hurl 文件无法执行 | 文件语法、版本、文件内容和大小 |
| 自定义程序不存在 | 应用镜像是否包含工具、命令路径是否正确 |
| 连接拒绝 | 应用监听地址、内部端口、启动是否完成 |
| HTTP 状态断言失败 | 实际状态码、认证要求、重定向和业务接口 |
| 目标不存在或不明确 | 域名、发布端口与应用配置是否一致，是否对应多个端口 |
| 一直等待或运行 | 服务器容量、任务启动情况、检查是否缺少合理退出条件 |
检查目标使用的是应用内部服务地址。公网域名不可访问时，即使内部检查通过，也需要另外检查 DNS、Pingress、证书和防火墙。
调整检查设计
检查应覆盖明确的可用条件，响应时间和依赖检查深度应与业务需要相符。只测试一个永远返回 200 的静态路径，不能证明数据库或关键业务链路正常。
也不要让检查依赖不稳定且与核心业务无关的外部站点，否则会制造与应用自身无关的失败结果。
通知与发布
周期性失败可以进入平台通知流程，按通知设置配置接收渠道。普通告警与 AI 值班分析是不同机制。
启用 Guardian 后，候选实例检查失败应结合候选应用和候选检查日志分析；正式实例与候选实例的状态不能混为一谈，参见发布验证。