Hosting SLA ve Hizmet Koşullarını Okumak: Uptime, İade Politikaları ve Gizli Limitler

Hosting SLA ve Hizmet Koşullarını Neden Ciddiye Almalısınız?

Yeni bir hosting paketi seçerken çoğu kişi önce fiyat, sonra disk ve trafik rakamlarına bakıyor. Oysa projenizin kaderini belirleyen asıl metinler, genellikle en alttaki küçük linklerde saklı: SLA (Service Level Agreement / Hizmet Düzeyi Sözleşmesi) ve hizmet koşulları. Bu metinler, siteniz çöktüğünde ne olacağını, hangi durumlarda iade veya hizmet kredisi alabileceğinizi, “limitsiz” gördüğünüz kaynakların gerçekte nerede bittiğini belirliyor.

Ajanslar, e-ticaret siteleri, SaaS projeleri ve yoğun içerik üreten yayıncılar için SLA artık sadece hukuki bir formalite değil; iş sürekliliği planının çekirdeği. Özellikle kampanya dönemleri, ürün lansmanları veya kritik SEO çalışmalarında birkaç dakikalık kesinti bile doğrudan gelir ve itibar kaybı anlamına gelebiliyor. Bu yüzden SLA ve hizmet koşullarını doğru okumayı öğrenmek, teknik ekibin olduğu kadar iş tarafının da sorumluluğu.

Bu yazıda DCHost ekibi olarak, uptime yüzdelerini gerçek kesinti sürelerine çevirmeyi, iade ve hizmet kredisi politikalarının satır aralarını ve hizmet koşullarındaki gizli limitleri birlikte açacağız. Amacımız, yeni bir hosting seçerken veya mevcut altyapınızı gözden geçirirken, sözleşme metinlerine korkmadan, net bir checklist ile bakabilmenizi sağlamak.

Hosting SLA Nedir, Neyi Kapsar?

SLA (Service Level Agreement), hosting sağlayıcısının size vermeyi taahhüt ettiği hizmet seviyesini tanımlar. En bilinen başlık uptime yüzdesidir; ancak iyi yazılmış bir SLA bunun çok ötesine geçer.

Tipik bir hosting SLA’sında şu başlıklar olur:

• Uptime yüzdesi: Örneğin aylık %99,9 ağ ve servis erişilebilirliği gibi.
• Ölçüm yöntemi: Hangi bileşenlerin uptime hesabına dahil edildiği (ağ, elektrik, hipervizör, web sunucusu vb.).
• Hariç tutulan durumlar: Planlı bakım, üçüncü taraf ağ sorunları, DDoS saldırıları, mücbir sebepler gibi.
• SLA ihlali durumunda telafi: Hizmet kredisi yüzdeleri, üst limitler, başvuru süreci.
• Bildirim süreçleri: Kesintilerin ne zaman, hangi kanaldan bildirileceği.

Burada kritik nokta şu: SLA, bir pazarlama metni değildir; ölçülebilir, denetlenebilir ve hesaplamaya dönüştürülebilir cümleler içermelidir. Örneğin “mümkün olan en yüksek uptime” ifadesi, hukuken neredeyse hiçbir şey ifade etmez. Buna karşılık “aylık ağ erişilebilirliği %99,9’un altına düşerse, etkilenen hizmetin aylık ücretinin %10–%25’i oranında hizmet kredisi tanımlanır” gibi bir cümle somut ve ölçülebilirdir.

SLA, Hizmet Koşulları ve AUP Arasındaki Farklar

Çoğu kullanıcı bu üç metni karıştırıyor:

• SLA: Teknik kalite ve süreklilik taahhüdü. Uptime, tepki süreleri, telafiler.
• Hizmet koşulları (ToS): Sözleşmenin hukuki çerçevesi. Ödeme, fesih, sorumluluk sınırları, veri saklama poliçeleri vb.
• Acceptable Use Policy (AUP): Hizmetin nasıl kullanılamayacağını tarif eder (spam, madencilik, saldırı trafiği vb.).

