Portal Akademik Kampus Lemot: Cara Cek

Lagi rebut KRS jam 00:00. Buka portal akademik kampus — loading. Refresh — masih loading. Coba dari HP — loading. 30 detik kemudian, browser kasih notif "This site can't be reached". Pesan grup angkatan rame: "portal down lagi gak sih?" Beberapa bilang bisa, beberapa nggak bisa.

Skenario di atas dialami hampir semua mahasiswa Indonesia. Tapi — portal kampus yang "selalu down" itu kebanyakan tidak benar-benar mati. Yang terjadi biasanya server hidup tapi lambat respons, sampai browser timeout dan kelihatan seperti down. Artikel ini mengajak kamu membedakan dua kondisi itu, plus menjelaskan kenapa portal akademik kampus di Indonesia rentan mengalami ini.

Lompat ke section yang sesuai kamu: Mahasiswa aktif (KRS, nilai, jadwal) · Calon mahasiswa (SNBP/UTBK, daftar, pengumuman) · Admin IT kampus (quick-fix tanpa ganti hardware). Section diagnostik 5-langkah berlaku universal untuk semua audience.

TL;DR untuk yang buru-buru: Buka cekipsaya.com di tab lain. Kalau cekipsaya kebuka cepat tapi portal kampus tidak — masalah ada di server kampus, bukan koneksi kamu. Kalau dua-duanya lambat, koneksi kamu yang bermasalah.

Cara Cek: Server Kampus Down atau Koneksi Kamu yang Bermasalah

Lima menit. Lima langkah. Tidak butuh install apapun — semua bisa pakai browser atau Terminal/CMD bawaan.

Langkah 1 — Cek Koneksi Internet Kamu Sendiri

Sebelum kambing-hitamkan server kampus, pastikan koneksi kamu hidup. Buka 2-3 situs lain yang biasanya cepat: cekipsaya.com, Google, atau YouTube. Kalau semua lambat — masalah di kamu (router butuh restart, kuota habis, jam puncak internet rumah). Kalau cuma portal kampus yang lambat — lanjut ke langkah 2.

Langkah 2 — Ping Server Portal Kampus

Buka Terminal (macOS/Linux) atau Command Prompt (Windows). Ganti portal.kampus.ac.id dengan domain portal kampus kamu sebenarnya:

BASH/CMD — Ping server portal

ping portal.kampus.ac.id

# Output ideal (server hidup, jaringan sehat):
# 64 bytes from 203.0.113.10: icmp_seq=1 ttl=56 time=18.4 ms
# 64 bytes from 203.0.113.10: icmp_seq=2 ttl=56 time=19.1 ms

# Output mengkhawatirkan:
# Request timeout    -> server tidak respons / firewall blokir ICMP
# unknown host       -> DNS gagal resolve (server bisa hidup tapi DNS broken)

Banyak server kampus disable ICMP — ping timeout BUKAN berarti server mati. Lanjut ke langkah 3 untuk verifikasi pakai HTTP.

Langkah 3 — Cek HTTP Response (Lebih Akurat dari Ping)

Ini yang paling decisive. curl langsung kasih tahu apakah server jawab HTTP dan seberapa lambat. Tersedia di macOS/Linux bawaan, Windows 10+ juga sudah ada.

BASH/CMD — Cek HTTP code dan timing

curl -o /dev/null -s -w "HTTP:%{http_code} | TTFB:%{time_starttransfer}s | Total:%{time_total}s\n" -m 15 https://portal.kampus.ac.id

# Interpretasi:
# HTTP:200 | TTFB:0.4s    -> server sehat
# HTTP:200 | TTFB:2.8s    -> server UP tapi LEMOT (paling sering ini)
# HTTP:502/503/504        -> server overload atau backend down
# HTTP:000 | timeout      -> server beneran tidak respons

TTFB (Time To First Byte) di atas 2 detik = server kewalahan. Browser default timeout sekitar 30-60 detik, jadi TTFB 5-10 detik = sering kelihatan "down".

Pola yang paling umum: HTTP 200 dengan TTFB 1-3 detik. Server kampus secara teknis UP, tapi backend (PHP/Database) overload sehingga setiap request mengantri. Saat puncak (KRS, lihat nilai, daftar UTS), antrian makin panjang dan request kamu kena timeout.

