ההתאוששות לא הייתה אחידה. שירותים מרכזיים חזרו לפעילות, בעוד ש-Copilot המשיך לסבול מבעיות אימות בחלק מהיישומים. לפי דיווחי ניטור נוספים, האירוע הכולל הסתיים בסביבות 21:15 UTC, כך שהשיבוש המלא נמשך זמן רב יותר מהשלב הראשוני של הירידה החדה בביצועים.
הנתונים הבולטים שדווחו במהלך האירוע:
במילים אחרות, ארגון שהיה תלוי ב-GitHub לא רק לאחסון קוד, אלא גם להתחברות משתמשים, להרצת בדיקות, לאוטומציות ולפריסות, עלול היה להיתקל בכשל בכמה שלבים מחוברים של תהליך הפיתוח.
גם מספרי הדיווחים באתרי ניטור התקלות השתנו לפי השעה והמקור. דיווח אחד ציין יותר מ-10,000 דיווחים ב-Downdetector עד 8:12 בבוקר לפי שעון האוקיינוס השקט, בעוד שדיווח התאוששות אחר דיבר על שיא של כמעט 3,000 דיווחים.
אין לראות במספרים האלה ספירה מדויקת של המשתמשים שנפגעו. אתרי ניטור מודדים דיווחים שהוגשו על ידי משתמשים, והסכומים משתנים לפי אזור גאוגרפי, מועד המדידה ושיטת הספירה.
האירוע החל ביום שני בבוקר בארצות הברית — תחילת שבוע העבודה עבור צוותי פיתוח רבים. זהו חלון זמן רגיש במיוחד: צוותים מתחילים את היום בגישה למאגרים, סקירות קוד, הרצות אינטגרציה רציפה ופריסה של גרסאות.
מכיוון ש-Actions, Pull Requests, APIs ו-Webhooks היו בין השירותים שנפגעו, צוותים יכלו להיתקל בכשלים בכמה שלבים עוקבים, במקום בתקלה נקודתית בפיצ'ר אחד בלבד. כך, למשל, גישה לקוד, פתיחת בקשת מיזוג והרצת תהליך בדיקות אוטומטי עלולות היו להיפגע באותו חלון זמן.
העדכונים הפומביים של GitHub מבססים שלושה דברים:
עם זאת, המידע הזמין עדיין אינו מזהה איזה רכיב כשל, אינו מפרט מה בדיוק כלל התיקון, ואינו מוכיח שלחץ קיבולת היה הגורם הישיר לאירוע המסוים הזה. הגידול בתעבורה שנוצרה על ידי כלי בינה מלאכותית ומגבלות תשתית הם חלק מדיון רחב יותר של GitHub על אמינות, אך אין להציג אותם כסיבה מוכחת לתקלה ב-17 באוגוסט לפני פרסום התחקיר הרשמי.
האירוע באוגוסט הגיע לאחר תקופה קשה מבחינת אמינות השירות. בדוח הזמינות של יולי GitHub תיעדה שמונה אירועים במהלך החודש. אחד מהם, ב-8 ביולי, נמשך יותר משבע שעות והשפיע על ממשק האתר, ה-REST API, ה-GraphQL API, Actions, Packages, Copilot ופעולות Git בסביבות מסוימות של Enterprise Cloud.
GitHub עצמה תיארה גם אתגר תשתיתי רחב יותר: התעבורה גדלה במהירות, בין היתר בשל תהליכי פיתוח בסיוע בינה מלאכותית ותהליכי פיתוח אוטונומיים יותר. בין צעדי התגובה שעליהם דיווחה החברה: העברת קיבולת נוספת ל-Azure, הפרדת שירותים והפחתת נקודות כשל משותפות.
היקף התכנון השתנה משמעותית. GitHub תכננה במקור להגדיל את הקיבולת פי 10, אך עד פברואר 2026 התברר לה שעליה לתכנן עבור קנה מידה של פי 30 מהיקפה באותה תקופה. דיווחים נוספים תיארו מאמצים הקשורים ל-Azure ולתוספת קיבולת בסביבה מרובת עננים, כולל AWS — אך התוכניות האלה אינן מסבירות כשלעצמן את תקלת אוגוסט.
המשמעות היא ש-GitHub אינה רק מקום לאחסון מאגרי Git. היא משמשת גם שכבת שיתוף פעולה, פלטפורמת אוטומציה, מערכת זהות ושירות תכנות מבוסס בינה מלאכותית. כאשר תלות משותפת נכשלת, תקלה יחידה יכולה לקטוע בו-זמנית גישה למאגרים, סקירות קוד, בנייה, פריסה, Webhooks וסיוע תכנותי.
התקלה אינה מוכיחה שמפתחים עומדים לנטוש את GitHub, והראיות הקיימות אינן מצדיקות תחזית לגל הגירה מיידי. עם זאת, היא כן ממחישה מדוע ארגונים שמסתמכים על GitHub להעברת תוכנה לסביבת ייצור צריכים לבחון מחדש את הנחות ההתאוששות שלהם.
צעדי הגנה מעשיים כוללים:
הצעדים האלה אינם מבטלים את הסיכון של תלות בפלטפורמה, אך הם עשויים לצמצם את היקף הפגיעה בתקלה הבאה.
המסקנה הסופית לגבי 17 באוגוסט תלויה בתחקיר ש-GitHub הבטיחה לפרסם. עד אז, המסקנה שניתן לבסס היא מצומצמת יותר: GitHub חוותה שיבוש שירות רחב ומתגלגל, עם פגיעה חמורה בהורדות מאגרים ובתהליכי פיתוח מחוברים; השירותים התאוששו בשלבים, והסיבה הבסיסית לתקלה עדיין לא הוסברה בפומבי.