OpenAI 狀態頁顯示，API、ChatGPT 與 Codex 在 7 月 25 日出現 elevated error rates；頁面列出的受影響範圍包括 12 個 API 元件、15 個 ChatGPT 元件與 4 個 Codex 元件。OpenAI 先把狀態標為 investigating，再更新為已套用緩解措施並監控恢復，最後在同日上午 11:08 標示所有受影響服務已恢復。
這次公開紀錄描述的是服務可用性事件，沒有把錯誤歸因於某個模型版本、區域或供應商。OpenAI 的狀態頁也提醒，可用性指標是跨方案、模型與錯誤類型的彙總，單一客戶的實際影響可能不同。
OpenAI 狀態頁同時列出 API、ChatGPT 與 Codex 影響範圍
API、ChatGPT 和 Codex 是不同的產品入口，但這次事件在狀態頁上被放進同一則 elevated error rates 紀錄。API 客戶可能遇到請求錯誤，ChatGPT 使用者可能無法正常完成對話，Codex 則可能在程式開發工作中回傳失敗；公開頁面沒有列出每個元件的錯誤比例。
狀態頁把 affected components 分開列出，讓服務範圍與單一模型表現分開呈現。API 或 Codex 的一次失敗，不能直接當成模型回答品質下降；同樣地，某個模型的輸出異常也不會自動證明整個 ChatGPT 服務中斷。
OpenAI 以緩解措施與恢復狀態結束 7 月 25 日事件
OpenAI 在事件頁的更新順序是 investigating、monitoring 和 resolved。中間的 monitoring 更新只說已套用 mitigation 並觀察恢復，沒有公開修正內容、受影響請求數或服務端變更。狀態頁歷史紀錄則把 7 月 25 日的多筆 elevated error rates 事件列為已恢復。
這種時間線能確認故障何時被承認、何時進入觀察以及何時標記結束，但不足以還原技術根因。若沒有後續 postmortem 或更完整的狀態更新，不能把恢復時間倒推成某個部署、容量或網路故障的證據。
OpenAI 公開頁面尚未交代事件根因與客戶分布
截至事件頁完成更新，OpenAI 沒有在這則公開紀錄中說明是哪個服務元件觸發錯誤、哪些地區或方案受到較大影響，也沒有公布錯誤率、請求量與資料遺失狀況。狀態頁的彙總指標只能支持「多個入口曾出現錯誤並已恢復」這個結論。
目前可確認的後續項目是事件已被標記 resolved，並保留在 OpenAI Status 的歷史頁。若 OpenAI 後續發布根因說明，才有資料判斷這次事件是否與特定模型、部署或 API 變更有關。
消息來源：OpenAI Status：7 月 25 日 elevated error rates 事件、OpenAI Status：事件歷史紀錄。