Langkah 4 — Cek dari Lokasi Lain (Bukan Dari Kamu)

Kalau curl dari kamu lambat, belum tentu server lambat — bisa jadi route ISP kamu ke kampus yang bottleneck. Cek dari probe luar pakai layanan publik gratis:

Tools	Fungsi	Hasil yang Dilihat	Limit Free
downforeveryoneorjustme.com	Cek up/down dari probe global	Just you / everyone	Tidak ada
isitdownrightnow.com	Cek + history downtime	Status + uptime chart	Tidak ada
uptimerobot.com	Monitoring berkala (signup)	Grafik 30 hari	50 monitor free
checkhost.net	Ping/HTTP dari 30+ lokasi	Per-lokasi response time	5 check/menit
downdetector.id	Crowdsource laporan ID	Spike laporan user	Tidak ada

Langkah 5 — Traceroute (Opsional, untuk yang Mau Detail)

Kalau ping bisa tapi response lambat, traceroute bantu identifikasi di hop mana paket kena delay. Output yang sehat: latency naik bertahap; output mencurigakan: latency tiba-tiba lompat 200ms+ di satu hop.

BASH/CMD — Traceroute ke server portal

# macOS/Linux
traceroute portal.kampus.ac.id

# Windows
tracert portal.kampus.ac.id

# Contoh output sehat (IP via RFC 5737):
#  1  192.168.1.1          1.2 ms   <- router rumah
#  2  10.0.0.1             8.4 ms   <- ISP gateway
#  3  203.0.113.50        18.1 ms   <- IIX exchange
#  5  203.0.113.10        21.5 ms   <- server kampus, sehat

# Contoh output bermasalah:
#  5  *  *  *                       <- hop blackhole / firewall blokir
#  6  203.0.113.10       250.4 ms   <- latency lompat = bottleneck

Tidak punya CLI? Pakai tool Traceroute online di cekipsaya.com — input domain, lihat hasilnya tanpa install.

Kenapa Portal Akademik Kampus di Indonesia Sering Lemot

Bukan kebetulan. Ada 5 pola umum yang berulang di hampir semua kampus Indonesia, dari kampus kecil sampai PTN besar.

Penyebab 1 — Server On-Premise di Datacenter Kampus

Sebagian besar portal akademik di-host di datacenter internal kampus, bukan cloud. Implikasinya: kapasitas terbatas pada hardware fisik yang dibeli 3-5 tahun lalu, listrik kampus jadi single point of failure, dan link uplink ke ISP nasional sering oversubscribed. Ada kelebihan host on-prem (data sovereignty, kontrol penuh), tapi burst capacity-nya jelek.

Penyebab 2 — Spike Concurrent User di Jam Puncak

Hari biasa: 100-300 concurrent user. Hari KRS dibuka: 5.000-15.000 concurrent dalam 5 menit pertama. Server yang di-sizing untuk traffic harian akan kelimpungan saat puncak. Kompetitor cloud-native (Tokopedia, Shopee) handle ini dengan auto-scaling — kampus rata-rata belum punya budget/SDM untuk arsitektur seperti itu.

Event	Spike Magnitude	Durasi	Tingkat Risiko
KRS dibuka pertama	50-150x baseline	15-30 menit pertama	Sangat tinggi
Pengumuman nilai akhir	30-80x baseline	1-2 jam pertama	Tinggi
Pendaftaran beasiswa	20-50x baseline	Hari terakhir deadline	Tinggi
Cek hasil UTBK/SNBP	100-300x baseline	30 menit pertama	Ekstrem
Pendaftaran wisuda	10-25x baseline	Hari pembukaan	Sedang
Hari biasa	1x (baseline)	24 jam	Rendah

Penyebab 3 — Aplikasi PHP/Laravel Tidak Optimized

Ini sering terlihat dari TTFB. Banyak portal pakai Laravel/CodeIgniter tanpa enable OPcache, tanpa Redis untuk session/cache, dan tanpa audit query database (N+1 problem klasik). Setiap request membuka koneksi DB baru, bootstrapping framework dari nol, dan eksekusi puluhan query SQL yang seharusnya bisa di-cache. Hasil: TTFB 1-3 detik per request bahkan di traffic rendah.

