SaaS SLA Tasarımı: Uptime, Credit ve Kurumsal Müşteri Sözleşmesi 2026

SaaS SLA nedir? Service Level Agreement, hizmet sağlayıcının uptime, response time, throughput ve support yanıt süresi gibi ölçülebilir taahhütleri ile bu taahhütler ihlal edildiğinde uygulanan service credit veya termination hakkını tanımlayan sözleşmeye eklenmiş hukuki bir ektir. 2026’da kurumsal alıcılar standart 99.9% taahhüdü artık yeterli görmüyor — Gartner 2025 SaaS Trust survey’inde 412 enterprise alıcının %71’i “ölçülebilir financial remedy” maddesini ilk üç teknik şart içine koydu. Bu yazı uptime tier’larından credit hesabına, exclusion klozlarından multi-region taahhüde, support severity’den audit haklarına kadar parametreleri gerçek rakamlarla açıklıyor.

SaaS SLA tasarımının özü dengededir: müşteri downtime maliyetini telafi edecek mekanizma ister; sağlayıcı ise sürdürülebilir tazminat limiti ve net exclusion tanımı ister. Yanlış kalibre edilmiş SLA, satışı kaybettirir veya %20’yi aşan revenue givebacks ile margin’i eritir.

Uptime Taahhüdü: Yüzde Sayısının Gerçek Maliyeti

Uptime yüzdesi sözleşmede satıcının operasyonel maliyetinin dakika dakika tanımıdır. %99.9 ile %99.99 arasındaki tek hane, yıllık izin verilen downtime’ı 8 saat 45 dakikadan 52 dakikaya indirir — altyapı maliyetini iki haneli yüzdeyle artırır. AWS’in EC2 Multi-Region SLA dokümanı bu farkı net gösterir: %99.99 garantisi yalnızca aktif-aktif deployment + health-check failover kuran müşteriler için geçerlidir.

Uptime %	Aylık Maks. Downtime	Yıllık Maks. Downtime	Tipik Mimari Gereksinim	Tipik Premium (taban fiyat üstüne)
99.0%	7 saat 18 dk	3 gün 15 saat	Tek region, tek AZ	—
99.5%	3 saat 39 dk	1 gün 19 saat	Tek region, multi-AZ	~%5-8
99.9% (“three nines”)	43 dk 12 sn	8 saat 45 dk	Multi-AZ + read replica	~%10-15
99.95%	21 dk 36 sn	4 saat 22 dk	Multi-AZ + auto-failover + chaos test	~%18-25
99.99% (“four nines”)	4 dk 19 sn	52 dk 36 sn	Multi-region active-active	~%30-45
99.999% (“five nines”)	26 sn	5 dk 15 sn	Global anycast + edge cache + sub-second failover	~%60-100+

Premium yüzdeleri sektöre göre değişir; finans “four nines”ı standart sayarken B2B SaaS için “three nines” en alt sınırdır. AWS Well-Architected Reliability Pillar her 9’un altyapı maliyetini 2-3 kat artırdığını gösteriyor.

“Uptime” tanımı flu bırakılırsa savunulamaz. Endüstri pratiği üç modeli birleştirir: availability monitor (sentetik probe), error rate threshold (5xx > %1) ve latency floor (p95 > X ms). Google SRE Book bunu “user-facing error budget” formülünde birleştirir.

Service Credit Modelleri: Tazminat Nasıl Hesaplanır

SLA ihlalinde tazminat para iadesi değil, gelecek dönemin ücretine uygulanan service credit olur. Üç model kurumsal sözleşmelerde dolaşır:

1. Tiered credit (basamak modeli): Uptime %99.9 altına düştüğünde %10, %99.0 altında %25, %95.0 altında %50 credit verilir. Avantaj: öngörülebilir, hesaplaması basit. Dezavantaj: bir saatlik tam çökme ile bir ay boyunca her gün 10 dakikalık degradation aynı kategoriye düşer. Ne zaman seç: mid-market self-serve SaaS satışı.
2. Pro-rata credit (orantılı model): Gerçek downtime saatleri / aylık toplam saat × aylık ücret = credit. Avantaj: matematiksel olarak adil, sürtünme yaratmaz. Dezavantaj: kısa downtime’larda tazminat sembolik kalır, müşteri tatmin olmaz. Ne zaman seç: kurumsal satışta, müşterinin gerçek maliyet hesaplamak istediği durumlarda.
3. Stepped + cap (basamaklı + tavanlı): Tiered modelle başla, aylık maksimum credit’i ücretin %50’si veya %100’ü ile sınırla. Avantaj: satıcının cash exposure’ını öngörülebilir tutar. Dezavantaj: büyük outage’larda müşteri “tavanın çok düşük” itirazını getirir. Ne zaman seç: standart enterprise contract template’i.

