ChatGPT 9月15日異常：逾2,000筆回報，不等於全面當機

9月15日（週二），ChatGPT 傳出一波短暫的使用異常。當時不少人直接在 Google 搜尋「Is ChatGPT down?」，Downdetector 在中午至下午的高峰前後累計收到超過 2,000 筆與 OpenAI 有關的問題回報；同時報導指出，約 85% 的申訴與 ChatGPT 有關。3537

不過，這個數字是故障追蹤網站收到的使用者回報數，並不是實際受影響使用者總數，更不能據此推論有多少比例的所有 ChatGPT 使用者無法使用服務。3537

使用者遇到問題，但未證實為全面性故障

現有資訊可支持的結論是：至少部分 ChatGPT 使用者在短時間內遇到存取或使用摩擦；但沒有證據能證明所有使用者都受影響，也沒有公開資料確認根本原因。

在回報量攀升時，OpenAI 的公開狀態檢查頁面據報仍顯示「未察覺系統有問題」。37 不過，OpenAI 的官方事故紀錄確實另列一宗 9 月 15 日的輕微事件：付費方案的 GPT-5.6 與 GPT-5.6 Instant 在 07:12 至 07:53 UTC 出現較高錯誤率。17 已公開的資訊並未清楚證明，這起較早的模型事件與後來的回報高峰屬於同一件事。

這正是解讀「服務掛了嗎？」時最容易混淆的地方：群眾回報可能先反映真實的使用障礙；官方狀態頁則通常要等到問題經確認、達到內部通報門檻，或可歸類至特定元件後，才會列為事故。

為何各種狀態工具給出不同答案？

9月15日的訊號並不一致，但未必彼此衝突，因為每種工具看到的是服務的不同切面：

• **群眾回報平台：**Downdetector 的逾 2,000 筆回報表示，許多人在相近時間遇到問題；其中一篇報導稱約 85% 被歸為 ChatGPT 相關。35
• **官方狀態頁：**OpenAI 的公開頁面在回報高峰時被報導為沒有已知異常；但官方事故資料另記錄了稍早影響付費方案 GPT-5.6 與 GPT-5.6 Instant 的事件。1737
• **第三方追蹤器：**Entireweb 在 9 月 15 日將 ChatGPT 標示為效能降級，稱過去 24 小時有 140 筆回報、前一小時有 11 筆。9 StatusGator 則一面顯示服務已恢復正常，一面顯示過去 24 小時有 201 筆使用者提交的回報。16
• **自動化監測：**UptimeRobot 表示，其北美探測點可正常連上 chatgpt.com，未發現異常回應時間或錯誤碼。3

例如，首頁能正常開啟，並不代表每位使用者都能登入、載入對話、使用指定模型或取得回覆；反過來說，群眾回報可以捕捉到地區性、帳戶層級或特定功能的問題，但也無法單獨證明存在一個共同的基礎設施故障。

與9月3日的大規模事故相比，規模小得多

9月3日是更明確、規模也大得多的一次事故。Downdetector 回報數在太平洋時間上午 7 時 53 分超過 5,000 筆，約 10 分鐘後突破 22,000 筆，至上午 8 時 23 分則據報超過 74,000 筆。32 另有報導指出，美東時間上午 11 時左右，ChatGPT 的回報量超過 37,000 筆。33

與9月15日不同的是，OpenAI 當時承認 ChatGPT 與 Codex 出現問題。OpenAI 表示，太平洋時間上午約 7 時 43 分起，一項路由錯誤讓部分使用者無法使用 ChatGPT 和 Codex；約上午 8 時 17 分已部署緩解措施，並持續監看復原情況。147

同一上午，Claude 與 Grok 也發生重疊的服務中斷，Gemini 則出現使用者錯誤回報。然而，沒有任何業者公開說明或可靠證據確認，四項服務都由 Microsoft Azure East US 的單一事故所致；報導反而指出，並未確認有一場廣泛的 Azure 中斷可解釋所有服務的異常。4144

「90天內58宗事故」該怎麼看？

一個獨立追蹤平台統計，ChatGPT 在此前 90 天內有 58 宗事故，包括 1 宗重大事故與 57 宗輕微事故。27 這個數字應審慎解讀：不同第三方平台採用的服務範圍、事件定義與計數方法不盡相同；另一個彙整 OpenAI 官方狀態頁資料的平台則顯示 25 宗事件。21

比起執著單一總數，更值得注意的是 OpenAI 的狀態歷史確實顯示多種產品與功能反覆出現事故，包括 ChatGPT、付費方案模型、Work Mode、圖像生成、檔案上傳與 API 服務。1720

對日常工作依賴 AI 的實際提醒

9月15日的回報高峰足以干擾部分使用者，並推升「ChatGPT 是否當機」的搜尋熱度；但它不足以證明是所有人都受影響的全面故障，也沒有證據支持 Azure 相關故障的說法。OpenAI 並未公開技術說明，將當日下午的使用者回報高峰連結到某個具體原因。

對把 AI 納入工作流程的個人與團隊而言，較穩妥的做法是同時觀察多個訊號：

1. 查看供應商狀態頁，掌握已確認的事故；
2. 使用獨立監測工具，確認網站或端點是否可連線；
3. 參考群眾回報，了解真實使用者是否正遇到障礙；
4. 對時效性高的工作預先保留替代工具或人工流程。

服務可能在某個地區、帳戶類型或工作流程中失效，卻仍可在另一處正常運作；這正是 AI 已成為日常基礎工具後，可靠性與資訊透明度必須面對的現實。