Dürüst konuşayım — GitHub’ın status sayfasına bakıp “burası bana bir şey anlatmıyor” dediğim çok oldu. Bilhassa de geçen yıl yaşadığımız Actions kesintisinde ekibin başına kaldığımda, sayfa “partial outage” diyordu ama aslında servisin %90’ı çalışıyordu (ben de ilk duyduğumda şaşırmıştım). Müşteri panik, ben panik, herkes panik. Halbuki durum o kadar da vahim değildi.
İşte tam bu noktada GitHub’dan güzel bir haber geldi. Jakub Oleksy imzalı duyuruyla birlikte, status sayfasında üç önemli değişikliğe gidiliyor. Hem de bunlar, yıllardır DevOps ekiplerinin homurdandığı konulara birebir dokunuyor.
Bakın şimdi, işin aslı şu: GitHub artık sadece kod barındıran bir yer değil. Copilot var, Actions var, Packages var, Codespaces var (ciddiyim). Ve bunların hepsi farklı seviyelerde — kendi adıma konuşayım — arıza yaşayabiliyor (buna dikkat edin). Tek bir “outage” etiketiyle bunu anlatmaya çalışmak, 2025 yılında biraz ilkel kaçıyordu.
Neler değişiyor? Üç madde, büyük etki
GitHub’ın yaptığı değişiklikleri kısaca özetleyeyim, sonra tek tek kazıyacağız:
- “Degraded Performance” adında yeni bir arıza seviyesi geldi. Yani artık her sorun otomatik olarak “outage” sayılmıyor.
- Her servis için ayrı uptime yüzdeleri — son 90 günün fotoğrafı artık status sayfasında.
- Copilot AI Model Providers diye yepyeni bir bileşen geldi. Yani OpenAI veya Anthropic tarafında bir şey olduğunda, artık “Copilot çökmüş” paniğine gerek kalmıyor.
İlk bakışta ufak düzenlemeler gibi duruyor değil mi? Bana sorarsanız, özellikle kurumsal kullanıcılar için bu değişiklikler SLA takibini baştan aşağı etkiliyor. Küçük gibi görünüyor ama öyle pek küçük değil.
Degraded Performance: Neden bu kadar önemli?
Önceden GitHub’da bir şey ters gittiğinde — diyelim ki kullanıcıların %3’ü bir endpoint’te yüksek latency yaşıyor — status sayfası hemen “Partial Outage” diyordu. Sonuç? Slack kanallarında “GitHub çöktü!” mesajları, müşterilerden “deployment’ı durduralım mı?” soruları, gereksiz telaş.
Hmm, bunu nasıl anlatsamdı…
Halbuki servis aslında çalışıyordu. Sadece biraz yavaştı. Ya da belli bir bölgede tökezliyordu (buna — itiraz edebilirsiniz tabi — dikkat edin). Siz hiç denediniz mi? Şimdi gelen üç katmanlı yapı bu nüansı yakalıyor, yani olayın rengini daha doğru gösteriyor (ve açıkçası buna baya ihtiyaç vardı):
| Durum | Ne anlama geliyor? | Downtime ağırlığı |
|---|---|---|
| Degraded Performance | Servis ayakta ama biraz aksak. Yüksek latency, hafif hata oranları. | %0 (uptime’a yansımıyor) |
| Partial Outage | Servisin önemli bir kısmı ya erişilmez ya da ciddi sıkıntılı. | %30 |
| Major Outage | Servis büyük ölçüde çökmüş. Çoğunluk etkileniyor. | %100 |
Aslında, Yani pratikte şu oluyor: 1 saatlik bir Partial Outage, uptime hesabında 18 dakika olarak sayılıyor. Degraded Performance ise hiç sayılmıyor bile. Bu hesap tarzı endüstri standardı aslında — StatusPage.io ve benzeri platformlarda yıllardır böyle. GitHub bu standarda şimdi uyum sağlamış oldu.
“Müşteri etkisini doğru yansıtmak lazım. Her hıçkırığı outage ilan etmek ne kimseye fayda sağlar, ne de şirketin reliability tablosunu adil gösterir.” — Bu benim yıllardır söylediğim bir şey; şimdi GitHub da resmen uyguluyor.
Benim Azure tarafından gördüğüm benzer hikaye
2022’de Logosoft’ta bir bankacılık müşterimiz vardı — Azure Front Door üzerinden global trafik yönetiyorduk. Azure’ın status sayfası o dönemde de çok siyah-beyazdı. Bir gün Frankfurt bölgesinde latency 200ms’den 800ms’e fırladı (yanlış duymadınız). Status sayfası: yemyeşil. Biz müşteriye ne diyeceğimizi bilmiyoruz, çünkü “healthy” diyor sayfa ama kullanıcılar şikayetçi.
Kısa bir not düşeyim buraya.
Microsoft sonradan Service Health içinde “Service Advisories” diye ayrı bir kategori ekledi. GitHub’ın şimdi yaptığı da aynı mantığın ürünü (ki bu çoğu kişinin gözünden kaçıyor). Bir servisin “çalışıyor” ile “çökmüş” arasında bir sürü ara ton var —. Bunları şeffafça iletmek güveni besliyor, başka türlü olmuyor zaten.
Per-service uptime: 90 günlük fotoğraf
Şimdi ikinci değişikliğe gelelim. GitHub artık her servis için ayrı ayrı 90 günlük uptime yüzdesi yayınlayacak. Yani Actions’ın uptime’ı başka, Packages’ın başka, Pages’ın başka olarak görünecek.
Doğrusu, Bunu neden önemsiyorum? Çünkü kurumsal müşteriyseniz. SLA görüşmelerine giriyorsanız, elinizde somut veri olması işi baya kolaylaştırıyor. Daha önce “GitHub’ın uptime’ı şu kadar” diyordum. Bu aslında her şeyi tek torbaya atmak demekti; Actions da dahil, Copilot da dahil, Repos da dahil… Halbuki bazen sadece iki servisi kullanıyoruz, geri kalan metrikler niye bizi yoruyor ki?
Pratik bir örnek vereyim: Enterprise Cloud müşterisi bir holding düşünün. GitHub Actions’ı kritik CI/CD pipeline’ları için kullanıyor. Yönetim kuruluna “Actions’ın son 90 günde uptime’ı %99.94” diye raporlamak istiyor. Eskiden bu veriyi kendi internal tooling’iyle toplamak zorundaydı — Prometheus’a scrape eden custom script’ler, Grafana dashboard’ları… Şimdi status sayfasında direkt görebilecek.
Türkiye tarafında bu ne anlama geliyor?
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de özellikle finans. Telekom sektörü GitHub Enterprise tarafına geçişte hâlâ temkinli davranıyor. En büyük itirazlardan biri şu: “SLA’nız ne? Kesinti olursa nasıl ölçeceğiz?”
Size bir şey söyleyeyim, Bu değişiklikten sonra satış süreçlerinde elimde daha somut bir argüman olacak (ciddiyim). “Bakın, GitHub her servisin uptime’ını ayrı ayrı yayınlıyor; Actions için ayrı takip yapabilirsiniz.” Eskiden bu konuşma baya muğlaktı ama şimdi rakamlar ortada duruyor.
Ayrıca şunu da ekleyeyim — Türkiye’den kullandığımızda özellikle Europe-North bölgesinin performansı bizi direkt etkiliyor. GitHub henüz bölge bazlı uptime yayınlamıyor (hâlâ global metrikler). Bu bence eksik kalan taraflardan biri; umarım sonraki turda bölge kırılımını da koyarlar. Bu konuyla ilgili Azure MCP Visual Studio 2022’de: Eklenti Devri Bitti yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili VS Live! Las Vegas 2026: İzlemeye Değer 20 Oturum yazımıza da göz atmanızı tavsiye ederim.
Copilot AI Model Providers: Zincirin kırılan halkası
Şimdi gelelim benim en çok dikkatimi çeken değişikliğe. GitHub, Copilot için ayrı — itiraz edebilirsiniz tabi — bir “AI Model Providers” bileşeni ekledi. Bu neden kritik? Çünkü Copilot aslında tek parça değil — kendi altyapısı var. Arkasında OpenAI, Anthropic (Claude), Google (Gemini) gibi üçüncü parti model sağlayıcıları çalışıyor.
Küçük bir detay: Eskiden şöyle oluyordu: OpenAI’ın API’si kesintiye girse Copilot kullanıcıları suggestion alamıyordu. Status sayfasında Copilot “Partial Outage” görünüyordu. Halbuki GitHub’ın kendi altyapısında hiçbir sorun yoktu! Sorun tamamen upstream’deydi; yani suçlu kapının dışında duruyordu desek yanlış olmaz. Azure Smart Tier GA: Blob Depolamada Otomatik Tasarruf yazımızda bu konuya da değinmiştik.
Yeni yapıyla status sayfasında artık şunu görebileceksiniz:
GitHub Copilot ✅ Operational
├─ Copilot Chat ✅ Operational
├─ Copilot Code Completion ✅ Operational
└─ AI Model Providers ⚠️ Degraded Performance
└─ (detay: OpenAI GPT-4 endpoint'inde yüksek latency)Açıkçası, Bu ayrım sandığınızdan daha önemli olabilir mi? Bence evet. Çünkü kurumsal müşteriler bazen “Copilot çökmüş” algısıyla karar alabiliyor; halbuki sorun GitHub’ın kontrolü dışında gelişiyor olabilir. Şeffaflık burada ikna ediyor işte. Daha fazla bilgi için Kubernetes v1.36 ile Gelen Değişiklikler ve Notlarım yazımıza bakabilirsiniz.
Geçen ay yaşadığım bir olay
İlginç olan şu ki, Peki ben bunu niye bu kadar ciddiye alıyorum? Geçen ay bir e-ticaret müşterimizde Copilot Enterprise deployment’ı yaparken tam iki gün boyunca yavaşlık yaşadık; sabah suggestion’lar 4-5 saniyede geliyordu, normalde 800ms civarıydı ve fark resmen tokat gibi hissediliyordu. Bu konuyla ilgili Ingress’ten Gateway API’ye Geçiş: 1.0 Rehberi yazımıza da göz atmanızı tavsiye ederim.
Müşterinin CTO’su “Copilot’ta ciddi bir sorun var, geri çekelim mi?” diye sorduğunda ben status sayfasına baktım — yeşil gözüküyordu. Resmi olarak her şey yolundaydı. Sonradan öğrendim ki Anthropic tarafında Claude 3.5 Sonnet endpoint’lerinde capacity sorunu varmış; GitHub tarafı temizdi ama kullanıcı deneyimi yine de kötüydü.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
SLA hesaplaması: Matematiği biraz kurcalayalım
Garip gelecek ama, Neyse uzatmayayım, işin teknik tarafına geçelim biraz da (şaşırtıcı ama gerçek). Uptime hesaplamasının nasıl yapıldığını bilmek kurumsal kontratlarda hayati oluyor çünkü rakamın arkasındaki mantığı anlatamazsanız toplantıda havada kalırsınız.
Effective Downtime =
(Major Outage süresi × 1.0) +
(Partial Outage süresi × 0.3) +
(Degraded Performance süresi × 0.0)
Uptime % =
((Toplam Süre — Effective Downtime) / Toplam Süre) × 100Bir senaryo üzerinden gidelim; çünkü rakamla konuşunca mesele daha net oturuyor:
- 30 dakika Major Outage → 30 dakika downtime
- 2 saat Partial Outage → 120 × 0.3 = 36 dakika downtime
- 4 saat Degraded Performance → 0 dakika downtime
Total effective downtime böylece 66 dakika oluyor peki sonuç ne? Uptime hesabı (129600 — 66) /129600 = %99.
949 çıkıyor burayı yuvarlayınca %99
949 gibi görünür ama esas nokta başka: Dört saatlik Degraded Performance hiç sayılmadı bile ve bu bazılarına göre tartışmalı olabilir.
Aynen.
END OF DOC
Sıkça Sorulan Sorular
GitHub’ın yeni “Degraded Performance” durumu SLA’ımı nasıl etkiliyor?
Degraded Performance, uptime hesabında aslında %0 ağırlığa sahip. Yani servis bu durumda olsa bile SLA’nıza göre downtime sayılmıyor. Kurumsal kontratınız varsa, bence bu hesap yönteminin kontratınıza yansıyıp yansımadığını GitHub temsilcinizle bir netleştirin — sonradan sürprizle karşılaşmak istemezsiniz.
Peki neden?
Copilot kullanırken AI Model Providers durumunu nasıl takip edebilirim?
githubstatus.com’da artık “Copilot AI Model Providers” diye ayrı bir bileşen görüyorsunuz. Hani oraya RSS feed ile abone olabilir, ya da webhook kurarak kendi monitoring sisteminize entegre edebilirsiniz. Böylece upstream model provider sorunlarını GitHub’ın kendi servislerinden ayırt etmek çok daha kolay oluyor.
Per-service uptime verileri API ile çekilebiliyor mu?
GitHub’ın resmi status API’si var (githubstatus.com/api),. Açıkçası 90 günlük uptime yüzdelerini structured format’ta sağlıyor mu şu an net değil (en azından benim deneyimim böyle). Manuel scraping yerine statusgator veya StatusPage API entegrasyonlarını kullanmak daha mantıklı. Dokümantasyonu takip etmek lazım — hızlı değişiyor.
Türkiye’den erişim problemleri GitHub status sayfasında görünüyor mu?
Maalesef hayır. GitHub şu an bölge bazlı granularity sunmuyor. Yani Türkiye’den erişimde sorun yaşıyorsanız ama status sayfası yeşilse, bu büyük ihtimalle network/ISP kaynaklı lokal bir şey (buna dikkat edin). Tecrübeme göre öyle durumlarda Cloudflare Radar veya downdetector.com’da komşu ülkelerin durumuna bakmak iyi bir ipucu veriyor.
Bu değişiklikler GitHub Enterprise Server (self-hosted) için de geçerli mi?
Hayır, bunlar GitHub.com (SaaS) için. Kendi altyapınızda host ettiğiniz Enterprise Server’da status takibini zaten siz yapıyorsunuz. Ama Enterprise Cloud (SaaS kurumsal) müşterisiyseniz, aynı status sayfası sizin için de geçerli.
Kaynaklar ve İleri Okuma
Eh, GitHub Blog — Bringing more transparency to GitHub’s status page
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