Model	Hesap Mantığı	Maks. Credit (aylık)	Müşteri Memnuniyeti	Satıcı Cash Risk
Tiered (3 basamak)	Yüzdeye göre sabit %10/%25/%50	%50	Orta — şeffaf	Düşük — öngörülebilir
Tiered (5 basamak)	%5/%10/%25/%50/%100 basamak	%100	Yüksek	Orta
Pro-rata	downtime_hours / 720 × monthly_fee	%100 (teorik)	Yüksek — adil hesap	Orta — değişken
Hybrid (tiered + pro-rata)	Min eşik geçilince pro-rata + minimum %5	%50 (cap)	Çok yüksek	Orta-yüksek
Fixed dollar	Her saatlik ihlal için sabit $X (örn. $500)	$X × downtime saati	Düşük — müzakere zor	Yüksek — kontrolsüz

Microsoft Azure’un Online Services SLA “stepped + cap” modelinin standart formül olduğunu kanıtlar — VM SLA’sı %99.9 altında %10, %99.0 altında %25, %95.0 altında %100 credit verir; toplam credit aylık ücreti aşamaz.

Hangi Olaylar SLA İhlali Sayılmaz: Exclusion Klozları

Exclusion listesi satıcının credit borcunu doğuran olayların kapsamını daraltır. İyi tasarlanmış liste 6-10 kalem içerir, her kalem kanıtlanabilir koşullara bağlanır. Belirsiz ifade (“force majeure”, “üçüncü taraf sorunları”) credit yoksunluğuna kapı açar.

• Planlı bakım (planned maintenance): En az 7 gün önceden bildirilmiş, aylık 4 saati aşmayan ve hafta sonu 02:00-06:00 UTC arasında yapılan bakım. Detay: bildirim e-posta + status page hem zorunludur, yalnız e-posta yetmez (kurumsal alıcı için).
• Müşteri kaynaklı hatalar: API rate limit aşımı, geçersiz auth token, müşterinin kendi entegrasyon kodundaki bug, müşterinin firewall/proxy yapılandırması.
• Force majeure: Deprem, savaş, salgın, devlet emri (uydurmaca cyber attack değil — DDoS exclusion ayrı tartışılır).
• Beta / preview / experimental özellikler: “Generally Available” damgası taşımayan tüm özellik adları sözleşmede liste halinde verilmeli.
• Müşterinin üst quota aşımı: Plan limitini aşan istek hacmi, contract’taki concurrency limit’i geçen oturum sayısı.
• Üçüncü taraf altyapı arızası — sadece kanıtlı: ISP outage, root DNS hatası, müşterinin tarafındaki cloud provider arızası. Genel “üçüncü taraf hizmeti” maddesi müzakerede reddedilmelidir.
• Suspension for breach: Müşterinin ödeme yapmaması veya AUP (Acceptable Use Policy) ihlali nedeniyle hizmetin durdurulması.

DDoS exclusion müzakerenin en hassas noktasıdır. Sağlayıcı “volumetric > 100 Gbps” saldırıları istisna saymak ister, müşteri “DDoS koruması ücretin içinde” der. Orta yol: eşik üstü exclude edilir, satıcı “best effort mitigation” taahhüdü verir ve Cloudflare/AWS Shield raporu ibraz eder.

Support Response Time: Severity Tier Matrisi

İkinci somut SLA boyutu support response time’dır. Müşterinin bildirdiği olay severity’ye göre sınıflandırılır ve her sınıfa yanıt süresi (acknowledge) ve çözüm süresi (resolution) atanır. Sektör pratiği 4 severity tier kullanır.

Severity	Tanım	Tipik Örnek	İlk Yanıt Hedefi	Çözüm Hedefi	Kanal
S1 — Critical	Üretimde tam çökme, business impact yüksek	Tüm tenant’lar 500 hatası alıyor, login imkânsız	≤ 15 dk (24/7)	4 saat	Telefon + Slack Connect + ticket
S2 — High	Önemli özellik bozuk, workaround var	Webhook delivery %30 başarısız, retry çalışıyor	≤ 1 saat (24/7)	1 iş günü	Slack + ticket
S3 — Medium	İkincil özellik etkilenmiş, geçici çözüm uygulanmış	Export raporları 5x yavaş	≤ 4 saat (iş saati)	3 iş günü	Ticket
S4 — Low	Cosmetic / documentation / soru	UI’de yanlış çeviri, API doc örneği eksik	≤ 1 iş günü	10 iş günü	Ticket

