ChatGPT ล่ม 5 ชั่วโมงครึ่ง กระทบตั้งแต่ล็อกอินถึง Agents API

วันที่ 29 กันยายน 2569 บันทึกเหตุของ OpenAI ระบุว่า ChatGPT, Codex และ OpenAI API รวมถึง Agents API เกิดอัตราข้อผิดพลาดสูง ผู้ใช้บางส่วนส่งคำขอไม่สำเร็จ เข้าสู่ระบบหรือสมัครบัญชีได้ยาก และพบงานที่ทำไม่เสร็จ ก่อนประกาศว่าบริการที่ได้รับผลกระทบทั้งหมดกู้คืนแล้ว ส่วน บันทึกของ StatusGator ให้กรอบติดตามเหตุวันที่ 29 กันยายน 2569 ตั้งแต่ 17:51 ถึง 23:21 น. UTC รวม 5 ชั่วโมง 30 นาที

สำหรับประเทศไทย กรอบเวลาของผู้ติดตามสถานะตรงกับ 00:51–06:21 น. วันที่ 30 กันยายน แต่ช่วงดังกล่าวรวมปัญหาช่องทางช่วยเหลือที่เริ่มก่อนเหตุบนแพลตฟอร์มด้วย บันทึกเหตุของแพลตฟอร์มเองเริ่มแจ้งข้อผิดพลาดเวลา 17:52 น. UTC และปิดเหตุเวลา 23:14 น. UTC หรือห่างกัน 5 ชั่วโมง 22 นาที ทั้งสองวิธีนับจึงให้เวลาสิ้นสุดต่างกันเล็กน้อย โดยไม่ได้หมายความว่าทุกฟังก์ชันใช้งานไม่ได้ตลอดช่วงนั้น

ไทม์ไลน์จากเริ่มตรวจสอบถึงกู้คืนตามเวลาไทย

อัปเดตแรกของเหตุแพลตฟอร์มปรากฏหลังเที่ยงคืนในประเทศไทยเพียงไม่นาน ลำดับเวลาต่อไปนี้แปลงจากเวลา UTC ในบันทึกเหตุเป็นเวลาไทย ซึ่งเร็วกว่า UTC เจ็ดชั่วโมง วันที่บนหน้าสถานะจึงเป็น 29 กันยายน ขณะที่ช่วงที่ผู้ใช้ไทยพบปัญหาอยู่ในเช้ามืดวันที่ 30 กันยายน

• 00:52 น. เริ่มตรวจสอบอัตราข้อผิดพลาดสูงใน ChatGPT, Codex และ API พร้อมแจ้งอาการคำขอล้มเหลว การเข้าสู่ระบบหรือสมัครบัญชีติดขัด และงานที่ไม่เสร็จ
• 01:24 น. อัปเดตขอบเขตเหตุการณ์ให้ระบุ Agents API ด้วย โดยยังอยู่ในขั้นตรวจสอบ
• 02:08 น. แจ้งว่ายังตรวจสอบข้อผิดพลาดในกลุ่มบริการเดิม และยังไม่มีประกาศว่าปัญหาคลี่คลาย
• 02:39 น. เปลี่ยนเป็นสถานะติดตามผลหลังใช้มาตรการบรรเทา ซึ่งเป็นจุดเริ่มของการเฝ้าดูการฟื้นตัว
• 04:09, 05:03 และ 05:47 น. ยังรายงานสถานะติดตามผลและการฟื้นตัวต่อเนื่อง
• 06:14 น. ปิดเหตุการณ์ พร้อมระบุว่าบริการที่ได้รับผลกระทบทั้งหมดกู้คืนแล้ว

การเปลี่ยนจากตรวจสอบเป็นติดตามผลมีความหมายต่างจากการปิดเหตุ มาตรการบรรเทาถูกใช้แล้วในช่วงแรกของการติดตาม แต่บันทึกยังคงสถานะนี้ไว้อีกหลายชั่วโมง ก่อนระบุว่ากู้คืนครบ ผู้ที่เห็นคำขอกลับมาสำเร็จบางครั้งในช่วงนั้นจึงยังไม่ควรถือว่าทุกขั้นตอนของระบบพร้อมทำงานตามปกติ การกู้คืนในประกาศสุดท้ายเป็นสถานะรวมของบริการที่อยู่ในเหตุการณ์

เวลา 5 ชั่วโมง 30 นาทีของกรอบติดตามเริ่มก่อนอัปเดตแพลตฟอร์มหนึ่งนาที และสิ้นสุดหลังประกาศปิดเหตุแพลตฟอร์มเจ็ดนาที ความต่างนี้เกิดจากขอบเขตการรวบรวมเหตุ ซึ่งรวมช่องทางช่วยเหลือเข้ากับปัญหา ChatGPT, Codex และ API หากต้องการเทียบเวลาคำขอในแอปกับเหตุของแพลตฟอร์ม ช่วง 00:52–06:14 น. ตามเวลาไทยตรงกับอัปเดตของเหตุแพลตฟอร์มโดยตรงกว่า ส่วนกรอบที่ยาวกว่าแสดงช่วงที่ผู้ติดตามสถานะบันทึกความผิดปกติที่เกี่ยวข้อง