Indikator visual mahasiswa: kalau halaman login muncul cepat tapi setelah login dashboard loading lama (5-15 detik), itu tanda backend lambat memproses query nilai/jadwal/KRS — bukan masalah jaringan kamu.

Penyebab 4 — Tidak Pakai CDN atau Cloudflare Proxy

Ada kampus yang sudah pakai Cloudflare, tapi cuma untuk DNS — bukan proxy. Bedanya besar: dengan proxy ON (orange cloud), Cloudflare cache CSS/JS/gambar di edge node terdekat (Jakarta/Singapore), origin kampus cuma diketuk untuk request dinamis. Tanpa proxy, setiap user hit langsung ke server fisik kampus dengan kapasitas yang sama untuk semua orang.

Penyebab 5 — Monitoring Reaktif, Bukan Proaktif

Tim IT kampus rata-rata kecil dan multi-peran (jaringan + sistem + helpdesk + pengadaan). Monitoring proaktif (Prometheus/Grafana, alerting Telegram, Smokeping) jarang diimplementasi karena tidak ada SDM dedicated. Akibat: tim baru tahu portal lemot setelah keluhan masuk Twitter — padahal mahasiswa di grup angkatan sudah tahu duluan.

Yang Sering Disalahkan Padahal Bukan Penyebab Utama

Diskusi grup angkatan sering melempar penyebab yang salah. Berikut yang sering disalahkan tapi kontribusinya kecil dibanding 5 penyebab di atas:

Yang Disalahkan	Realita	Status
"WiFi kampus lemot"	WiFi kampus rata-rata fine. Portal lemot dari mana saja (rumah/4G) = bukan WiFi.	Mitos
"Browser kamu jelek"	Chrome/Firefox/Safari/Edge sama-sama hit endpoint yang sama. Browser bukan bottleneck.	Mitos
"Hapus cache & cookies"	Kadang membantu (kalau token expired), tapi tidak menyelesaikan TTFB tinggi di server.	Sebagian benar
"Pakai mode incognito"	Sama dengan hapus cookies. Tidak membantu kalau server overload.	Mitos
"Internet Indonesia jelek"	Internet ID rata-rata 30-100 Mbps fine untuk portal text-based. Bukan bottleneck.	Mitos
"DNS kamu lambat"	Hanya berkontribusi 50-200ms di first lookup. Bukan penyebab TTFB 3 detik.	Mitos
"VPN bantu cepat"	VPN sering memperburuk (extra hop). Hanya membantu kalau ISP kamu route ke kampus jelek.	Tergantung

Untuk Mahasiswa Aktif: KRS, Nilai, Jadwal, SPP

Audience ini menghadapi portal kampus rutin tiap semester. Pain point utama: KRS rebutan kelas, lihat nilai akhir, daftar UTS/UAS, bayar SPP, ambil transkrip. Yang bisa dikontrol adalah kapan dan bagaimana akses — bukan servernya.

Tip 1 — Hindari Jam Puncak, Cari Sweet Spot

Untuk KRS: jangan refresh F5 maniak di menit pertama. Sistem antrian backend butuh 5-10 menit settle. Coba lagi setelah 15 menit, biasanya sudah lebih lancar. Untuk lihat nilai: tunggu 1-2 jam setelah pengumuman. Untuk daftar beasiswa: jangan H-1 deadline jam 23:59 — semua orang melakukan hal yang sama. Submit H-2 atau H-3.

Tip 2 — Pilih Koneksi yang Stabil, Bukan yang Tercepat

Untuk submit KRS, fiber rumah 20 Mbps stabil > 4G 100 Mbps yang fluktuatif. Kalau koneksi kamu drop di tengah submit form, server kampus yang sudah lemot harus retry — sering gagal. Pilih satu koneksi, jangan switch WiFi-4G-WiFi.

Tip 3 — Siapkan Data Sebelum Buka Form

Tulis dulu kode mata kuliah, NIP dosen, nomor jadwal di Notepad/Google Keep. Saat form akhirnya kebuka, kamu tinggal copy-paste — selesai dalam 30 detik vs ngetik 5 menit (form sering session timeout di tengah ngetik karena server reset).

Tip 4 — Jangan Refresh Berulang Saat Loading

