GitHub เกิดเหตุขัดข้องอีกครั้ง

 (githubstatus.com)
1 คะแนน โดย GN⁺ 2026-02-10 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีรายงานว่า บางบริการของ GitHub ทำงานช้าลง และเกิด ความล่าช้าในการส่งการแจ้งเตือน (Notification)
  • เวลาแฝงเฉลี่ยเพิ่มขึ้นจากราว 50 นาที ในช่วงแรก ไปสูงสุดที่ 1 ชั่วโมง 20 นาที
  • หลังจากนั้นมีการกู้คืนอย่างค่อยเป็นค่อยไป โดยความล่าช้าลดลงเป็น 1 ชั่วโมง → 30 นาที → 15 นาที
  • มีรายงานว่าแก้ไขปัญหาและ ปิดเหตุการณ์ แล้วเมื่อ 9 กุมภาพันธ์ 2026 เวลา 19:29 น. ตาม UTC
  • GitHub เตรียมเผยแพร่ การวิเคราะห์สาเหตุราก (RCA) ในภายหลัง

ภาพรวมของเหตุการณ์การแจ้งเตือนล่าช้าบน GitHub

  • GitHub รายงานว่าเกิด ประสิทธิภาพลดลง ในบางบริการ
    • ในระยะแรก การส่งการแจ้งเตือนไม่เป็นไปตามปกติ
    • ขณะนั้นยังอยู่ระหว่างการตรวจสอบสาเหตุของปัญหา

ความคืบหน้าของการแจ้งเตือนล่าช้า

  • ในการอัปเดตครั้งแรก ระบุว่ามี ความล่าช้าเฉลี่ย 50 นาที
    • GitHub ระบุว่ากำลังดำเนินมาตรการบรรเทาผลกระทบ
  • ในการอัปเดตถัดมา ความล่าช้าแย่ลงเป็น 1 ชั่วโมง 20 นาที แต่เริ่มเห็น สัญญาณการฟื้นตัว
  • จากนั้นระบบค่อย ๆ ฟื้นตัว ทำให้เวลาล่าช้าลดลงจาก 1 ชั่วโมง → 30 นาที → 15 นาที
    • อธิบายว่ากำลังประมวลผลแบ็กล็อก (การแจ้งเตือนที่ค้างสะสม)
  • สุดท้าย ปัญหาการแจ้งเตือนล่าช้าได้รับการแก้ไข และกลับมาส่งได้ตามปกติ

การปิดเหตุการณ์และการดำเนินการต่อเนื่อง

  • เหตุการณ์นี้ ได้รับการแก้ไขสมบูรณ์ เมื่อ 9 กุมภาพันธ์ 2026 เวลา 19:29 น. ตาม UTC
  • GitHub แสดงความ ขอบคุณต่อความอดทนและความเข้าใจ ของผู้ใช้
  • ผลการ วิเคราะห์สาเหตุราก (Root Cause Analysis) จะเผยแพร่เมื่อพร้อม

การแจ้งเตือนผู้ใช้และฟังก์ชันการสมัครรับอัปเดต

  • ผู้ใช้สามารถ สมัครรับอัปเดตของเหตุการณ์ ผ่านอีเมล, SMS, Slack, Webhook เป็นต้น
  • การสมัครรับอัปเดตถือเป็นการยอมรับ นโยบายความเป็นส่วนตัว และ ข้อกำหนดการให้บริการ ของ GitHub และ Atlassian
  • เว็บไซต์นี้ได้รับการปกป้องด้วย Google reCAPTCHA

สรุป

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

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
joyfui 2026-02-10

ดูเหมือนว่าไม่ใช่แค่ผมคนเดียวที่เจอ GitHub โยนข้อผิดพลาดออกมาตอนช่วงเช้ามืดวันนี้
 
