בהמשך מסרה GitHub כי זיהתה את הרכיב שהיה מעורב בתקלה ונקטה צעדי תיקון. בעדכון שפורסם בשעה 12:36 בצהריים לפי שעון החוף המזרחי נאמר כי ניכרים סימנים חזקים להתאוששות, אך השירות עדיין לא התייצב לחלוטין.

ההתאוששות לא הייתה אחידה. שירותים מרכזיים חזרו לפעילות, בעוד ש-Copilot המשיך לסבול מבעיות אימות בחלק מהיישומים. לפי דיווחי ניטור נוספים, האירוע הכולל הסתיים בסביבות 21:15 UTC, כך שהשיבוש המלא נמשך זמן רב יותר מהשלב הראשוני של הירידה החדה בביצועים.

אילו שירותים נפגעו?

הנתונים הבולטים שדווחו במהלך האירוע:

• האתר ותעבורת ה-API: שיעור שגיאות של כ-20%.
• הורדות ארכיונים ותוכן גולמי ממאגרים: שיעור שגיאות של כ-50%.
• כלי פיתוח ושיתוף פעולה: Pull Requests, Issues, Actions, Webhooks, פעולות Git ו-Pages נפגעו בדרגות שונות.
• סיוע תכנות מבוסס בינה מלאכותית: GitHub Copilot נפגע, והמשיך להיות מוקד תקלה גם לאחר שחלק משירותי הליבה התאוששו.
• זהות ארגונית: דיווחים הצביעו על שיבושים באימות SAML ו-OIDC, בהקצאת משתמשים באמצעות SCIM וב-Team Sync. הדבר עלול היה למנוע מארגונים להתחבר באופן אמין או לנהל הרשאות משתמשים.

במילים אחרות, ארגון שהיה תלוי ב-GitHub לא רק לאחסון קוד, אלא גם להתחברות משתמשים, להרצת בדיקות, לאוטומציות ולפריסות, עלול היה להיתקל בכשל בכמה שלבים מחוברים של תהליך הפיתוח.

כמה דיווחים נרשמו — ולמה קשה להשוות בין המספרים?

גם מספרי הדיווחים באתרי ניטור התקלות השתנו לפי השעה והמקור. דיווח אחד ציין יותר מ-10,000 דיווחים ב-Downdetector עד 8:12 בבוקר לפי שעון האוקיינוס השקט, בעוד שדיווח התאוששות אחר דיבר על שיא של כמעט 3,000 דיווחים.

אין לראות במספרים האלה ספירה מדויקת של המשתמשים שנפגעו. אתרי ניטור מודדים דיווחים שהוגשו על ידי משתמשים, והסכומים משתנים לפי אזור גאוגרפי, מועד המדידה ושיטת הספירה.

התזמון הוסיף שמן למדורה

האירוע החל ביום שני בבוקר בארצות הברית — תחילת שבוע העבודה עבור צוותי פיתוח רבים. זהו חלון זמן רגיש במיוחד: צוותים מתחילים את היום בגישה למאגרים, סקירות קוד, הרצות אינטגרציה רציפה ופריסה של גרסאות.

מכיוון ש-Actions, Pull Requests, APIs ו-Webhooks היו בין השירותים שנפגעו, צוותים יכלו להיתקל בכשלים בכמה שלבים עוקבים, במקום בתקלה נקודתית בפיצ'ר אחד בלבד. כך, למשל, גישה לקוד, פתיחת בקשת מיזוג והרצת תהליך בדיקות אוטומטי עלולות היו להיפגע באותו חלון זמן.

מה GitHub עשתה — ומה עדיין לא הוסבר

העדכונים הפומביים של GitHub מבססים שלושה דברים:

1. מהנדסי החברה חקרו בעיות ביצועים ועלייה בשיעורי השגיאות בכמה שירותים.
2. החברה זיהתה רכיב בעייתי ונקטה פעולה מתקנת.
3. גם לאחר התאוששותם של שירותי הליבה, GitHub המשיכה להפעיל אמצעי מיתון — ובהם טיפול בתקלות אימות אקראיות ב-Copilot.

