Service Level Agreement

SLA Hosch.id: Target Layanan yang Terukur & Realistis

SLA ini menetapkan cara membaca target dukungan, ketersediaan, maintenance, backup, dependensi pihak ketiga, pengecualian, dan tindak lanjut bila target tidak tercapai. Target hanya berlaku pada layanan yang secara eksplisit tercakup dalam paket, penawaran, atau kesepakatan layanan.

Status: Aktif Diperbarui 15 Oktober 2026 Jam dukungan standar: Senin-Sabtu 08.00-17.00 WIB Availability bersifat scope-based
Respons bukan resolusiTarget respons berarti konfirmasi awal dan dimulainya triase, bukan janji masalah selesai pada waktu yang sama.
99,9% bersyaratTarget hanya berlaku jika layanan/paket secara eksplisit menyebut target availability tersebut.
Maintenance & third partyWaktu tertentu dapat dikecualikan bila memenuhi kondisi yang dijelaskan dalam SLA.
Remedy tidak otomatis tunaiService credit, refund, atau perpanjangan hanya berlaku bila dinyatakan pada paket/kesepakatan terkait.
Catatan kontraktual: halaman ini adalah SLA operasional publik. Jika penawaran, kontrak, atau paket layanan tertentu menetapkan angka/ketentuan yang berbeda, dokumen khusus layanan tersebut menjadi rujukan untuk layanan itu. SLA ini tidak menciptakan jaminan zero-downtime, zero-data-loss, atau kompensasi otomatis.
Scope

1. Layanan yang Dapat Dicakup SLA

Tidak semua layanan memiliki target yang sama. Penerapan SLA mengikuti paket, arsitektur, akses, dan dependensi masing-masing layanan.

Website

Website sekolah / madrasah

Dapat mencakup availability platform, domain mapping, dan dukungan konfigurasi yang memang berada dalam scope layanan.

Domain

Domain & DNS

Dapat mencakup dukungan administrasi dan konfigurasi; keputusan Registry/Registrar tetap berada pada kewenangan pihak tersebut.

Application

Hosting RDM / aplikasi

Dapat mencakup server, database, DNS/subdomain, backup, dan dukungan sesuai paket hosting yang digunakan.

Support

Dukungan operator

Mencakup triase dan bantuan teknis dalam batas akses, jam dukungan, dan ruang lingkup pekerjaan yang disepakati.

Support window

2. Jam Dukungan Standar

Jam dukungan standar Hosch.id adalah Senin-Sabtu, 08.00-17.00 WIB. Jadwal khusus, hari libur nasional, atau perubahan operasional dapat diberlakukan dan diinformasikan melalui kanal yang wajar.

Laporan dapat dikirim di luar jam dukungan, tetapi perhitungan target respons standar dimulai atau dilanjutkan pada jam dukungan berikutnya, kecuali paket atau kesepakatan tertentu menyediakan penanganan di luar jam tersebut.

Initial response

3. Target Waktu Respons

Target di bawah adalah target respons awal/triase, bukan waktu penyelesaian. Penyelesaian dipengaruhi kompleksitas, akses, kebutuhan restore, perubahan konfigurasi, vendor, dan pihak ketiga.

Matriks prioritas dan target respons awal
Prioritas Contoh kondisi Target respons awal Catatan
P1 - KritisLayanan utama tidak dapat digunakan secara luas dan tidak tersedia workaround yang wajar.Prioritas penangananTarget numerik khusus hanya berlaku bila paket/kontrak menetapkannya. Eskalasi dimulai secepat yang wajar dalam kemampuan dukungan.
P2 - MayorGangguan signifikan pada fungsi utama, tetapi layanan masih sebagian tersedia atau terdapat workaround terbatas.≤ 12 jam dukunganDihitung pada jam dukungan standar.
P3 - MinorKendala teknis ringan yang tidak menghentikan fungsi utama.≤ 24 jam dukunganDihitung pada jam dukungan standar.
P4 - InformasiPertanyaan umum, konsultasi, atau permintaan non-insiden.≤ 24 jam dukunganDapat dijadwalkan sesuai antrean dan kompleksitas.
Availability

4. Target Ketersediaan 99,9% - Bila Dicakup Layanan

Angka 99,9% tidak diberlakukan secara universal ke seluruh layanan Hosch.id. Target ini hanya berlaku pada layanan yang secara eksplisit menyatakan availability target 99,9% pada paket, penawaran, atau kesepakatan.

Periode pengukuran standar: bulan kalender, kecuali dokumen layanan menyatakan periode lain.

Availability (%) = ((menit layanan terjadwal - qualifying downtime) / menit layanan terjadwal) x 100

Dalam ilustrasi bulan 30 hari, availability 99,9% setara dengan sekitar 43 menit 12 detik qualifying downtime. Angka tersebut adalah ilustrasi matematis sebelum menerapkan pengecualian SLA, bukan "jatah downtime" yang harus digunakan.

Qualifying downtimeWaktu ketika layanan yang dicakup tidak tersedia karena gangguan pada komponen yang berada dalam kendali operasional Hosch.id dan tidak termasuk pengecualian.
Partial degradationGangguan sebagian dinilai berdasarkan dampak dan definisi layanan terkait; tidak otomatis dihitung sebagai downtime penuh.
Sumber pembuktianLog sistem, monitoring, tiket insiden, catatan penyedia, dan bukti teknis lain dapat digunakan untuk merekonstruksi periode gangguan.
Maintenance

5. Pemeliharaan Terjadwal & Darurat

