1. Ruang Lingkup
Perjanjian Tingkat Layanan ("SLA") ini dimasukkan dengan referensi ke dalam Ketentuan Layanan dan mengatur komitmen tingkat layanan yang kami buat kepada pelanggan yang menggunakan Layanan yang dijelaskan di bawah ini.
1.1 Layanan yang Dicakup
SLA ini berlaku untuk kategori Layanan berikut:
- Server pribadi virtual (VPS), termasuk semua tingkatan KVM Linux
- Server Protokol Desktop Jarak Jauh (RDP)
- Server khusus (DS)
- Server GPU (GPU)
- Server penyimpanan dan cadangan
- Server streaming
- Server game
1.2 Layanan dengan komitmen yang disesuaikan
Hosting bersama dan cPanel membawa komitmen uptime di Bagian 2 tetapi dengan pengukuran yang disesuaikan untuk arsitektur tingkat bersama (target pengukuran yang relevan adalah ketersediaan host bersama daripada ketersediaan kontainer per pelanggan).
1.3 Layanan yang tidak dicakup
Hosting email dan SMTP membawa komitmen ketersediaan terpisah yang dipublikasikan di halaman produk masing-masing. Layanan Beta dan Pratinjau yang secara eksplisit diberi label demikian tidak dicakup oleh SLA ini.
2. Komitmen Uptime
2.1 Paket standar
Paket standar — VPS-1 hingga VPS-8, RDP-Basic dan RDP-Pro, semua tingkatan Storage, Game-S dan Game-M, Streaming-1 — membawa komitmen uptime bulanan sebesar 99,9%.
Uptime bulanan 99,9% setara dengan maksimum 43 menit 50 detik downtime dalam bulan kalender 30 hari, atau 44 menit 38 detik dalam bulan 31 hari.
2.2 Paket Pro, Premium, Khusus, GPU
Paket tingkat lebih tinggi — VPS-16, RDP-Power, semua tingkatan Dedicated (DS-Lite hingga DS-Beast), semua tingkatan GPU (GPU-Lite hingga GPU-Beast), Game-L, Streaming-2 — membawa komitmen uptime bulanan sebesar 99,99%.
Uptime bulanan 99,99% setara dengan maksimum 4 menit 23 detik downtime dalam bulan kalender 30 hari, atau 4 menit 28 detik dalam bulan 31 hari.
3. Metodologi Pengukuran
3.1 Pemantauan eksternal
Uptime diukur oleh node pemantauan eksternal yang dioperasikan oleh penyedia uptime pihak ketiga (UptimeRobot, Better Uptime, atau yang setara). Kami saat ini memelihara tiga (3) node pemantauan independen yang berlokasi di wilayah geografis yang berbeda untuk menghindari pengukuran titik kegagalan tunggal.
3.2 Interval probe
Setiap node pemantauan memeriksa endpoint utama setiap Layanan setiap lima (5) menit.
3.3 Deteksi aturan mayoritas
Downtime dicatat ketika setidaknya dua dari tiga node pemantauan melaporkan Layanan tidak dapat dijangkau dalam jendela probe yang sama. Ini menghindari menghubungkan gangguan jaringan lokal di node pemantauan ke insiden MurmurHost.
3.4 Akrual downtime
"Menit downtime" adalah setiap menit penuh selama deteksi aturan mayoritas berada dalam keadaan tidak dapat dijangkau. Menit parsial dibulatkan ke atas menjadi menit penuh untuk tujuan perhitungan kredit.
3.5 Pengukuran sisi pelanggan
Pelanggan dapat menggunakan infrastruktur pemantauan mereka sendiri untuk menguatkan klaim downtime. Jika pengukuran sisi pelanggan berbeda secara material dari pemantauan kami, kami akan membagikan data pengukuran kami dan bekerja menuju kesepakatan tentang periode downtime yang sebenarnya.
4. Kredit Layanan
4.1 Tingkat kredit
Jika Layanan yang dicakup turun di bawah komitmen uptime bulanannya, pelanggan berhak atas kredit layanan yang dihitung sebagai persentase dari biaya bulanan untuk Layanan yang terpengaruh:
| Uptime bulanan | Kredit |
|---|---|
| Di bawah 99,9% (atau 99,99% untuk tingkat lebih tinggi) tetapi ≥ 99,0% | 10% |
| Di bawah 99,0% tetapi ≥ 95,0% | 25% |
| Di bawah 95,0% tetapi ≥ 90,0% | 50% |
| Di bawah 90,0% | 100% |
4.2 Aplikasi
Kredit layanan diterapkan pada faktur berikutnya dari Layanan yang terpengaruh. Jika pelanggan menghentikan Layanan yang terpengaruh sebelum faktur berikutnya, kredit dibayarkan sebagai pengembalian dana melalui metode pembayaran asli, tunduk pada ketentuan pemrosesan dalam Kebijakan Pengembalian Dana.
4.3 Batas
Total kredit untuk Layanan yang terpengaruh dalam satu bulan tidak dapat melebihi 100% dari biaya bulanan Layanan tersebut. Kredit layanan adalah satu-satunya dan eksklusif remedy pelanggan untuk kegagalan memenuhi komitmen uptime berdasarkan SLA ini.
5. Pengecualian
Berikut ini tidak dihitung sebagai downtime untuk tujuan Bagian 2:
5.1 Pemeliharaan terjadwal
Pemeliharaan yang diumumkan setidaknya empat puluh delapan (48) jam sebelumnya melalui panel pelanggan dan halaman status di /status. Jendela pemeliharaan rutin biasanya dijadwalkan selama jam di luar puncak untuk yurisdiksi yang relevan.
5.2 Force majeure
Tindakan Tuhan, bencana alam, perang, kerusuhan sipil, tindakan pemerintah, terorisme, atau peristiwa sebanding di luar kendali wajar kami.
5.3 Kesalahan pelanggan
Downtime yang disebabkan oleh konfigurasi yang salah oleh pelanggan, bug perangkat lunak yang dikendalikan pelanggan, melebihi alokasi sumber daya paket, atau operasi yang dilakukan oleh pelanggan (seperti reboot sukarela, instal ulang OS, atau perubahan konfigurasi yang menonaktifkan akses jarak jauh).
5.4 Gangguan jaringan pihak ketiga
Downtime yang disebabkan oleh gangguan jaringan pihak ketiga di luar jaringan kami dan di luar perjanjian peering kami, termasuk gangguan ISP pelanggan sendiri, penyedia transit, atau jaringan last-mile.
5.5 Tindakan terkait AUP
Penangguhan berdasarkan AUP tidak dihitung sebagai downtime. Penangguhan AUP yang disengketakan yang dibatalkan pada banding tidak dihitung secara retroaktif sebagai downtime; remedy pelanggan dalam kasus itu didokumentasikan dalam AUP.
6. Kinerja Jaringan
6.1 Target latensi
Kami berkomitmen pada target latensi median antara jaringan edge kami dan bursa internet regional utama, diukur setiap bulan:
| Wilayah (asal) | Target median ke IX terdekat |
|---|---|
| Islandia (RVK) | < 5 ms ke LIX |
| Swiss (ZRH) | < 2 ms ke SwissIX |
| Belanda (AMS) | < 1 ms ke AMS-IX |
| Rumania (BUC) | < 2 ms ke InterLAN |
| Moldova (KIV) | < 5 ms ke MD-IX |
| Bulgaria (SOF) | < 3 ms ke BIX.BG |
| Rusia (MSK) | < 3 ms ke MSK-IX |
| Panama (PTY) | < 4 ms ke PA-IX |
6.2 Kehilangan paket
Kami berkomitmen pada kehilangan paket kurang dari 0,1% pada lalu lintas intra-pusat data yang diukur selama jendela 5 menit bergulir, tidak termasuk interval yang terpengaruh oleh scrubbing DDoS aktif.
6.3 Throughput
Kami berkomitmen pada throughput pada kecepatan port yang dikonfigurasi pada Layanan, dikurangi overhead enkapsulasi dan transit yang khas. Throughput berkelanjutan yang secara material di bawah kecepatan port (setelah mengecualikan kemacetan transit di luar jaringan kami) diperlakukan sebagai kegagalan kinerja jaringan.
7. Waktu Mitigasi DDoS
7.1 Serangan volumetrik
Serangan DDoS volumetrik yang menargetkan Layanan pelanggan dideteksi dan ditandai oleh edge scrubbing anycast kami dalam waktu enam puluh (60) detik dari awal serangan. Mitigasi bersifat otomatis dan tidak memerlukan tindakan pelanggan.
7.2 Serangan lapisan aplikasi
Serangan lapisan aplikasi (L7) memerlukan aturan khusus aplikasi. Kami menyediakan aturan standar di edge untuk pola umum; aturan yang disesuaikan dengan aplikasi spesifik pelanggan (jalur URL, tanda tangan permintaan) adalah tanggung jawab pelanggan, opsional dapat dikonfigurasi melalui Cloudflare atau BunnyCDN di edge aplikasi.
7.3 Kapasitas per tingkat paket
Kapasitas scrubbing volumetrik diskalakan dengan tingkat paket dan didokumentasikan di /features/ddos-protection. Serangan berkelanjutan di atas kapasitas scrubbing paket dapat memicu percakapan peningkatan daripada kredit layanan.
8. SLA Penyediaan
8.1 Layanan berbasis KVM
Paket KVM VPS, RDP, bersama, dan cPanel menyelesaikan penyediaan dalam waktu lima (5) menit setelah konfirmasi pembayaran. Konfirmasi adalah saat pembayaran cryptocurrency mencapai konfirmasi ambang yang dijelaskan di halaman metode pembayaran yang relevan; untuk pembayaran kartu yang didukung, konfirmasi adalah penyelesaian di pemroses.
8.2 Khusus dan GPU
Paket khusus dan GPU stok menyelesaikan penyediaan dalam waktu dua puluh empat (24) jam setelah konfirmasi pembayaran. Build khusus khusus (multi-GPU, konfigurasi RAID eksotis, model NIC tertentu) ditandai saat pemesanan dan dapat memakan waktu 1–3 hari kerja.
8.3 Pesanan massal
Pesanan massal (lebih dari lima Layanan dalam satu transaksi) memerlukan koordinasi dengan tim penjualan. Waktu tunggu disepakati saat pemesanan dan menjadi bagian dari SLA khusus pesanan.
8.4 Kredit kegagalan penyediaan
Jika penyediaan melebihi target yang relevan lebih dari 25%, pelanggan berhak atas kredit layanan satu bulan pada Layanan yang terpengaruh. Ini sebagai tambahan atas kredit terkait uptime yang timbul berdasarkan Bagian 4.
9. Waktu Respons Dukungan
9.1 Definisi tingkat keparahan
- Kritis: server down, data tidak dapat diakses, insiden keamanan sedang berlangsung
- Tinggi: kinerja menurun, gangguan parsial, tidak dapat dijangkau secara intermiten
- Normal: pertanyaan konfigurasi, pertanyaan fitur, klarifikasi penagihan yang tidak mempengaruhi operasi layanan
- Rendah: umpan balik dokumentasi, pertanyaan proses, permintaan yang tidak sensitif terhadap waktu
9.2 Target respons
| Tingkat keparahan | Respons pertama | Pembaruan per jam | Target resolusi |
|---|---|---|---|
| Kritis | 30 menit | setiap jam | upaya terbaik, halaman status diperbarui |
| Tinggi | 2 jam | setiap 4 jam | upaya terbaik dalam 1 hari kerja |
| Normal | 24 jam | sesuai kebutuhan | dalam 3 hari kerja |
| Rendah | 48 jam | sesuai kebutuhan | dalam 5 hari kerja |
9.3 Saluran dukungan
Tiket diterima melalui panel pelanggan dan melalui email ke [email protected]. Obrolan 24/7 (jika tersedia, dimuat lambat sesuai dokumentasi di /features) untuk pertanyaan umum; masalah dengan tingkat keparahan Kritis harus selalu juga dibuka sebagai tiket untuk memastikan pelacakan.
10. Cara Mengklaim Kredit
10.1 Jendela klaim
Kredit layanan harus diklaim dalam waktu tiga puluh (30) hari setelah insiden yang menimbulkan kredit. Kredit yang tidak diklaim dalam jendela ini hangus.
10.2 Prosedur klaim
Untuk mengklaim kredit, kirim email ke [email protected] dengan informasi berikut:
- Email akun dan pengidentifikasi Layanan yang terpengaruh
- Tanggal dan waktu insiden dalam UTC
- Alasan klaim (kehilangan uptime, kehilangan penyediaan, kehilangan kinerja jaringan)
- Data pemantauan eksternal yang dimiliki pelanggan yang menguatkan insiden tersebut
10.3 Pemrosesan
Kami mengakui klaim dalam waktu empat puluh delapan (48) jam. Resolusi substantif biasanya selesai dalam waktu tujuh (7) hari kerja. Kredit yang disetujui diterapkan pada faktur berikutnya atau, atas permintaan pelanggan, dibayarkan sebagai pengembalian dana sesuai Bagian 4.2.
11. Jendela Pemeliharaan
Pemberitahuan pemeliharaan dipublikasikan di halaman status di /status dan dikirim melalui email ke semua pelanggan yang terpengaruh. Jendela pemberitahuan standar adalah empat puluh delapan (48) jam. Pemeliharaan darurat — diperlukan untuk mengatasi masalah keamanan atau stabilitas aktif — dapat dilakukan tanpa pemberitahuan sebelumnya; dalam kasus itu, post-mortem dipublikasikan di halaman status dalam waktu lima (5) hari kerja.
12. Modifikasi SLA Ini
Kami dapat memperbarui SLA ini secara berkala. Perubahan material yang mengurangi tingkat layanan yang dijamin berdasarkan SLA ini memerlukan pemberitahuan tiga puluh (30) hari melalui prosedur dalam Ketentuan Layanan Bagian 15. Perubahan yang meningkatkan komitmen atau memperjelas bahasa berlaku segera pada publikasi. Tanggal "Terakhir diperbarui" di bagian atas dokumen ini mencerminkan perubahan terbaru.