ขอบเขตที่กระทบ: ChatGPT, Codex และ API

หน้าสถานะจัดเหตุการณ์นี้เป็นประสิทธิภาพลดลงและแยกส่วนประกอบที่ได้รับผลกระทบตามผลิตภัณฑ์ การจัดประเภทดังกล่าวสอดคล้องกับอาการข้อผิดพลาดสูง ซึ่งอาจทำให้ผู้ใช้บางรายทำงานต่อได้ ขณะที่บางรายติดตั้งแต่ขั้นตอนเข้าสู่ระบบ ชื่อส่วนประกอบในรายการบอกว่าบริการใดอยู่ในขอบเขตเหตุการณ์ แต่ไม่ได้เป็นอัตราความล้มเหลวของแต่ละส่วน และไม่ได้บอกว่าผู้ใช้ทุกคนพบอาการเดียวกัน

ใน ChatGPT รายการครอบคลุม Conversations, Login และ ChatGPT Work ตลอดจน Search, File uploads, Voice mode, GPTs, Image Generation, Deep Research, Agent และ Connectors/Apps ยังมี Codex in ChatGPT Desktop, Compliance API และ Sites อยู่ในกลุ่มเดียวกัน ผลที่ผู้ใช้มองเห็นจึงไม่จำกัดอยู่ที่หน้าสนทนา การส่งข้อความอาจล้มเหลว การเริ่มใช้งานอาจติดที่ล็อกอิน หรือฟังก์ชันที่เรียกต่อจากบทสนทนาอาจทำงานไม่เสร็จ ทั้งหมดเป็นอาการที่ต้องเทียบกับส่วนประกอบที่แอปนั้นใช้อยู่จริง

Codex ถูกแสดงแยกอีกกลุ่ม โดยมี Codex Web, Codex API, CLI และส่วนขยาย VS Code อยู่ในรายการที่ได้รับผลกระทบ ข้อนี้สำคัญต่อการอ่านอาการในเครื่องมือเขียนโค้ด เพราะความผิดพลาดที่เกิดพร้อมกันในเว็บ คำสั่ง CLI หรือส่วนขยาย อาจสัมพันธ์กับเหตุบริการกลางได้ แม้ผู้ใช้จะพบข้อความผิดพลาดจากเครื่องมือคนละชนิดกันก็ตาม ส่วน Codex ในแอปเดสก์ท็อปถูกจัดไว้ใต้กลุ่ม ChatGPT จึงต้องดูชื่อส่วนประกอบให้ตรงก่อนเทียบบันทึกเหตุ

ด้าน API มีทั้ง Chat Completions และ Responses ซึ่งใช้สร้างคำตอบ รวมถึง Agents, Embeddings, Images, Batch, Fine-tuning, Audio, Realtime, Files, Moderations และ Login การแยกรายชื่อเช่นนี้ช่วยอธิบายว่าทำไมแอปที่ยังสร้างข้อความได้บางครั้งอาจมีงานอีกขั้นตอนหยุดค้าง แอปหนึ่งอาจเรียกบริการมากกว่าหนึ่งรายการต่อคำขอของผู้ใช้ และความสำเร็จของขั้นแรกไม่ได้ยืนยันว่าขั้นถัดไปจะเสร็จในช่วงที่หลายส่วนประกอบมีข้อผิดพลาดสูง

Agents API ในรายการ API กับ Agent ในรายการ ChatGPT เป็นคนละส่วนประกอบตามการจัดหมวดบนหน้าสถานะ แม้ชื่อคล้ายกัน การแยกนี้มีผลต่อทีมที่ต้องระบุจุดล้มเหลว: งานใน ChatGPT Agent และคำขอจากแอปภายนอกที่เรียก Agents API ไม่ควรถูกนับเป็นเส้นทางเดียวกันโดยอัตโนมัติ ส่วนการเข้าสู่ระบบก็ปรากฏทั้งฝั่ง ChatGPT และ API จึงมีโอกาสที่อาการเริ่มก่อนถึงขั้นสร้างคำตอบหรือเริ่มงานของ Agent