F5 berulang menambah beban server (tiap refresh = request baru) dan membatalkan request kamu yang barangkali sudah hampir selesai. Kalau sudah loading 30 detik, biarkan sampai 60-90 detik sebelum refresh. Ini paling sering bikin orang gagal padahal request sebelumnya tinggal selangkah lagi sukses.

Tip 5 — Coba Versi Mobile atau Desktop Bergantian

Beberapa portal pakai backend berbeda untuk versi mobile dan desktop (subdomain m.portal.kampus.ac.id vs portal.kampus.ac.id). Kalau satu lemot, coba yang lain. Tidak selalu work tapi gratis dicoba.

Hari KRS — checklist 5 menit sebelum jam dibuka: (1) tulis daftar mata kuliah + alternatif kelas di catatan, (2) login portal SEBELUM jam dibuka biar session aktif, (3) test koneksi pakai Ping Test, (4) tutup tab/aplikasi lain biar bandwidth fokus, (5) siapkan satu device backup (HP) kalau laptop hang.

Untuk Calon Mahasiswa: SNBP, UTBK, Mandiri, Pengumuman

Stake-nya beda dari mahasiswa aktif. Kalau KRS gagal, masih bisa diurus minggu depan. Kalau SNBP/UTBK upload berkas gagal di deadline atau pengumuman tidak kebuka, dampaknya bisa 1 tahun. Audience ini biasanya: siswa SMA + orangtua, baru pertama kali interact dengan portal kampus, sering pakai HP entry-level di area sinyal pas-pasan.

Tip 1 — JANGAN Submit di H-0 atau H-1 Deadline

Pola yang setiap tahun terulang: deadline SNBP/UTBK/jalur mandiri jam 23:59. Dari jam 21:00 portal mulai lemot, jam 23:00 sering crash, jam 23:30 menuju 24:00 sering total down. Submit H-3 kalau bisa, paling lambat H-1 sore.

Cerita berulang tiap tahun: peserta upload berkas di menit terakhir, koneksi drop, sistem timeout, berkas tidak ke-submit. Saat banding, jawaban resmi: "submit terakhir tercatat tidak ada / tidak valid." Tahun depan baru bisa mendaftar. Jangan jadi korban pola ini. Submit minimal H-2.

Tip 2 — Hari Pengumuman SNBP/UTBK: Mirror Site dan Sweet Spot

Hari pengumuman, satu link resmi pasti collapse di 5 menit pertama. LTMPT/SNPMB biasanya menyediakan 40+ mirror site dari kampus mitra (PTN se-Indonesia). Jangan berebut server resmi pusat — coba mirror PTN regional yang lebih sepi (PTN luar Jawa biasanya lebih lancar). Sweet spot waktu: 2-4 jam setelah pengumuman dibuka atau 23:00-04:00 WIB saat traffic turun.

Tip 3 — Screenshot Setiap Step Sebagai Bukti

Saat upload berkas SNBP/UTBK/mandiri, screenshot setiap halaman: form sebelum submit, halaman konfirmasi sukses, nomor pendaftaran. Kalau sistem error klaim berkas kamu "tidak ke-upload" padahal kamu sudah dapat halaman sukses — screenshot ini bukti untuk banding. Simpan minimal 6 bulan setelah pengumuman.

Tip 4 — Bayar Tagihan UTBK/Mandiri: Cek 2x Sebelum Panik

Saat bayar via virtual account/marketplace, status sering tidak sync real-time dengan portal kampus (delay 5 menit-2 jam). Jangan panik kalau status "belum bayar" muncul setelah transfer — tunggu, refresh setelah 1 jam. Tapi kalau besoknya masih belum sync, hubungi panitia/CS portal dengan kirim screenshot bukti transfer.

Tip 5 — Untuk Orangtua atau Pendamping Calon Mahasiswa

Banyak orangtua kelimpungan saat anak gagal akses portal di hari deadline. Yang bisa dilakukan: (1) siapkan koneksi backup (paket data HP terisi cukup), (2) jangan bantu refresh berulang — itu memperlambat, (3) bantu screenshot/dokumentasi setiap step, (4) catat nomor CS/helpdesk panitia sebelum hari H, (5) saat anak panik, biarkan tarik napas 30 detik dulu sebelum klik berikutnya.