İyi bir hosting seçerken bu üç metni birlikte okumanız gerekir. Örneğin SLA size %99,9 uptime sözü verirken, hizmet koşullarında sağlayıcının toplam sorumluluğunun “en fazla son 1 aylık ücretle sınırlı” olduğuna dair bir madde görebilirsiniz. Bu, büyük bir e-ticaret sitesinin ciddi gelir kayıpları için ayrıca sigorta veya farklı iş sürekliliği stratejileri düşünmesi gerektiği anlamına gelir.

Uptime yüzdelerinin teknik hesaplamasını daha detaylı incelemek isterseniz, 99.9% uptime ve SLA sözleşmelerini okuma rehberi yazımıza da göz atabilirsiniz.

Uptime Yüzdelerini Gerçek Kesinti Süresine Çevirmek

“%99,9 uptime” ilk bakışta kulağa mükemmel geliyor. Ancak bu yüzdelerin aylık ve yıllık bazda ne kadar gerçek kesinti süresine denk geldiğini bilmeden karar vermek sağlıklı değil.

Uptime Yüzdeleri ve Aylık Kesinti Süreleri

Aşağıdaki tablo, yaklaşık bir aylık (30 gün) süre için farklı uptime yüzdelerinde en fazla ne kadar kesintiyi kabul etmiş olacağınızı gösteriyor:

Gerçek hayatta kesintiler genellikle tek bir blok halinde değil, birkaç dakikalık veya saniyelik parçalar halinde dağılır. Ancak yine de kampanya dönemlerinde 40–50 dakikalık toplam kesintinin bile ciddi ciro kaybına dönüşebileceğini unutmayın.

Uptime Hesabında Ne Ölçülüyor?

Bir diğer kritik detay, sağlayıcının “uptime” derken neyi kastettiğidir. Bazı sağlayıcılar sadece ağ ve güç sürekliliğini garanti eder; yani sunucunun bağlı olduğu switch ve elektrik altyapısı çalışıyorsa uptime sayılır. Oysa siz siteye erişemeyebilirsiniz, veritabanı sunucusu yanıt vermiyor olabilir. Bu farkı netleştirmek için SLA’da şu terimleri arayın:

• Network uptime: Veri merkezinin dış dünyaya bağlantısının ayakta olması.
• Host node uptime: VPS’in çalıştığı fiziksel sunucunun ayakta olması.
• Service uptime: Web ve veritabanı gibi belirli servislerin dışarıdan erişilebilir olması.

Örneğin sadece network uptime garanti ediliyorsa, “sunucu reboot’ta kaldı” veya “web sunucusu çöküyor” gibi sorunlar teknik olarak SLA kapsamına girmeyebilir. DCHost olarak SLA metinlerinde bu ayrımları olabildiğince açık yazmaya ve müşterilerimizin neyi, nasıl talep edebileceğini netleştirmeye özellikle dikkat ediyoruz.

Uptime Nasıl Ölçülüyor? Sağlayıcıya Körü Körüne Güvenmeyin

SLA’nın gerçekten işlemesi için tek taraflı ölçüm yeterli değildir. Sağlayıcı, genellikle kendi izleme sistemine (monitoring) göre uptime hesaplar; ancak kendi bağımsız ölçümünüz olmadan bu verileri teknik olarak tartışmanız zorlaşır.

Sağlayıcının İzleme Sistemleri

Profesyonel hosting altyapılarında sunucu ve ağ katmanında onlarca metrik izlenir: ping cevapları, HTTP/HTTPS kontrolleri, disk ve CPU alarmları, veritabanı sağlık kontrolleri vb. Ancak bu izlemeler genellikle sağlayıcının iç ağından yapılır. Yani dış dünyadan erişimi etkileyen bazı rota problemleri, ara sıra yaşanan paket kayıpları veya belirli bölgelere özgü problemler bu metriklere yansımayabilir.

Kendi Uptime Ölçümünüzü Kurun

Önerimiz, özellikle kritik projeler için mutlaka kendi uptime izleme altyapınızı kurmanız. Bu, harici bir izleme servisi veya kendi VPS’iniz üzerinde koşturduğunuz açık kaynak çözümler olabilir. IP veya domain bazlı ping yerine HTTP/HTTPS içerik kontrolü yapmanız (örneğin belirli bir kelimeyi sayfada aramak) gerçek kullanıcı deneyimine daha yakındır.