ข้อมูลความพร้อมใช้งานบนหน้าสถานะเป็นภาพรวมข้ามระดับสมาชิก โมเดล และประเภทข้อผิดพลาด ประสบการณ์ของลูกค้าแต่ละรายอาจต่างกันตามสิทธิ์การใช้งาน โมเดล และคุณสมบัติ API ที่เรียกใช้ ด้วยเหตุนี้ รายชื่อส่วนประกอบที่ยาวจึงแสดงขอบเขตการเฝ้าระวังของเหตุการณ์ได้ดีกว่าการใช้ตัดสินว่าทุกคำขอในทุกบริการล้มเหลวเท่ากัน การวิเคราะห์ผลกระทบของแอปต้องเริ่มจากเส้นทางคำขอและเวลาที่บันทึกไว้ในระบบของแอปเอง

แยกข้อผิดพลาดของผู้ให้บริการออกจากบั๊กในแอป

สัญญาณที่มีน้ำหนักที่สุดของเหตุนี้คือการที่บริการหลายกลุ่มถูกระบุในเหตุการณ์สาธารณะเดียวกัน และเวลาที่ข้อผิดพลาดเพิ่มขึ้นตรงกับช่วงตรวจสอบหรือฟื้นตัว หากคำขอของแอปเริ่มล้มเหลวในช่วงเดียวกัน ผู้ดูแลควรจับคู่เวลาตามเขตเวลาให้ตรงก่อน แล้วระบุว่าคำขอนั้นไปยัง Responses, Agents, Files หรือส่วนประกอบอื่นที่ปรากฏในรายการหรือไม่ ความสอดคล้องของเวลาและส่วนประกอบช่วยจัดลำดับการตรวจสอบ แต่ยังไม่พิสูจน์ว่าข้อผิดพลาดทุกชนิดในแอปมาจากเหตุเดียวกัน

ข้อมูลที่ใช้แยกปัญหาควรรวมเวลาของคำขอ ปลายทาง API รหัสตอบกลับหรือข้อผิดพลาดจาก SDK และ request ID เมื่อมี หากคำขอได้รับคำตอบจากบริการพร้อมรหัสข้อผิดพลาด การตรวจจะต่างจากกรณีที่แอปเชื่อมต่อไม่ถึงปลายทางเลย ข้อมูลเหล่านี้ช่วยบอกว่าความล้มเหลวเกิดก่อนส่งคำขอ ระหว่างรอคำตอบ หรือหลังได้รับผลแล้ว อีกทั้งช่วยให้เทียบคำขอที่ล้มเหลวกับคำขอที่สำเร็จในเส้นทางเดียวกันได้

ควรดูด้วยว่าความผิดพลาดเพิ่มขึ้นพร้อมกันในหลายฟังก์ชันหรือจำกัดอยู่ที่ขั้นตอนเดียว หากปัญหาเกิดเฉพาะหลังการเปลี่ยนโค้ด การตั้งค่า หรือสิทธิ์ของแอป การตรวจการเปลี่ยนแปลงนั้นยังจำเป็น แม้ช่วงเวลาเดียวกันจะมีเหตุฝั่ง OpenAI อยู่ก็ตาม ในทางกลับกัน หากหลายเส้นทางที่ไม่ได้เปลี่ยนโค้ดเริ่มผิดพลาดพร้อมกัน และส่วนประกอบเหล่านั้นอยู่ในรายการเหตุการณ์ ข้อเท็จจริงดังกล่าวทำให้การตรวจบริการกลางมีลำดับความสำคัญสูงขึ้น

อาการล็อกอินติดขัดต้องพิจารณาแยกจากงานที่ส่งแล้วไม่เสร็จ ผู้ที่ไม่ผ่านขั้นยืนยันตัวตนอาจยังไม่เคยเรียก API สำหรับสร้างผลลัพธ์ ขณะที่งาน Agent ที่ค้างอาจเริ่มทำงานไปแล้วบางส่วนก่อนแสดงข้อผิดพลาด การรวมอาการทั้งหมดเป็นคำว่า “แอปล่ม” จะบดบังจุดที่ต้องตรวจ โดยเฉพาะระบบที่มีการส่งคำขอหลายขั้นหรือมีงานเบื้องหลังต่อจากการตอบกลับครั้งแรก

หลังประกาศกู้คืน ความผิดพลาดที่ยังเกิดเฉพาะแอปหนึ่งควรถูกตรวจจากบันทึกของแอปและสถานะคำขอจริง คำขอที่ค้างอยู่ในคิวอาจยังรอประมวลผลตามนโยบายของระบบนั้น แม้บริการต้นทางกลับมาแล้ว ขณะเดียวกัน การที่หน้าเว็บ ChatGPT ใช้งานได้อีกครั้งไม่ได้ยืนยันว่าเส้นทาง API ที่แอปใช้อยู่ตอบสนองตามที่ต้องการทันที การตรวจผลลัพธ์ปลายทางจึงต้องดูตามหน้าที่ของแต่ละคำขอ

แผนสำรองสำหรับงานที่พึ่ง OpenAI API