Untuk siswa SMA yang baca: bookmark artikel konfigurasi jaringan UTBK 2026 dan panduan troubleshooting koneksi kami — workflow ganti DNS yang membantu saat server pusat overload tapi mirror PTN masih bisa dibuka.

Untuk Admin IT Kampus: Quick-Fix Tanpa Ganti Hardware

Section ini buat tim TIK/PTIK kampus yang nemu artikel ini lewat Google atau dikirim mahasiswa via email keluhan. Asumsi: budget terbatas, tidak boleh migrasi cloud minggu depan, audit-pengadaan butuh 6 bulan. Yang berikut bisa dideploy dalam 1-3 hari dengan downtime menit-menit, dan hasilnya sering 3-10x improvement TTFB.

Prioritas eksekusi: Fix 1 (OPcache, 15 menit) → Fix 3 (Cloudflare proxy, 30 menit) → Fix 4 (UptimeRobot, 30 menit) → Fix 2 (Redis, 1 jam). Tiga pertama bisa selesai dalam 1 hari kerja dan tidak butuh approval pengadaan/kontrak vendor.

Fix 1 — Aktifkan PHP OPcache (Effort: 15 Menit)

OPcache cache hasil compile script PHP — tanpa ini, setiap request meng-compile ulang Laravel framework dari nol. Edit php.ini:

CONFIG — php.ini OPcache untuk production

; ============================================
; cekipsaya.com — network intelligence tools
; gratis untuk Indonesia: cek IP, DNS, ping,
; traceroute, blacklist check & more.
; ============================================
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit_buffer_size=128M
opcache.jit=tracing

; Restart setelah edit
sudo systemctl restart php8.2-fpm

Verify enabled: php -i | grep -i opcache.enable. Expected gain: TTFB drop 30-60%.

Fix 2 — Migrasi Session ke Redis (Effort: 1 Jam)

Default Laravel pakai file session — setiap request lock file, race condition saat concurrent. Redis solve ini + lebih cepat. Install Redis, ubah SESSION_DRIVER=redis + CACHE_DRIVER=redis di .env. Untuk kampus skala 5K-20K user, single Redis 1GB cukup.

Fix 3 — Aktifkan Cloudflare Proxy (Effort: 30 Menit)