Maintenance diperlukan untuk keamanan, stabilitas, pembaruan, atau perubahan infrastruktur. Waktu maintenance yang memenuhi kondisi di bawah tidak dihitung sebagai qualifying downtime.

Planned

Pemeliharaan terjadwal

Diupayakan dilakukan pada waktu yang meminimalkan dampak dan dikomunikasikan lebih dahulu melalui kanal yang wajar bila pemberitahuan sebelumnya memungkinkan.

Emergency

Pemeliharaan darurat

Dapat dilakukan tanpa pemberitahuan panjang ketika diperlukan untuk menangani risiko keamanan, kegagalan kritis, atau menjaga stabilitas layanan. Informasi diberikan sesegera yang wajar setelah kondisi memungkinkan.

Dependencies

6. Infrastruktur & Pihak Ketiga

Layanan dapat bergantung pada Registrar/Registry domain, data center, hosting provider, jaringan, platform website, layanan email, aplikasi, atau penyedia eksternal lainnya.

Gangguan pihak ketiga yang berada di luar kendali operasional langsung Hosch.id dapat dikecualikan dari perhitungan availability. Namun, sepanjang relevan dengan scope layanan, Hosch.id tetap melakukan tindakan yang wajar seperti triase, pengumpulan bukti, eskalasi ke penyedia, perubahan konfigurasi yang tersedia, dan penyampaian status kepada pelanggan.

Backup & recovery

7. Backup, RPO/RTO & Pemulihan

Backup merupakan mitigasi risiko, bukan jaminan zero-data-loss. Frekuensi backup, retensi, titik pemulihan, dan waktu restore mengikuti paket serta konfigurasi layanan.

Yang dapat menjadi bagian SLA

  • mekanisme backup sesuai paket;
  • retensi backup sesuai konfigurasi;
  • prosedur permintaan restore;
  • verifikasi hasil restore sejauh memungkinkan.

Yang tidak boleh diasumsikan

  • semua layanan memiliki backup dengan jadwal yang sama;
  • backup selalu identik dengan data paling baru;
  • RPO/RTO tertentu berlaku tanpa dinyatakan pada paket;
  • setiap kehilangan data pasti dapat dipulihkan sepenuhnya.

Detail masa simpan berada pada Kebijakan Retensi Data; kontrol keamanan berada pada Kebijakan Keamanan Informasi.

Remedies

8. Jika Target SLA Tidak Tercapai

Kegagalan mencapai target tidak otomatis menghasilkan refund atau service credit kecuali paket, penawaran, atau kontrak layanan secara eksplisit menyediakannya.

Default remedy

Review SLA & tindakan korektif

Pelanggan dapat meminta peninjauan insiden. Hosch.id dapat memeriksa bukti teknis, mengonfirmasi qualifying downtime, menjelaskan penyebab yang diketahui, dan menetapkan perbaikan atau tindak lanjut yang relevan.

Jika diperjanjikan

Service credit / perpanjangan / refund

Bentuk kompensasi hanya berlaku bila dinyatakan secara eksplisit pada paket atau kesepakatan layanan, termasuk syarat, batas, dan cara pengajuannya.

Untuk meminta review, sertakan layanan terdampak, waktu mulai/berakhir gangguan, dampak, dan nomor tiket atau bukti komunikasi bila tersedia melalui Bantuan Admin.

Exclusions

9. Pengecualian SLA

Kondisi berikut umumnya tidak dihitung sebagai qualifying downtime sepanjang dapat dibuktikan relevan terhadap insiden.

  • pemeliharaan terjadwal atau pemeliharaan darurat yang memenuhi ketentuan SLA;
  • force majeure atau keadaan di luar kendali yang wajar;
  • gangguan pada Registry, Registrar, data center, ISP, platform, aplikasi, atau penyedia pihak ketiga di luar kendali langsung Hosch.id;
  • perangkat, jaringan lokal, koneksi internet, DNS resolver, atau sistem pengguna yang tidak dikelola Hosch.id;
  • perubahan konfigurasi, penghapusan data, kesalahan, atau tindakan pengguna/pihak lain di luar kewenangan Hosch.id;
  • kompromi kredensial yang berasal dari perangkat atau praktik pengguna di luar komponen yang dikelola;
  • pemblokiran, penghentian, pembatasan akun, atau tindakan regulator/penyedia yang berada di luar kendali Hosch.id;
  • layanan atau fitur yang memang tidak dinyatakan tercakup oleh SLA/availability target pada paket terkait.
Customer responsibility

10. Tanggung Jawab Pelanggan

Akurasi evaluasi SLA juga bergantung pada informasi dan praktik operasional pelanggan.

  • melaporkan gangguan melalui kanal resmi dengan informasi yang cukup;
  • menjaga akun dan kredensial akses;
  • memberikan akses/otorisasi yang diperlukan untuk troubleshooting;
  • tidak melakukan perubahan berisiko tanpa koordinasi bila sistem sedang ditangani;
  • menyediakan data atau informasi yang benar dan memiliki kewenangan untuk digunakan dalam layanan.

Dokumen yang Dibaca Bersama SLA

Status & Kedudukan Layanan Paket Layanan Hosch.id Hosting RDM Kebijakan Retensi Data Kebijakan Keamanan Informasi Pelindungan Data Pribadi Syarat & Ketentuan Bantuan Admin
Service Level Agreement Hosch.id - Terakhir diperbarui 15 Oktober 2026.
Target SLA berlaku sesuai paket, penawaran, konfigurasi, dan pengecualian layanan yang relevan.