Müzakere noktaları: (1) Severity sınıfını kim belirler? İlk talep müşteri tanımıyla açılır, satıcı 2 saat içinde yeniden sınıflandırma hakkına sahiptir. (2) “Iş saati” tanımı zaman dilimi + tatil takvimi ile netleşmelidir. (3) Çözüm hedefi “best effort” tutulur; gerçek SLA-credit yalnız ilk yanıt süresine bağlanır. Çözüm hedefini SLA’ya bağlamak ücreti %20-30 artırır. Azure AD B2C SLA support tier’larının ücret katmanına nasıl bağlandığını gösterir.

Multi-Region ve Data Residency Taahhüdü

2026’da kurumsal alıcılar SLA’nın veri ikamet (data residency) taahhüdünü de içermesini istiyor. GDPR Article 28 ve KVKK kararları verinin nerede depolandığını sözleşmenin temel maddesi olarak görüyor. Üç ayrı taahhüt:

1. Primary region taahhüdü: Production veritabanı hangi bölgede tutulur (AWS eu-west-1, Azure West Europe, GCP europe-west1). Müşteri yazılı onayı olmadan değiştirilemez.
2. Cross-region replication kapsamı: Disaster recovery için verinin kopyalandığı ikinci bölge — burası primary’nin yargı yetkisinde mi (örn. EU-içi mi, yoksa US-EU mı)?
3. Sub-processor zinciri: Kullanılan CDN (Cloudflare, Akamai), e-posta delivery (SendGrid, Mailgun), monitoring (Datadog, New Relic), log aggregation (Splunk). Her biri sub-processor sayılır ve GDPR Article 28 gereği müşteriye liste halinde sunulmalıdır.

Multi-region active-active “four nines”a ulaşmanın tek pratik yoludur ama maliyet 1.8-2.4× artar; satıcı bunu “Enterprise Plus” tier olarak fiyatlandırır. Cloudflare’in Quicksilver replication raporuna göre sub-30 ms cross-region config replication standartlaştı.

Performance ve Throughput SLA: Latency Bütçesi

Availability “açık olup olmadığını” söyler ama 2026’da kurumsal müşteri “açık AMA yavaş” durumu da ihlal sayılmasını istiyor. Performans SLA üç parametre üzerinden tasarlanır: p50/p95/p99 latency, throughput (RPS) ve concurrency. Google Cloud Reliability Framework her endpoint’in p95 hedefini ayrı tanımlamayı önerir.

Endpoint Tipi	p50 Hedef	p95 Hedef	p99 Hedef	İhlal Eşiği (rolling 5 dk)
Auth / login	120 ms	350 ms	800 ms	p95 > 350 ms ardışık 3 ölçüm
Read API (search, list)	80 ms	250 ms	600 ms	p95 > 250 ms ardışık 3 ölçüm
Write API (POST/PUT)	180 ms	500 ms	1200 ms	p95 > 500 ms ardışık 3 ölçüm
Bulk import / async job	n/a (queue zamanı)	n/a	n/a	queue ack > 60 sn
Real-time webhook delivery	200 ms	1.5 sn	5 sn	%2 failed delivery

Latency credit uptime’dan karmaşıktır çünkü “yavaş” sürekli spektrumdur. Pratik çözüm: rolling 30 günlük p95’in hedef altında kaldığı zamanın yüzdesi %95’in altına düşerse credit doğar. Cloudflare TTFB benchmark B2B SaaS için 200-400 ms p95’i standart olarak gösterir.

Throughput SLA kapasite taahhüdüdür: “500 RPS sustained, 1000 RPS burst (5 sn)” net rakamları. Enterprise alıcının teknik ekibi bunu Day 1’de sorar; throughput taahhüdü olmadan “scale ediyoruz” hukuki taahhüt değildir.

Audit Hakları, SOC 2 ve Penetration Test

Kurumsal alıcı sözleşmede üç ayrı audit hakkı arar; bunlar satıcının operasyonel olgunluğunun göstergesidir.

