OpenAI 七月狀態頁很忙
OpenAI 七月狀態頁連續記錄 ChatGPT、Codex、登入、圖片生成與 Moderation API 的多起事故，顯示平台在快速推進功能時，穩定性仍有明顯壓力。
OpenAI 七月狀態頁連續記錄 ChatGPT、Codex、登入、圖片生成與 Moderation API 的多起事故，顯示平台在快速推進功能時，穩定性仍有明顯壓力。
OpenAI 的 status history 在 2026 年 7 月很擠。ChatGPT、Codex、圖片生成、登入系統，全都輪流出事。很多事件都在幾小時內修好，但密度高到很難假裝沒看到。
更微妙的是，OpenAI 同時把 GPT-5.5 推進到 Codex 的付費用戶，還在 Moderation API 上碰到錯誤率與延遲升高。這種畫面很像一邊開新路，一邊補坑。對開發者來說，這不是八卦，是上線風險。
| Date | Incident | Status note |
|---|---|---|
| Jul 23, 2026 | Moderation API | Elevated error rates and latency |
| Jul 22, 2026 | Workspace Agent, file uploads, image generation, ChatGPT image generation | All impacted services recovered |
| Jul 21, 2026 | API image generation, logins and signups | Recovered |
| Jul 18, 2026 | Codex access, ChatGPT app availability | Recovered |
| Apr 23, 2026 | Codex access, GPT-5.5 in Codex, Moderation API | GPT-5.5 rollout note and mitigation update |
七月事故很密，還跨產品線
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
7 月 22 日那天，OpenAI 一口氣更新了多個事件。ChatGPT、Codex、圖片生成、檔案上傳、Workspace Agent，全都在同一天被點名。這種密度很少見，代表問題不是單點抖一下而已。
接著 7 月 21 日又輪到 API 圖片生成、登入與註冊。7 月 18 日則打到 Codex 存取與 ChatGPT app 可用性。你如果把這些事件串起來看，會發現它們橫跨消費端、開發端、帳號系統與媒體生成流程。
這種情況對台灣團隊很有感。很多公司把 OpenAI 接進客服、內部知識庫、程式輔助、內容生成，一旦登入或檔案流程出問題，前台看起來像壞掉，後台其實是整條鏈一起卡住。
- 7 月 22 日出現 4 筆事件更新。
- 7 月 21 日同時影響圖片生成、登入、註冊。
- 7 月 18 日碰到 Codex 與 ChatGPT app。
- 7 月 16 日出現 SSO 登入錯誤。
- 7 月 11 日的 FedRAMP workspace 事件牽動多個功能。
OpenAI 在狀態頁上的措辭很固定，常見就是「已完全恢復」。這句話看起來平淡，但它透露兩件事。第一，事件真的夠大，才需要公開更新。第二，修復多半很快，通常在同一天完成。
GPT-5.5 進 Codex，代表版本管理更重要
4 月 23 日那筆更新很重要。OpenAI 寫明 GPT-5.5 已提供給所有付費 Codex 用戶。頁面也提醒，如果還有存取問題，要更新到最新 Codex 版本。這句話看似普通，其實把產品 rollout 和 client 版本綁在一起了。
後面幾筆事件也呼應這件事。7 月 17 日，Codex 5.6-sol 出現 server-overload errors。7 月 16 日，有些人看到「Selected Model is at Capacity」。7 月 11 日，GPT-5.5 in Codex 又出現 elevated error rates。功能在推，問題也跟著冒出來。
對開發者來說，這種訊號很直接。你不能只看模型名稱，還要看客戶端版本、登入狀態、後端容量與路由切換。只要其中一環慢一拍，使用者感受到的就是「AI 壞了」，不會管是哪一層炸掉。
“The best way to predict the future is to invent it.” — Alan Kay
這句話很老，但放在這裡很貼切。OpenAI 的節奏就是先上線，再公開修補。這對產品團隊是壓力，對工程團隊是提醒。模型接入不是裝個 SDK 就好，還得把版本、權限、fallback、重試機制一起想清楚。
- GPT-5.5 已進入 Codex 的付費方案。
- 最新 Codex 版本成了存取問題的排查重點。
- 7 月多筆事件都直接指向 Codex。
- 模型能力更新與穩定性問題同時存在。
數字一比，問題範圍比單一 API 大
如果只看一個 endpoint，很容易低估狀況。7 月 23 日是 Moderation API；7 月 22 日是 Workspace Agent、檔案上傳、圖片生成；7 月 21 日又變成登入與註冊。這不是單一服務抽風，而是多個產品面同時拉警報。
再往前看，4 月、5 月、6 月也都有類似痕跡。像是 Responses API 404、轉錄失敗、訂閱結帳問題、GitHub 連接器異常、voice mode 問題，都在歷史頁面上留痕。這種分布代表壓力不只在模型推理，也在帳號、檔案、工作區與整合層。
對企業採購來說，這比單次故障更值得盯。因為你買的不是一個 API，而是一整串流程。只要其中一段不穩，客服、內部自動化、內容產線、程式輔助都會一起停。
- 產品面：ChatGPT、Codex、Sora API、Responses API、Moderation API 都出現事件。
- 帳號面：登入、註冊、SSO、Microsoft personal account sign-in 都曾受影響。
- 工作流面：檔案上傳、GitHub connectors、workspace analytics、code review 都有紀錄。
- 合規面：FedRAMP workspace 事件牽動多個功能。
我覺得最實際的結論很簡單：OpenAI 的狀態頁已經不只是「ChatGPT 有沒有掛」。它更像一份公開營運紀錄，讓工程師、PM、IT 管理員都能直接看出風險在哪裡。若你的產品依賴 OpenAI API，就不能只盯你呼叫的那個 endpoint。
台灣團隊該怎麼看這份狀態頁
如果你在台灣做 SaaS、內部工具，或把 LLM 接進客服與內容流程，這份歷史頁面很值得加入日常監控。它不是事後檢討用，而是上線前就該看的風險清單。尤其登入、上傳、圖片生成這幾類功能，一出事就會直接打到使用者體感。
實務上，最少要準備三件事。第一，版本要常更新，尤其是 Codex 這類會跟 client 綁很緊的產品。第二，重要流程要有 fallback。第三，status page 要納入值班清單，而不是出事才去翻。
OpenAI 7 月的節奏也提醒一件事：功能推得快，問題也會跟著快。這不是道德評價，是工程現實。你可以接受新模型，但不能假設它永遠穩。
接下來要盯的是穩定性，不是新名詞
我會繼續看 OpenAI 的 status history，重點放在登入、圖片生成、Codex、Moderation API 這幾條線。只要這些地方還頻繁出現事件，代表平台的壓力還沒完全消化。
如果你是開發者，現在最該做的不是追下一個模型名，而是把 retry、queue、fallback、降級路徑補好。下一次狀態頁再亮紅燈時，你的產品才不會跟著一起倒。
我的判斷很直接：接下來幾週，誰把 OpenAI 服務接得越深，誰越該把監控做細。別等使用者先發現問題。