XHealth 狀態表示檢查任務的執行結果。判斷業務是否恢復前，應確認最近一次檢查已經完成並成功，而不是只看到任務不再報錯或容器正在執行。
狀態含義
| 狀態 | 解釋 |
|---|---|
| Pending | 等待執行，尚無本輪成功結果 |
| Running | 檢查正在執行 |
| Passed | 最近完成的檢查通過 |
| Failed | 檢查失敗，結合錯誤和日誌分析 |
| Settled | 本輪已結束或收斂，但不能據此認定檢查通過 |
狀態顯示採用當前界面的本地化文字。記錄完成時間，避免把很早以前的成功當作當前健康狀態。
建議排查順序
- 檢查應用程式實際副本是否執行，是否正處於部署或重啟過程。
- 核對檢查方法、目標連接埠和執行間隔。
- 打開應用程式日誌，選擇 XHealth 對應來源，查看本輪輸出。
- 區分執行工具失敗與業務斷言失敗。
- 修正後等待新的完整檢查結果，並驗證真實用戶端存取。
常見失敗
| 現象 | 優先檢查 |
|---|---|
| Hurl 檔案無法執行 | 檔案語法、版本、檔案內容和大小 |
| 自訂程序不存在 | 應用程式映像檔是否包含工具、指令路徑是否正確 |
| 連接拒絕 | 應用程式監聽地址、內部連接埠、啟動是否完成 |
| HTTP 狀態斷言失敗 | 實際狀態碼、認證要求、重定向和業務接口 |
| 目標不存在或不明確 | 網域、發佈連接埠與應用程式設定是否一致，是否對應多個連接埠 |
| 一直等待或執行 | 伺服器容量、任務啟動情況、檢查是否缺少合理退出條件 |
檢查目標使用的是應用程式內部服務地址。公網網域不可存取時，即使內部檢查通過，也需要另外檢查 DNS、Pingress、憑證和防火牆。
調整檢查設計
檢查應覆蓋明確的可用條件，回應時間和依賴檢查深度應與業務需要相符。只測試一個永遠回傳 200 的靜態路徑，不能證明資料庫或關鍵業務連線路徑正常。
也不要讓檢查依賴不穩定且與核心業務無關的外部站點，否則會製造與應用程式自身無關的失敗結果。
通知與發佈
週期性失敗可以進入平台通知流程，按通知設定設定接收渠道。普通告警與 AI 值班分析是不同機制。
啟用 Guardian 後，候選實例檢查失敗應結合候選應用程式和候選檢查日誌分析；正式實例與候選實例的狀態不能混為一談，參見發佈驗證。