สำหรับผู้ใช้ API แผนรับมือควรแยกงานที่รอได้ออกจากงานที่ต้องตอบทันทีระหว่างบริการกำลังฟื้นตัว งานที่รอได้อาจพักไว้ในคิวพร้อมสถานะที่ผู้ใช้เข้าใจ ส่วนคำขอที่ต้องตอบทันทีควรมีขอบเขตเวลารอและข้อความแจ้งเมื่อทำต่อไม่ได้ การปล่อยให้ทุกคำขอส่งซ้ำพร้อมกันทันทีที่เริ่มมีความสำเร็จบางส่วน อาจทำให้แอปสร้างภาระเพิ่มและทำให้ผู้ใช้เห็นผลลัพธ์ซ้ำ

ก่อนส่งงาน Agent ซ้ำ คู่มือการกู้คืน Agents API แนะนำให้ตรวจสถานะเซสชัน เทิร์น และงานที่บันทึกไว้ รวมถึงผลของการกระทำที่อาจเสร็จไปแล้ว แม้ผู้เรียกจะเห็นข้อผิดพลาด วิธีนี้สำคัญกับงานที่เรียกเครื่องมือหรือเปลี่ยนไฟล์ เพราะการเริ่มใหม่โดยไม่รู้ผลของครั้งแรกอาจทำงานเดิมซ้ำ ข้อผิดพลาดจากคำขอ HTTP กับข้อผิดพลาดของเทิร์นที่เริ่มไปแล้วจึงต้องถูกจัดการต่างกัน

สำหรับความผิดพลาดชั่วคราว ควรกำหนดจำนวนครั้งและเวลารวมของการลองใหม่ หากการตอบกลับมีค่า Retry-After ให้รออย่างน้อยตามเวลาที่ระบุ หากไม่มีค่าให้เพิ่มระยะรอเป็นขั้นและกระจายจังหวะส่งคำขอ ไม่ควรให้การลองใหม่ของ SDK ซ้อนกับการลองใหม่ที่แอปเขียนเพิ่มจนจำนวนคำขอทวีขึ้น งานที่ไม่ทราบผลสำเร็จของครั้งแรกควรถูกพักไว้เพื่อตรวจสถานะก่อน มากกว่าส่งคำสั่งเดียวกันอีกทันที

การสลับไปใช้เส้นทางสำรองต้องอิงความสามารถของขั้นตอนที่ล้มเหลว หากแอปพึ่ง Agents API เพื่อทำงานหลายขั้น การส่งข้อความธรรมดาผ่าน API อีกชนิดอาจให้คำตอบได้ แต่ไม่เท่ากับทำงานเดิมเสร็จ ระบบควรแสดงสถานะตามจริงว่าขั้นตอนไหนสำเร็จ ขั้นตอนไหนรอ และขั้นตอนไหนต้องให้ผู้ใช้เริ่มใหม่ การแยกเช่นนี้ช่วยรักษาผลลัพธ์ที่สำเร็จแล้วและลดโอกาสทำงานซ้ำโดยไม่จำเป็น

เหตุการณ์นี้ยังชี้ให้เห็นความสำคัญของการเฝ้าดูผลลัพธ์แยกตามส่วนประกอบที่ใช้งานจริง ตัวชี้วัดรวมของแอปอาจดูปกติหากคำขอส่วนใหญ่ยังสำเร็จ แต่เส้นทางที่พึ่ง Login, Files หรือ Agents อาจมีข้อผิดพลาดสูงกว่าปกติได้ การบันทึกเวลา ปลายทาง สถานะคำขอ และผลลัพธ์หลังลองใหม่ ทำให้ทีมแยกการฟื้นตัวของบริการต้นทางออกจากงานตกค้างในระบบของตนได้

บันทึกปิดเหตุระบุว่าจะเผยแพร่การวิเคราะห์สาเหตุโดยละเอียดภายในห้าวันทำการ รายงานนั้นจะเป็นข้อมูลสำหรับระบุสาเหตุและลำดับการแก้ไขทางเทคนิคอย่างเป็นทางการ ระหว่างนี้ การตัดสินใจเรื่องงานค้าง การลองใหม่ และเส้นทางสำรองควรอิงสถานะคำขอที่สังเกตได้จริง มากกว่าคาดเดาว่าส่วนใดของโครงสร้างบริการเป็นต้นเหตุ

อ่านเพิ่มเติม:

• Gemini 3.8 Live สร้างอวตารสดได้ 97 ภาษา แต่ API ยังมีเงื่อนไข
• DigitalOcean เปิด Managed Agents แต่ Public Preview ยังไม่มี SLA
• ChatGPT Search หรือ Perplexity: ลิงก์เยอะไม่ได้แปลว่าอ้างอิงแม่น