Kendi izleme sisteminizi kurmak için pratik bir rehber arıyorsanız, web sitesi uptime izleme ve alarm kurma rehberi yazımızda adım adım örnek senaryoları bulabilirsiniz. Bu tür bir izleme, SLA ihlali yaşadığınızı düşündüğünüz durumlarda elinizi güçlendirir, destek ekibiyle teknik veriye dayalı iletişim kurmanızı sağlar.

Planlı Bakım, DDoS ve Mücbir Sebepler

Hemen her SLA’da bazı durumların uptime hesabı dışında tutulduğunu görürsünüz. Özellikle şu başlıklar önemlidir:

• Planlı bakım: Belirli bir süre önceden e-posta veya panel üzerinden duyurulan, genellikle gece saatlerine alınan bakım çalışmaları.
• DDoS ve saldırılar: Altyapıya yönelik geniş çaplı saldırılar, sağlayıcının DDoS koruma sınırının ötesine geçtiğinde çoğu zaman SLA dışına alınır.
• Mücbir sebepler: Doğal afetler, geniş çaplı enerji kesintileri, ulusal/uluslararası ağ sorunları gibi öngörülemeyen durumlar.

Planlı bakımlar genellikle SLA hesabına dahil edilmez. Ancak burada bakmanız gereken, “planlı bakım” için ön bildirim süresi ve bakımların ne sıklıkla, ne kadar uzun sürdüğüdür. Haftada bir saat kesinti gerektiren bir altyapı, kâğıt üzerinde SLA’yı bozmasa bile işiniz için kabul edilemez olabilir.

SLA İhlalinde İade ve Hizmet Kredileri Nasıl Çalışır?

Uptime yüzdesi tek başına yeterli değil; asıl önemli olan, bu yüzdelerin ihlali halinde ne olacağı. Burada genellikle iki tür telafi görürüz:

• Hizmet kredisi (service credit): Gelecek dönemdeki faturadan düşülen veya hesabınıza kredi olarak tanımlanan tutarlar.
• Doğrudan para iadesi: Daha nadir görülür; genellikle ilk 7–30 gün “memnuniyet garantisi” kapsamında uygulanır.

SLA bölümünü okurken şu sorulara net cevap bulabilmelisiniz:

• Hangi eşiklerde (ör. %99,9 yerine %99,5 gerçekleştiğinde) ne kadar kredi alırım?
• Kredinin üst limiti nedir? (Çoğunlukla ilgili ayın fatura tutarı kadar.)
• Krediye hak kazanmak için destek talebi açmam gerekir mi, yoksa otomatik mi işliyor?
• Başvuru için zaman aşımı var mı? (Örn. 7 veya 30 gün içinde başvurulmalı.)

SLA Kredileri Genellikle Nasıl Hesaplanır?

Her sağlayıcının formülü farklı olabilir, ancak sık gördüğümüz bir örnek üzerinden gidelim:

• Aylık uptime %99,9–%99,0 arası gerçekleşti: İlgili ayın hizmet bedelinin %10’u kadar kredi.
• Aylık uptime %99,0–%98,0 arası gerçekleşti: %25 kredi.
• Aylık uptime %98,0’in altına düştü: %50 kredi.

Burada dikkat etmeniz gereken iki kritik nokta var:

1. Krediler genellikle “gelecek faturadan düşülür”: Yani şirketiniz bir kampanya döneminde binlerce lira ciro kaybetmiş olsa bile, SLA kredisi çoğunlukla sadece altyapı maliyetinizi kısmen telafi eder.
2. Üst limitler: Hizmet koşullarında “toplam sorumluluğumuz son 1 ayda ödediğiniz tutarla sınırlıdır” gibi bir madde varsa, uzun süreli kesintilerde dahi bundan fazlasını alamazsınız.

Para İadesi, Deneme Süresi ve SLA Kredisi Farkı

Kullanıcıların en çok karıştırdığı konu, “X gün koşulsuz iade” ile SLA ihlali sonrası verilen hizmet kredilerinin birbirine karıştırılması. Şu ayrımı net tutun:

• Memnuniyet / deneme süresi iadesi: Genellikle ilk 7–30 gün içinde, sebep göstermeden ayrılmanızı sağlar. Çoğu zaman alan adı, lisans ve üçüncü taraf hizmetler bu iadenin dışında kalır.
• SLA hizmet kredisi: Hizmetinizi kullanmaya devam ederken, yaşanan uptime düşüşüne karşılık gelecekte kullanabileceğiniz kredi tanımlanmasıdır.

Örneğin yeni bir VPS alıp ilk hafta içinde “beklediğim performansı alamadım” diyerek iade isteyebilirsiniz; bu SLA ile ilgili değil, memnuniyet politikasıdır. Buna karşılık 1 yıldır kullandığınız bir hostingde, bir ay içinde toplam 2 saat kesinti yaşarsanız, SLA’daki eşiğe bakarak hesaplanan hizmet kredisini talep edersiniz.

Hizmet Koşullarındaki Gizli Limitler: Asıl Sürprizler Burada

Paket tanıtım sayfasında “limitsiz” veya “yüksek” diye gördüğünüz birçok değer, aslında hizmet koşulları ve teknik dokümanlarda somut limitlere bağlanır. Bu limitler kötü niyetli değil; paylaşımlı altyapılarda adil kaynak kullanımı (fair use) için gereklidir. Ancak bilmeden bu sınırlara dayandığınızda siteniz yavaşlayabilir, hata verebilir veya geçici olarak askıya alınabilir.

CPU, RAM, IO ve Process Limitleri (Özellikle paylaşımlı hosting)

Paylaşımlı hosting paketlerinde her kullanıcıya belli bir CPU, RAM, IO ve eşzamanlı süreç (process) limiti atanır. Bu değerler çoğu zaman cPanel/CloudLinux gibi paneller üzerinden yönetilir. Örneğin:

• CPU: 1 vCPU’ya kadar
• RAM: 1–2 GB arası
• IO: 5–10 MB/s disk okuma/yazma
• EP (Entry Process): Aynı anda çalışabilecek PHP süreç sayısı

Bu limitleri aştığınızda siteye girişte “508 Resource Limit Is Reached” gibi hatalar görebilirsiniz. Bu konuya özel olarak, cPanel’de kaynak limitleri ve Resource Limit Reached hatası</a rehberimizde detaylı örneklerle değiniyoruz.

Paket açıklamalarında “limitsiz” disk ifadesi görüp, hizmet koşullarında 250.000 veya 500.000 inode sınırıyla karşılaşmak çok yaygın. Bu yüzden özellikle WordPress sitelerinde eski yedekler, cache dosyaları ve gereksiz medya dosyalarını temiz tutmak kritik önem taşır. Uygulamalı bir temizlik rehberi arıyorsanız, paylaşımlı hosting’de inode limitine takılmamak için temizlik rehberimiz tam bu soruna odaklanıyor.

Trafik ve Bant Genişliği: “Limitsiz” Her Zaman Limitsiz Değil

“Limitsiz trafik” ifadesi genelde şu anlama gelir: Toplam data transferiniz için katı bir kota yazmak yerine, anormal veya kötü niyetli kullanımları hizmet koşulları üzerinden sınırlandırıyoruz. Örneğin:

• Sürekli yüksek bitrate’li video akışı (stream) yapmak
• Dosya paylaşım / warez tarzı kullanımlar
• Sürekli yoğun API isteklerine maruz kalan, neredeyse CDN gibi çalışan siteler

Bu tarz senaryolarda sağlayıcı, fair use maddesine dayanarak sizi farklı bir pakete (örneğin VPS veya dedicated) geçirmenizi isteyebilir. Özellikle büyük medya veya dosya tabanlı projelerde, medyayı object storage ve CDN’e taşıyan offload stratejileri gibi çözümler planlamak çok daha sağlıklı olur.

E-posta Gönderim Limitleri ve Spam Politikaları

Birçok hosting kullanıcısı, hizmet koşullarında belirtilen saatlik / günlük e-posta gönderim limitlerini gözden kaçırır. Oysa:

• WordPress form eklentileri
• WooCommerce sipariş bildirimleri
• Toplu bülten veya kampanya mailleri