עם זאת, המידע הזמין עדיין אינו מזהה איזה רכיב כשל, אינו מפרט מה בדיוק כלל התיקון, ואינו מוכיח שלחץ קיבולת היה הגורם הישיר לאירוע המסוים הזה. הגידול בתעבורה שנוצרה על ידי כלי בינה מלאכותית ומגבלות תשתית הם חלק מדיון רחב יותר של GitHub על אמינות, אך אין להציג אותם כסיבה מוכחת לתקלה ב-17 באוגוסט לפני פרסום התחקיר הרשמי.

חלק מבעיה רחבה יותר ב-2026

האירוע באוגוסט הגיע לאחר תקופה קשה מבחינת אמינות השירות. בדוח הזמינות של יולי 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 להעברת תוכנה לסביבת ייצור צריכים לבחון מחדש את הנחות ההתאוששות שלהם.

צעדי הגנה מעשיים כוללים:

• שמירה על גיבויים או מראות של מאגרים;
• שימוש בתצורות CI/CD שניתן להעביר לפלטפורמות אחרות;
• תיעוד נוהלי שחרור חירום;
• הכנת חלופות למצבים שבהם SSO, Webhooks או runners מתארחים אינם זמינים.

הצעדים האלה אינם מבטלים את הסיכון של תלות בפלטפורמה, אך הם עשויים לצמצם את היקף הפגיעה בתקלה הבאה.

המסקנה הסופית לגבי 17 באוגוסט תלויה בתחקיר ש-GitHub הבטיחה לפרסם. עד אז, המסקנה שניתן לבסס היא מצומצמת יותר: GitHub חוותה שיבוש שירות רחב ומתגלגל, עם פגיעה חמורה בהורדות מאגרים ובתהליכי פיתוח מחוברים; השירותים התאוששו בשלבים, והסיבה הבסיסית לתקלה עדיין לא הוסברה בפומבי.

בהמשך מסרה GitHub כי זיהתה את הרכיב שהיה מעורב בתקלה ונקטה צעדי תיקון. בעדכון שפורסם בשעה 12:36 בצהריים לפי שעון החוף המזרחי נאמר כי ניכרים סימנים חזקים להתאוששות, אך השירות עדיין לא התייצב לחלוטין.

ההתאוששות לא הייתה אחידה. שירותים מרכזיים חזרו לפעילות, בעוד ש-Copilot המשיך לסבול מבעיות אימות בחלק מהיישומים. לפי דיווחי ניטור נוספים, האירוע הכולל הסתיים בסביבות 21:15 UTC, כך שהשיבוש המלא נמשך זמן רב יותר מהשלב הראשוני של הירידה החדה בביצועים.

אילו שירותים נפגעו?

הנתונים הבולטים שדווחו במהלך האירוע:

• האתר ותעבורת ה-API: שיעור שגיאות של כ-20%.
• הורדות ארכיונים ותוכן גולמי ממאגרים: שיעור שגיאות של כ-50%.
• כלי פיתוח ושיתוף פעולה: Pull Requests, Issues, Actions, Webhooks, פעולות Git ו-Pages נפגעו בדרגות שונות.
• סיוע תכנות מבוסס בינה מלאכותית: GitHub Copilot נפגע, והמשיך להיות מוקד תקלה גם לאחר שחלק משירותי הליבה התאוששו.
• זהות ארגונית: דיווחים הצביעו על שיבושים באימות SAML ו-OIDC, בהקצאת משתמשים באמצעות SCIM וב-Team Sync. הדבר עלול היה למנוע מארגונים להתחבר באופן אמין או לנהל הרשאות משתמשים.

במילים אחרות, ארגון שהיה תלוי ב-GitHub לא רק לאחסון קוד, אלא גם להתחברות משתמשים, להרצת בדיקות, לאוטומציות ולפריסות, עלול היה להיתקל בכשל בכמה שלבים מחוברים של תהליך הפיתוח.