GN⁺ 2026-02-10
ความคิดเห็นจาก Hacker News

  • GitHub เลิกเปิดเผย สถิติ uptime ของบริการ แล้ว ผมเลยลองพาร์สข้อมูลเอง
    ตอนนี้ถ้ามองทั้งบริการรวมกันก็น่าจะอยู่ระดับ ‘single 9’
    ดูได้ที่ หน้า GitHub Statuses

    • ทำให้นึกถึงหน้า GitHub status แบบเก่า ตอนนั้นเขาแสดง เวลาให้บริการจริง อย่างโปร่งใส และก็ไม่น่าแปลกใจที่พอความจริงเริ่มปรากฏ หน้าดังกล่าวก็ถูกแทนที่ด้วยหน้าแบบปัจจุบัน
      ผมได้อ่าน คำอธิบายลิงก์ archive.org แล้วด้วย
    • การเรียกรวมทั้งบริการว่าอยู่ระดับ ‘single 9’ นั้น ไม่มีความหมายในแง่วิธีคำนวณ uptime
      ตัวเลขรายหมวดพอมีประโยชน์ แต่การรวมทุกบริการเป็นตัวชี้วัดเดียวไม่มีความหมาย
      ส่วนใหญ่เกิน 99.5% มีแค่ Copilot ที่ดูเป็นข้อยกเว้น
    • น่าสนใจที่ตัวเลขรวมของ Copilot ต่ำสุด
      ผมใช้ทุกวันแต่แทบไม่รู้สึกว่ามีปัญหา อาจเป็นเพราะ เวลาที่บันทึก incident ถูกสะท้อนช้าก็ได้
    • ไม่เข้าใจว่าทำไม downtime วันนี้ถึงถูกจัดเป็น ‘minor’
      ทั้งที่เว็บ UI แทบใช้งานไม่ได้เลย เลยสงสัยว่า GitHub กำลังรายงาน ความรุนแรงของ incident ต่ำกว่าความเป็นจริงหรือเปล่า
    • เป็นโปรเจ็กต์ที่ยอดเยี่ยม ขอบคุณที่แชร์

  • เมื่อไม่กี่ปีก่อน ผมยังไม่คิดว่า อำนาจครอบงำ ของ GitHub จะถูกสั่นคลอน
    แต่ถ้ายังปฏิบัติการได้ไม่เสถียรแบบตอนนี้ ก็น่าจะถูกจดจำว่าเป็น การทำร้ายตัวเอง ครั้งใหญ่ของวงการ

    • หลังการย้ายระบบครั้งใหญ่ไป Azure เมื่อปีก่อน ดูเหมือน ระดับ uptime จะตกลงไปหนึ่งถึงสองขั้น
    • ตอนนี้ผมกำลังดูหน้า “Migrate from GitHub” ในเอกสารของ GitLab
      ถ้าย้ายทั้ง issue และ project ได้ด้วย ผมก็คิดจะย้ายจริงจัง
    • ผมมองว่านี่ไม่ใช่แค่ปัญหาด้านการปฏิบัติการ แต่เป็นปัญหาเรื่อง สถาปัตยกรรมและคุณภาพโค้ด
      แค่ดูผลิตภัณฑ์ GitHub Enterprise แบบ self-hosted ก็พอจะเห็นความซับซ้อนได้
    • ไม่มีหลักฐาน แต่ผมเดาว่าเหตุขัดข้องถี่ ๆ ช่วงหลังอาจเป็นผลข้างเคียงจาก กลยุทธ์ที่เน้น AI
    • ผมคิดว่าเป็นผลจากการที่ Microsoft บังคับย้ายไป Azure และให้ workload ด้าน AI มาก่อน
      GitHub คือ ห่านทองคำ ของข้อมูลนักพัฒนาทั่วโลก แต่ถ้ายังไม่เสถียรแบบนี้ ตัวแฟรนไชส์เองก็เสี่ยง
      Windows 11 ก็ไม่ดีนัก และ GitHub อาจสูญเสียบทบาทการเป็นรากฐานของการพัฒนาสมัยใหม่ได้

  • ตอนกำลังจัดการ ช่องโหว่ความปลอดภัย ของ Caddy อยู่ GitHub ก็ดันล่ม พอเปิดรายงานก็เห็นแต่หน้ายูนิคอร์น
    ผมตั้งใจจะโฟกัสในช่วง 2 ชั่วโมงที่ไม่มีลูกอยู่บ้าน แต่ incident นี้ทำให้กังวลว่า feedback loop จะเลื่อนไปถึงพรุ่งนี้
    ถึงอย่างนั้นก็ยังรู้สึกขอบคุณที่ GitHub Sponsors ช่วยให้ผมเลี้ยงชีพได้

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

  • ตอนนี้เหมือนได้เห็น GitHub แตกเป็นชิ้น ๆ แล้วระเบิด แบบเรียลไทม์
    หน้า GitHub Status History แทบจะตลกเสียแล้ว

    • เพิ่งวันที่ 9 กุมภาพันธ์ แต่มี incident ไปแล้ว 14 รายการ
      มันช่างย้อนแย้งที่ได้เห็นช่วง ‘ผู้กอบกู้โลก’ ของอุตสาหกรรม AI ไหลไปแบบนี้อีกครั้ง
      บทความที่เกี่ยวข้อง: ลิงก์ The Verge
    • มีคนแซวว่าถ้าจะกลับเทรนด์นี้ได้ คงต้องทำ vibe coding ให้มากขึ้น
    • ถึงอย่างนั้นก็ยังดีที่ GitHub เปิดเผยอย่างโปร่งใส
      ไม่ได้ปิดบัง downtime จึงยังพอรับมือได้ และคงจะมี postmortem ตามมาเร็ว ๆ นี้
    • น่าจะยังเป็นแบบนี้ต่อไปจนกว่าการย้ายไป Azure จะเสร็จ
    • อยากให้มีภาพรวมรายปีแบบเดียวกับ กราฟ contribution บนโปรไฟล์ GitHub

  • ตั้งแต่ต้นปีมานี้ GitHub มี incident มากจนแทบจะ อัปเดต status page ทุกวัน
    ดูจาก ประวัติสถานะ แล้ว นี่ไม่ถือว่าปกติแม้สำหรับบริการขนาดใหญ่
    ถึงขั้นมีมุกว่าประมาณสี่โมงเย็นของทุกวัน GitHub Actions จะหยุดทำงาน
    อยากให้ภายในออกมาเปิดเผยสาเหตุและมาตรการรับมือ

    • หลังการมาของ coding agent เป็นไปได้สูงว่า ทราฟฟิกฝั่งปฏิบัติการเพิ่มขึ้น 100 เท่า
      เดิมที GitHub ถูกออกแบบมาสำหรับอีกขนาดหนึ่ง แต่จู่ ๆ ก็ต้องรับภาระในอีกระดับไปเลย

  • ในหน้า status ตอนแรกแสดงแค่ว่า การแจ้งเตือนล่าช้า แต่จริง ๆ แล้วพอเข้า PR ก็ขึ้นแต่หน้ายูนิคอร์นตลอด
    หลังจากนั้นจึงมี status page แยกเกี่ยวกับ PR และสุดท้ายก็ขยายเป็นปัญหาทั้งบริการ
    ลิงก์ incident ที่เกี่ยวข้อง

    • มีการเพิ่มรายการว่า “กำลังตรวจสอบประสิทธิภาพการทำงานที่ลดลงของบางบริการ”
      ตอน UTC 16:10 ยังไม่มี แต่ไม่กี่นาทีถัดมาก็โผล่มา
    • ตอน approve PR นั้น JSON API กลับคืนหน้า error แบบ HTML ดูเหมือนระบบภายในจะพันกันหมดแล้ว
    • ผมเองก็เจอ 500 error บ่อยมาก และ latency ก็พุ่งขึ้นด้วย
      ลิงก์มอนิเตอร์
    • ตอนเข้าไปดูรายละเอียด commit ก็ขึ้นแต่หน้ายูนิคอร์นเหมือนกัน
    • แม้แต่คำสั่ง git เองก็ใช้ไม่ได้

  • ช่วงไม่กี่สัปดาห์ที่ผ่านมา ผมย้ายไป Forgejo เสร็จเรียบร้อยแล้ว
    บริษัทเราพยายามลดการพึ่งพาคลาวด์รายใหญ่ ดังนั้นการที่โครงสร้างพื้นฐานหลักหยุดเพราะ GitHub/Azure ล่มจึงเป็นเรื่องรับไม่ได้
    กระบวนการย้ายเป็นไปอย่างราบรื่น และเราก็กำลังทำ งานพัฒนาแบบคัสตอม บางอย่างอยู่

    1. สร้าง runner บน Firecracker เพื่อให้ Forgejo Actions รัน CI ในสภาพแวดล้อมแบบ VM
    2. กำลังเตรียมข้อเสนอเพื่อเพิ่ม ฟีเจอร์กลุ่มตัวแปรสภาพแวดล้อม
      คอมมูนิตี้เป็นมิตรมาก และหวังว่า Forgejo จะเติบโตยิ่งขึ้น
      ลิงก์บริษัท, ลิงก์ข้อเสนออภิปราย
    • ถ้าอยู่ลอนดอน ทำไมถึงใช้โดเมน .eu แล้วเซิร์ฟเวอร์อยู่ที่ไหน และใช้ผู้ให้บริการโฮสติ้งรายใด

  • ตอนนี้ ความไม่เสถียร ของ GitHub เป็นสิ่งที่ยอมรับไม่ได้แล้ว
    ถ้าต่อไปผมมีอิทธิพลต่อการเลือกที่เก็บโค้ด ผมจะพยายามหลีกเลี่ยง GitHub

    • ความสามารถต่าง ๆ บน forge อื่นก็ทดแทนได้เพียงพอ
      แต่ ความสามารถในการถูกค้นพบ และ สัญญาณทางสังคม (ดาว, fork) ของ GitHub ยังมีเสน่ห์อยู่
      วิธีที่ใช้งานได้จริงคือใช้ forge ภายใน (GitLab, Gitea ฯลฯ) แล้ว mirror ไป GitHub
      น่าแปลกดีที่ถ้า GitHub ดีกว่านี้ผมคงใช้แผนเสียเงิน แต่ตอนนี้กลับใช้ฟรีแล้วเอาเงินไปจ่ายที่อื่น

  • ในช่วง 3 เดือนที่ผ่านมา มี เหตุขัดข้องครั้งใหญ่ 3 ครั้ง
    มีระบุไว้อย่างชัดเจนใน ประวัติสถานะ

    • สงสัยว่าช่วงนี้ในทีมมีใครลาออกไปหรือเปล่า บางที คนที่ถือความรู้สำคัญ อาจหายไป หรือไม่ก็ย้ายงานปฏิบัติการไปภูมิภาคอื่น
    • อีกสองสัปดาห์ก็จะปล่อย MVP แล้ว แต่ดันมาเจอ incident อีก น่าหงุดหงิดมาก ความน่าเชื่อถือ ต่ำเกินไป
    • มีคนปิดท้ายมุกว่า หรือว่านี่ก็เป็นเพราะ vibe coding อีกเหมือนกัน

  • สถานการณ์ตอนนี้ดูเหมือนเป็นผลจาก AI มาแทนวิศวกร จริง ๆ

    • มีคนสวนกลับติดตลกว่า “ใช่ ขอโทษนะ ฉันลบฐานข้อมูลของคุณไปแล้ว”
    • แต่ในความเป็นจริง เท่าที่ผมรู้ GitHub กำลัง ย้ายไป Microsoft Azure เลยเกิด downtime แบบนี้
    • เป็นการเสียดสีราวกับว่า Tay.ai กับ Zoe.ai กำลังตีกันอยู่ข้างในจนดูแลบริการไม่ไหว