gibi işlevler bu limitlere takılabilir. Tipik kısıtlar şunlardır:

• Tek hesaptan saatte en fazla X adet e-posta
• Toplu spam şüphesi durumunda e-posta kuyruğunun otomatik durdurulması
• Şüpheli içerik veya çok sayıda bounce durumunda hesabın geçici askıya alınması

Hizmet koşullarında “bulk mailing” ile ilgili bölümü mutlaka okuyun. İş modeliniz düzenli bülten veya kampanya gönderimine dayanıyorsa, transactional ve pazarlama e-postalarını ayrı altyapılara ayırmayı ve ayrı gönderim alan adı kullanma stratejilerini değerlendirmenizi öneririz.

Yedekleme (Backup) Politikaları: Gerçekten Ne Kadar Güvendesiniz?

“Tüm siteleriniz düzenli olarak yedeklenir” cümlesi, kulağa çok güven verici geliyor. Ancak hangi sıklıkla, kaç kopya, nerede ve ne kadar süre saklandığı yazmıyorsa, bu cümle tek başına yeterli değil. Hizmet koşullarında mutlaka şu soruların cevabını arayın:

• Yedekleme sıklığı nedir? (Günlük, haftalık, saatlik?)
• Kaç geri dönüş noktasına (restore point) kadar saklanıyor?
• Yedekler aynı sunucuda mı, farklı disk havuzunda mı, farklı veri merkezinde mi tutuluyor?
• Ransomware veya hack durumunda yedeklerin şifrelenmesi/bozulması riskine karşı “immutable” yapılar var mı?

DCHost tarafında biz her zaman “yedeklerin son çare olduğu” bilinciyle, müşterilerimizi kendi bağımsız yedek akışlarını da kurmaları için cesaretlendiriyoruz. Özellikle kritik projeler için 3‑2‑1 yedekleme stratejisi ve ransomware’a dayanıklı backup rehberimizi mutlaka incelemenizi öneririm.

SLA ve Hizmet Koşullarını Okurken Kontrol Listesi

Tüm bu bilgileri tek tek akılda tutmak zor olabilir. Özellikle yeni bir hosting, VPS, dedicated veya colocation planlarken aşağıdaki kontrol listesini kullanabilirsiniz:

• 1. Uptime tanımı: Network mü, host node mu, yoksa web/DB servisi mi garanti ediliyor?
• 2. Uptime yüzdesi ve hesaplama periyodu: Aylık mı, yıllık mı değerlendiriliyor? Kısmi aylar nasıl ele alınıyor?
• 3. Hariç tutulan durumlar: Planlı bakım, DDoS, mücbir sebepler, üçüncü taraf ağ sorunları nasıl tanımlanmış?
• 4. Telafi mekanizması: Hizmet kredileri hangi eşiklerde, hangi oranlarda veriliyor? Üst limit nedir?
• 5. Başvuru süreci: SLA ihlali için bilet açma zorunluluğu, ekran görüntüsü / log talebi, zaman aşımı süreleri.
• 6. Kaynak limitleri: CPU, RAM, IO, EP, inode, veritabanı bağlantı ve e-posta gönderim limitleri nerede dökümante edilmiş?
• 7. Yedekleme politikası: Sıklık, saklama süresi, farklı lokasyonda yedek, test restore prosedürü var mı?
• 8. Fesih ve taşınma koşulları: Sözleşmeyi hangi şartlarda sonlandırabilirsiniz, verilerinizi almak için ne kadar süreniz var?
• 9. Veri koruma ve loglama: KVKK/GDPR uyumu, log saklama süreleri, veri merkezinin lokasyonu.
• 10. Destek SLA’sı: Yanıt süreleri, 7/24 destek kapsamı, kritik biletler için önceliklendirme.

Bu soruları netleştirdiğinizde, sadece fiyat etiketiyle değil, toplam sahip olma maliyeti (TCO) ve risk açısından da çok daha sağlıklı bir kıyaslama yapabilirsiniz. Özellikle büyüyen WordPress, WooCommerce veya Laravel projelerinde, ileride VPS’e geçişi de planlıyorsanız, paylaşımlı hosting’den VPS’e sorunsuz geçiş rehberi yazımız karar sürecinde oldukça yardımcı olacaktır.