• SOC 2 Type II raporu yıllık paylaşım: AICPA’nın SOC 2 framework beş güven kriterini (security, availability, processing integrity, confidentiality, privacy) bağımsız denetçi tarafından inceler. Type II 6-12 aylık operasyonel kanıt arar. Yıllık ~25.000-80.000 USD denetim maliyeti. Müzakere notu: SOC 2 raporu NDA altında verilir, müşteri rapor üretildikten 30 gün içinde alacak şekilde yazılır.
• ISO 27001:2022 sertifikası: Avrupa pazarında SOC 2’nin yerine sıkça istenir. Sertifika 3 yıllık geçerlilik + yıllık surveillance audit. Avantaj: kamu sektörü tender’larında zorunlu. Dezavantaj: implementation 6-9 ay sürer. Ne zaman seç: EU + Türkiye + Ortadoğu odaklı satıcı.
• Yıllık penetration test raporu: Bağımsız 3. taraf (OffSec, Bishop Fox, NCC Group) tarafından yapılan testin executive summary’sini müşteriye sunma hakkı. Detaylı zafiyetler değil — yalnız metodoloji + risk seviyeleri + remediation süresi.
• Right-to-audit (limitli): Müşterinin 60 gün önceden bildirimle 1 takvim yılında 1 kez, masraflar müşteriye ait olacak şekilde satıcının kontrol ortamını inceleme hakkı. Hyperscale’lerde “SOC 2’yi kabul et” cevabı verilir, ama mid-market SaaS bunu kabul etmek zorunda kalabilir.

Audit hakkı geriye dönük baskı kaynağıdır: satıcı “özelliği gönderdik” der, denetçi “production’da gerçek kontrol var mı?” diye sorar. SOC 2 hazırlığı satışın değil mühendislik kültürünün parçasıdır. Ömer Önal’ın yürüttüğü CTO as a Service kapsamında dış denetim öncesi kontrol matrisi kurulması, ilk Type II raporu için ortalama 4 ay kazandırıyor.

Termination, Veri Geri Alma ve Exit Süreci

SLA tasarımının sonunda exit maddeleri gelir. Kurumsal müşteri “lock-in” korkusu nedeniyle bu bölümü dikkatli okur. Üç ana senaryo:

1. Termination for cause (ihlal nedeniyle fesih): SLA ihlali 3 ay üst üste %25’ten fazla credit doğurduysa veya tek bir outage 24 saati aştıysa müşteri sözleşmeyi feshetme ve kalan dönem ücretini geri alma hakkını saklar. Ne zaman ekle: her enterprise sözleşme.
2. Termination for convenience (sebepsiz fesih): Sözleşme süresi içinde herhangi bir zamanda 90 gün önceden bildirimle fesih hakkı. Müzakere notu: satıcı bunu reddedip “yıllık taahhüt geri alınmaz” der; orta yol — kalan dönemin %50’sini cancel-fee olarak öder.
3. Data export ve transition: Fesih bildiriminden itibaren 90 gün boyunca satıcı veriyi makine-okunabilir formatta (JSON, CSV, Parquet) export hizmeti vermek zorundadır. Ücretsiz veya nominal $X bedelle. Dezavantaj: satıcı için maliyet, ama olmadığında müşteri sözleşmeyi imzalamaz.

Veri silme taahhüdü ayrı maddedir: terminasyon sonrası 30 gün içinde production verisi, 90 gün içinde backup’lar silinir; satıcı yazılı silme onayı verir. GDPR Article 17 (“right to erasure”) bunu zorunlu kılar. Build vs buy kararını veren CTO için exit kolaylığı kritik kriterdir — build vs buy değerlendirmesi satıcının exit sürecini ayrı kolonda puanlar.

Tehdit Modeli: Cybersecurity ve Incident Disclosure

2026’da hiçbir kurumsal SLA “security incident disclosure” maddesi olmadan kabul edilmiyor. NIS2 (EU) ve Türkiye Bilgi Güvenliği Kurulu kararları “data breach”in 72 saat içinde bildirilmesini zorunlu kılıyor.

Olay Tipi	Tanım	Müşteri Bildirimi	Detay Rapor (RCA)	Credit Tetikler mi?
Security incident (low)	Müşteri verisine yetkisiz erişim teşebbüsü, başarısız	Aylık güvenlik raporu	n/a	Hayır
Security incident (high)	Yetkisiz erişim başarılı, sınırlı veri	≤ 72 saat	10 iş günü	Müzakereye açık
Data breach	Müşteri PII’sinin sızdırılması	≤ 72 saat (NIS2 / GDPR)	30 gün	Evet (genelde %25-100)
Availability incident	SLA ihlaline yol açan outage	≤ 24 saat status page + e-posta	10 iş günü post-mortem	Evet (uptime credit)
Sub-processor breach	Cloudflare/Datadog gibi 3. taraf incident	Satıcıya bildirildiğinden 72 saat sonra	3. taraf rapor + impact assessment	Müzakereye açık