Kalau sudah pakai Cloudflare untuk DNS, aktifkan proxy (orange cloud) untuk record portal. Tambah Page Rule: *portal.kampus.ac.id/build/* → Cache Everything 1 month. CSS/JS/font/gambar otomatis dilayani edge Cloudflare, origin cuma kena request dinamis. Bandwidth + load drop 40-70%.

Hati-hati Cloudflare proxy + login session: beberapa portal lawas pakai IP-based session. Saat di-proxy, semua request kelihatan dari IP Cloudflare → session bingung. Solusi: install module Cloudflare untuk Apache/Nginx yang restore real IP dari header CF-Connecting-IP.

Fix 4 — Pasang Uptime Monitoring Eksternal (Effort: 30 Menit)

Pakai UptimeRobot atau StatusCake (gratis 50 monitor). Monitor portal setiap 5 menit dari probe internasional. Alert ke Telegram bot kalau down/lambat. Tim IT tahu sebelum mahasiswa Twitter complain. Effort minimal, dampak besar di reputasi.

Tools Diagnostik Gratis di CekIPSaya

Semua tools di bawah free, no signup, no install. Cocok untuk dokumentasi laporan ke tim IT atau sekadar penasaran kondisi koneksi kamu.

Tool	Fungsi	Kapan Pakai
Cek IP Saya	Lihat IP publik + ISP + ASN kamu	Verify ISP routing sebelum lapor
DNS Lookup	Cek A/AAAA/CNAME/MX record domain	Verify domain portal resolve benar
Ping Test	Ping ke domain dari probe luar	Bandingin ping kamu vs probe global
Traceroute	Trace path paket ke server tujuan	Identify hop yang jadi bottleneck
Blacklist Check	Cek IP kampus di 50+ DNSBL	Kalau email kampus masuk spam
Port Checker	Cek port 80/443 open dari luar	Verify firewall tidak blokir global

FAQ — Pertanyaan yang Sering Ditanyakan

Saya calon mahasiswa, portal SNPMB/UTBK tidak bisa dibuka di hari pengumuman, harus bagaimana?

Pertama jangan panik dan jangan refresh berulang. Server pusat memang collapse di 5 menit pertama. Coba mirror site yang biasanya disediakan panitia (40+ kampus mitra). Atau tunggu 2-4 jam setelah pembukaan, atau dini hari (23:00-04:00 WIB) saat traffic turun. Pengumuman tetap sama, hanya cara aksesnya yang dirotasi.

Kenapa portal kampus saya selalu down padahal kampus lain bisa?

Portal kampus dihost terpisah per institusi — tidak ada shared infrastructure. Server, kapasitas, dan tim pengelolanya beda-beda. Kampus dengan budget IT besar dan tim dedicated biasanya lebih jarang down. Kampus dengan tim IT kecil dan server on-premise lawas lebih sering bermasalah, terutama saat puncak KRS atau pengumuman.

Apakah pakai VPN bantu portal lebih cepat?

Tidak selalu. VPN menambah extra hop (kamu - server VPN - server kampus) yang sering memperlambat. VPN baru membantu kalau ISP kamu routing-nya jelek ke kampus — kasus yang jarang. Cek dulu tanpa VPN, baru coba VPN sebagai eksperimen kalau koneksi langsung lambat sekali.

Berapa lama harus tunggu sebelum yakin portal beneran down?

Browser default timeout 30-60 detik. Tapi banyak portal lemot punya TTFB 5-15 detik di puncak — masih dalam batas browser timeout. Tunggu sampai browser kasih error eksplisit (timeout, 502, 504). Jangan refresh sebelum error keluar — refresh berulang malah memperlambat dan membatalkan request kamu.

Bisakah saya lapor ke tim IT kampus dengan data teknis?

Bisa dan sangat disarankan. Sertakan: (1) timestamp masalah, (2) output curl HTTP code + TTFB, (3) screenshot error browser, (4) bandingkan dari beberapa koneksi (rumah, 4G, kantor). Jauh lebih akurat dari sekadar "portal down dong kak". Tim IT lebih cepat respons kalau laporan teknis dan ada datanya.

Apakah portal kampus down bisa karena cyberattack DDoS?

Mungkin tapi jarang. Kebanyakan kasus "down" portal kampus adalah lonjakan traffic legitimate dari mahasiswa sendiri (KRS, lihat nilai). DDoS attack ke portal kampus lebih sering terjadi di periode strategis (UTBK, SNBP) dan biasanya tim IT kasih pengumuman resmi. Jangan asumsi DDoS sebagai penyebab default.

Saya admin IT kampus, dari mana mulai improvement?

Mulai dari yang free dan low-effort: (1) enable PHP OPcache — 15 menit, (2) Cloudflare proxy mode untuk static asset — 30 menit, (3) UptimeRobot monitoring + Telegram alert — 30 menit. Tiga ini bisa selesai dalam 1 hari kerja, dampaknya signifikan, dan tidak butuh approval pengadaan. Setelah itu baru pikirkan Redis, load balancer, atau migrasi cloud sebagian.

Ada cara cek server kampus down tanpa install Terminal atau CMD?

Ada. Pakai layanan online seperti downforeveryoneorjustme.com, isitdownrightnow.com, atau checkhost.net — input domain portal, mereka cek dari probe global dan kasih hasil up/down + response time. Atau pakai tools cekipsaya.com seperti Ping Test dan DNS Lookup yang langsung kasih hasil dari browser tanpa install apapun.

Kesimpulan

Portal akademik kampus yang lemot atau "selalu down" jarang benar-benar mati total. Yang sering terjadi: server UP tapi response lambat (TTFB 1-3 detik) sehingga browser timeout, atau lonjakan concurrent user saat KRS/SNBP/lihat nilai bikin antrian backend menumpuk. Artikel ini ditulis untuk tiga audience: mahasiswa aktif (KRS, nilai, jadwal), calon mahasiswa (SNBP/UTBK, daftar, upload berkas), dan admin IT kampus (quick-fix tanpa ganti hardware). Untuk verifikasi cepat, gunakan Cek IP & ISP, DNS Lookup, Ping Test, dan Traceroute di cekipsaya.com — gratis, no install, hasil bisa dipakai sebagai dokumentasi saat lapor ke tim IT.