DCHost ile Çalışırken Bu Bilgileri Nasıl Avantaja Çevirirsiniz?

DCHost’ta bizim yaklaşımımız basit: Sözleşmeler şaşırtmak için değil, netleştirmek için yazılır. Uzun vadeli müşterilerimizin büyük kısmı, paketlerimizi seçmeden önce SLA ve hizmet koşullarını bizimle beraber tek tek üzerinden geçen ajanslar, e-ticaret işletmeleri ve SaaS ekipleri.

Pratikte nasıl ilerleyebilirsiniz?

• Yeni bir proje planlarken, tahmini trafik ve büyüme senaryonuzu bizimle paylaşın; SLA tarafında kritik eşikleri birlikte gözden geçirelim.
• Paylaşımlı hosting kullanıyorsanız, cPanel’deki CPU/IO ve inode grafiklerini düzenli kontrol edin; limitlere yaklaşmaya başladığınızda ekibimizle birlikte önce optimizasyon, gerekirse VPS veya dedicated’e geçiş planlayalım.
• Kritik projeler için kendi uptime izleme ve bağımsız yedekleme stratejinizi kurarken, DCHost üzerindeki altyapınızla nasıl entegre edebileceğinizi danışın.
• Colocation veya dedicated sunucu planlıyorsanız, veri merkezi tarafındaki güç, soğutma, network ve fiziksel güvenlik SLA’larını mühendislerimizle beraber teknik seviyede tartışın.

Sonuçta amaç, “hiç kesinti olmayacak” gibi gerçekçi olmayan bir dünya vadetmek değil; riskleri şeffafça konuşup, sizin işinizi kaldıracak bir altyapı + sözleşme kombinasyonu kurmak. DCHost olarak bu kombini kurarken sadece bugünkü ihtiyaçlarınıza değil, 1–3 yıllık büyüme planlarınıza da bakmayı seviyoruz.

Özet ve Yol Haritası: İmza Atmadan Önce Son Kontrol

Hosting seçimi artık sadece “kaç GB disk, kaç GB trafik” sorusuyla cevaplanabilecek basit bir karar değil. SLA, hizmet koşulları ve gizli limitler; projenizin uptime, performans, maliyet ve güvenlik dengesini doğrudan etkiliyor. Bu yazıda birlikte gördük ki:

• Uptime yüzdeleri, gerçek hayatta saat ve dakikalarla ifade edilen kesinti sürelerine dönüşüyor.
• Bu yüzdelerin nasıl ölçüldüğü ve hangi durumların hariç tutulduğu en az yüzdelerin kendisi kadar önemli.
• SLA ihlallerinde genellikle doğrudan para iadesi değil, hizmet kredisi söz konusu ve bu kredilerin üst limitleri var.
• CPU, IO, inode, e-posta ve yedekleme gibi başlıklardaki “gizli” limitler, projeler büyüdükçe karşınıza ciddi darboğaz olarak çıkabiliyor.

DCHost ekibi olarak önerimiz şu: Yeni bir paket seçmeden veya mevcut altyapınızı yükseltmeden önce, SLA ve hizmet koşullarını bu yazıdaki checklist ile bir kez daha gözden geçirin. Kafanıza takılan maddeleri not edip bize iletin; birlikte hem teknik hem sözleşmesel açıdan mantıklı bir yapı kuralım. İster paylaşımlı hosting, ister VPS, dedicated sunucu veya colocation olsun; doğru planlandığında, SLA metni sizin için sadece hukuki bir zorunluluk değil, işinizin sigortası haline gelir.

Eğer projeniz için hangi altyapının daha uygun olduğuna karar veremiyorsanız, DCHost üzerinde sunduğumuz paylaşımlı hosting, VPS, dedicated ve colocation seçeneklerini, SLA ve hizmet şartları bakış açısıyla birlikte değerlendirelim. Böylece hem teknik hem sözleşmesel tarafta sürpriz yaşamadan, uzun vadeli ve güvenilir bir altyapı kurabilirsiniz.