כמה דיווחים נרשמו — ולמה קשה להשוות בין המספרים?

גם מספרי הדיווחים באתרי ניטור התקלות השתנו לפי השעה והמקור. דיווח אחד ציין יותר מ-10,000 דיווחים ב-Downdetector עד 8:12 בבוקר לפי שעון האוקיינוס השקט, בעוד שדיווח התאוששות אחר דיבר על שיא של כמעט 3,000 דיווחים.

אין לראות במספרים האלה ספירה מדויקת של המשתמשים שנפגעו. אתרי ניטור מודדים דיווחים שהוגשו על ידי משתמשים, והסכומים משתנים לפי אזור גאוגרפי, מועד המדידה ושיטת הספירה.

התזמון הוסיף שמן למדורה

האירוע החל ביום שני בבוקר בארצות הברית — תחילת שבוע העבודה עבור צוותי פיתוח רבים. זהו חלון זמן רגיש במיוחד: צוותים מתחילים את היום בגישה למאגרים, סקירות קוד, הרצות אינטגרציה רציפה ופריסה של גרסאות.

מכיוון ש-Actions, Pull Requests, APIs ו-Webhooks היו בין השירותים שנפגעו, צוותים יכלו להיתקל בכשלים בכמה שלבים עוקבים, במקום בתקלה נקודתית בפיצ'ר אחד בלבד. כך, למשל, גישה לקוד, פתיחת בקשת מיזוג והרצת תהליך בדיקות אוטומטי עלולות היו להיפגע באותו חלון זמן.

מה GitHub עשתה — ומה עדיין לא הוסבר

העדכונים הפומביים של GitHub מבססים שלושה דברים:

1. מהנדסי החברה חקרו בעיות ביצועים ועלייה בשיעורי השגיאות בכמה שירותים.
2. החברה זיהתה רכיב בעייתי ונקטה פעולה מתקנת.
3. גם לאחר התאוששותם של שירותי הליבה, GitHub המשיכה להפעיל אמצעי מיתון — ובהם טיפול בתקלות אימות אקראיות ב-Copilot.

עם זאת, המידע הזמין עדיין אינו מזהה איזה רכיב כשל, אינו מפרט מה בדיוק כלל התיקון, ואינו מוכיח שלחץ קיבולת היה הגורם הישיר לאירוע המסוים הזה. הגידול בתעבורה שנוצרה על ידי כלי בינה מלאכותית ומגבלות תשתית הם חלק מדיון רחב יותר של GitHub על אמינות, אך אין להציג אותם כסיבה מוכחת לתקלה ב-17 באוגוסט לפני פרסום התחקיר הרשמי.

חלק מבעיה רחבה יותר ב-2026

האירוע באוגוסט הגיע לאחר תקופה קשה מבחינת אמינות השירות. בדוח הזמינות של יולי 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 להעברת תוכנה לסביבת ייצור צריכים לבחון מחדש את הנחות ההתאוששות שלהם.

צעדי הגנה מעשיים כוללים:

• שמירה על גיבויים או מראות של מאגרים;
• שימוש בתצורות CI/CD שניתן להעביר לפלטפורמות אחרות;
• תיעוד נוהלי שחרור חירום;
• הכנת חלופות למצבים שבהם SSO, Webhooks או runners מתארחים אינם זמינים.

הצעדים האלה אינם מבטלים את הסיכון של תלות בפלטפורמה, אך הם עשויים לצמצם את היקף הפגיעה בתקלה הבאה.

המסקנה הסופית לגבי 17 באוגוסט תלויה בתחקיר ש-GitHub הבטיחה לפרסם. עד אז, המסקנה שניתן לבסס היא מצומצמת יותר: GitHub חוותה שיבוש שירות רחב ומתגלגל, עם פגיעה חמורה בהורדות מאגרים ובתהליכי פיתוח מחוברים; השירותים התאוששו בשלבים, והסיבה הבסיסית לתקלה עדיין לא הוסברה בפומבי.