Post-mortem dokümanı kurumsal alıcı için kritiktir; “ne oldu” değil “neden engellenemedi”, “kontrol gap’i neydi” ve “tekrar olmaması için hangi engineering değişikliği yapıldı” bölümlerini içermeli. Dan Luu post-mortem koleksiyonu sektör örneklerini gösterir; güçlü RCA kültürü olan satıcı %15-20 daha yüksek fiyat alır. Teknoloji risk yönetimi KPI’ları RCA frekansını birinci sıra metrik olarak listeler.

Fiyatlama ve SLA Tier Eşleştirmesi

En pratik tasarım kararı SLA tier’larını fiyatlama plan’larına bağlamaktır. “Tek plan, herkese %99.9” enterprise satışı kaybettirir; “her müşteriye özel SLA” margin’i eritir. Standart yaklaşım 3-4 tier’lık matristir.

Tier	Aylık Fiyat Aralığı (örnek B2B SaaS)	Uptime	Support	Multi-Region	Audit / SOC 2	Credit Cap
Starter	$49-199 / ay	99.0% (best effort)	E-posta, 1 iş günü	Hayır	Hayır	—
Business	$499-1.499 / ay	99.9%	Slack + ticket, 4 saat	Single region	SOC 2 paylaşılır	%50
Enterprise	$2.999-15.000 / ay	99.95%	24/7 telefon, 1 saat	Multi-AZ + DR	SOC 2 + pen test	%100
Enterprise Plus	Müzakereli ($15.000+)	99.99%	Dedicated CSM + 15 dk	Multi-region active-active	SOC 2 + ISO 27001 + audit	%100 + pro-rata

Fiyatlama mantığı: SLA tier’ı yükseldikçe altyapı maliyeti süper-lineer artar (her 9 için 2-3×), fiyat da süper-lineer artmalı. Enterprise tier’ı Business’tan %50 daha pahalıysa, “four nines” sağlamak margin’i yer. Özel yazılım fiyatları 2026 analizinde SaaS tier farkı 5-10× modellenmiştir. İkinci kural: tier’lar arası geçişin teknik koşulları (multi-region migration 30-60 gün, data residency değişikliği, ek QA maliyeti) kim tarafından karşılanacak sözleşmede netleşmeli. Dijital dönüşüm KPI’ları tier upgrade SLA’sını da listeler.

SSS — Sıkça Sorulan Sorular

Sonuç

SaaS SLA tasarımı sales kontratının küçük eki değildir; satıcının altyapı yatırımı, mühendislik kültürü ve müşteri başarısı süreçlerinin bir araya geldiği operasyonel sözleşmedir. Doğru tasarlanmış SLA hem müşterinin downtime maliyetini önceden hesaplayabilmesini sağlar hem de satıcının cash exposure’ını öngörülebilir bir tavanla sınırlar. 2026’da tek bir “%99.9 uptime” cümlesi tatmin etmiyor; severity-based support, latency budget, audit hakları, data residency, incident disclosure ve exit süreci aynı paketin parçaları haline geldi.

Pratik karar çerçevesi: önce tier matrisini fiyatlama plan’larıyla eşleştir, her tier’ın altyapı maliyetini 12 aylık projeksiyonla modelle, exclusion listesini somutlaştır ve credit cap’i ücretle paralel ölçeklendir. SOC 2 + ISO 27001 hazırlığını Day 1’den engineering roadmap’ine yaz. Outsourcing sözleşmelerindeki SLA ve IP klozları ile bu yazıda anlatılan SaaS-müşteri SLA mantığı arasındaki ortak omurga hukuki dilin sayısallaştırılmasıdır.

SaaS şirketinizin enterprise satış pipeline’ında SLA müzakeresi takıldıysa veya tier matrisinizi 2026 standardına yükseltmek için bağımsız mühendislik + hukuk değerlendirmesi gerekiyorsa, iletişim formu üzerinden analiz çağrısı planlayabiliriz; mevcut sözleşmenizi 5 iş günü içinde tier bazlı gap analiziyle yanıtlıyoruz.