Saya membangun Gitae karena berulang kali menghadapi pertanyaan praktis yang sama: website benar-benar down, atau masalahnya hanya di sisi saya?
Satu tab browser bukan alat diagnosis yang bagus. Halaman bisa gagal dimuat karena origin server memang down, tetapi penyebabnya juga bisa DNS, masalah sertifikat HTTPS, routing, aturan firewall, port yang tertutup atau terfilter, ISP, jalur VPN, kondisi browser, atau cache lokal. Gejala yang terlihat sama, tetapi tindakan yang tepat bisa sangat berbeda.
Itulah masalah yang ingin saya selesaikan dengan Gitae: bukan sekadar menampilkan indikator hijau atau merah, tetapi membantu mempersempit masalah ke layer yang masuk akal untuk diperiksa berikutnya.
Masalah sebenarnya di balik “website down”
Banyak website checker sederhana hanya menjawab pertanyaan sempit: apakah URL ini merespons dari satu lokasi pada satu waktu? Informasi itu berguna, tetapi belum sama dengan mendiagnosis gangguan.
Jika DNS salah, restart aplikasi tidak akan memperbaikinya. Jika HTTPS gagal karena sertifikat, mengubah isi halaman tidak relevan. Jika sebuah TCP port tidak bisa dijangkau, server sendiri masih mungkin hidup. Dan jika website terbuka dari server eksternal tetapi tidak dari koneksi saya, masalah bisa berada di jalur antara jaringan saya dan tujuan, bukan pada application server.
Karena itu saya membangun Gitae dengan model yang lebih berguna: website adalah rantai dependensi, dan setiap pengecekan hanya memberi bukti tentang satu bagian dari rantai itu.
Sudut pandang eksternal, bukan kebenaran mutlak
Pengecekan Gitae berjalan dari server VDS milik saya di Moscow dan Helsinki. Ini memberi titik observasi di luar komputer dan jaringan tempat saya pertama kali melihat masalah.
Jika website gagal secara lokal tetapi merespons dari kedua VDS, itu sinyal penting bahwa origin setidaknya tidak tidak-terjangkau untuk semua orang. Dalam kasus seperti itu saya lebih serius memeriksa DNS lokal, routing ISP, VPN, browser, firewall, atau masalah lain yang bergantung pada jalur jaringan. Jika probe eksternal juga gagal, alasan untuk memeriksa server, DNS, sertifikat, routing, atau gangguan jaringan yang lebih luas menjadi lebih kuat.
Namun remote check tidak otomatis “lebih akurat” daripada local check. Dua lokasi VDS tidak mewakili seluruh internet. Website bisa berfungsi dari Moscow dan Helsinki tetapi gagal dari negara, ISP, CDN edge, atau jaringan lain. Saya memperlakukan hasil remote sebagai titik observasi tambahan, bukan vonis global.
Apa yang diperiksa Gitae sekarang
- Website check — memeriksa apakah URL merespons dari server eksternal.
- SSL check — memeriksa status sertifikat HTTPS/TLS dan masalah terkait sertifikat.
- DNS check, nslookup, dan dig — membantu melihat bagaimana domain di-resolve dan record DNS apa yang dikembalikan.
- Reverse DNS dan IP check — menampilkan informasi IP dan data PTR/reverse-DNS.
- Domain info dan domain age — memberikan metadata dasar tentang domain.
- Port check — menguji apakah port target dapat dijangkau dari lokasi probe.
- Find your IP — menampilkan IP publik yang terlihat oleh layanan.
- Ping dan traceroute — memberikan sinyal jaringan tentang latency, packet loss, dan jalur menuju host.
- Hosting check dan CMS detection — menampilkan sinyal infrastruktur dan teknologi yang dapat membantu identifikasi.
Saya sengaja memperlakukan hasil-hasil ini sebagai sinyal. Record PTR tidak membuktikan siapa pemilik server. CMS detection berdasarkan fingerprint publik tidak membuktikan software stack yang tepat. Port yang tidak dapat dijangkau dari satu probe bisa saja difilter di jalur tertentu, bukan tertutup untuk semua orang.
Bagaimana saya membaca hasilnya
Nilai sebenarnya muncul saat beberapa pengecekan dibaca bersama-sama.
Jika DNS mengembalikan alamat yang saya harapkan, sertifikat HTTPS valid, dan website merespons dari kedua VDS tetapi masih tidak terbuka secara lokal, saya akan menyelidiki jalur lokal lebih dulu sebelum mengubah server. Sebaliknya, jika DNS tidak konsisten atau remote website check juga gagal, ada alasan lebih kuat untuk memeriksa sisi infrastruktur.
Ping dan traceroute juga harus dibaca dengan hati-hati. ICMP bisa difilter atau di-rate-limit. Hop yang tidak muncul di traceroute tidak otomatis berarti node itu rusak, dan host yang tidak membalas ping masih bisa melayani HTTPS secara normal. Tool ini berguna karena menambah konteks, bukan karena memberikan satu diagnosis final.
Prinsip utama saya adalah: satu pengecekan yang berhasil tidak membuktikan seluruh sistem sehat, dan satu pengecekan yang gagal tidak menjelaskan penyebabnya sendirian.
Availability dan SEO bukan hal yang sama
Availability juga penting untuk SEO, tetapi gangguan teknis bukan berarti sama dengan masalah ranking. Crawling bukan indexing, dan indexing bukan traffic.
Jika crawler tidak bisa mencapai website karena error DNS, jaringan, atau server, crawler itu tidak dapat mengambil konten terkait dengan benar pada saat tersebut. Google mendokumentasikan bahwa network dan DNS error saat crawling diperlakukan mirip dengan error server 5xx, dan ketidaktersediaan yang berkepanjangan dapat memengaruhi crawl serta URL yang sudah terindeks. Itu tidak berarti setiap outage singkat otomatis menyebabkan kerugian SEO, dan tool diagnostik juga tidak dapat membuktikan bahwa perubahan traffic setelahnya disebabkan oleh outage tersebut.
Untuk pengguna, logikanya lebih sederhana: jika mereka tidak bisa mengakses website, mereka tidak bisa menggunakannya. Tergantung jenis proyek, hal itu bisa berarti kehilangan session, lead, conversion, atau revenue. Tetapi pengecekan teknis tidak menghitung dampak bisnis tersebut.
Urutan praktis saat website “down”
- Konfirmasi gejala dari jaringan lain. Jangan menganggap browser lokal mewakili seluruh internet.
- Periksa DNS. Pastikan domain resolve dan record yang dikembalikan sesuai harapan.
- Periksa HTTPS/TLS. Lihat validitas sertifikat dan error koneksi.
- Periksa port yang diperlukan. Uji jangkauannya dari lokasi probe.
- Bandingkan sinyal jaringan. Gunakan ping dan traceroute sebagai data pendukung.
- Lihat IP, reverse DNS, hosting, dan CMS. Sinyal ini dapat membantu memastikan bahwa Anda benar-benar mencapai infrastruktur yang diharapkan.
- Baru kemudian persempit investigasi. Tentukan apakah bukti lebih kuat mengarah ke aplikasi, server, DNS, network path, atau local environment.
Ini bukan protokol incident response yang universal. Bagi saya, ini cara untuk menghindari kesalahan yang ingin saya hilangkan sejak awal: mengubah layer yang salah hanya karena satu-satunya informasi yang ada adalah “website tidak terbuka”.
Manfaat nyata dulu, monetisasi kemudian
Saat ini Gitae belum dimonetisasi. Saya membangunnya pertama-tama untuk diri sendiri karena saya membutuhkan cara cepat untuk memeriksa website dari luar mesin saya lalu langsung masuk ke diagnosis DNS, sertifikat, port, dan jaringan tanpa berpindah-pindah tool yang tidak terkait.
Tujuan saya sekarang adalah membuat diagnosis lebih berguna dan melihat apakah proyek ini bisa mendapatkan organic traffic lewat SEO dan permintaan nyata. Jika mencapai traffic yang bahkan hanya moderat, saya ingin menambahkan automated website monitoring dengan alert instan di messenger. Itu akan memperluas ide yang sama dari diagnosis manual ke deteksi: menyadari bahwa sesuatu menjadi tidak tersedia, lalu memberikan cukup informasi agar pemilik bisa mulai menyelidiki dengan cepat.
Inti idenya tetap sederhana
“Up” dan “down” adalah gejala, bukan penjelasan.
DNS, HTTPS/TLS, routing, port, hosting, aplikasi, dan jaringan pengguna sendiri dapat menghasilkan masalah availability yang terlihat sederhana. Gitae tidak secara ajaib menemukan setiap root cause, dan lokasi VDS eksternal tersebut tidak menunjukkan apa yang dilihat seluruh internet. Tetapi tool ini dapat mengumpulkan beberapa sinyal independen di satu tempat.
Itulah tool yang saya inginkan: membantu bergerak dari “website tidak terbuka” ke pertanyaan yang jauh lebih berguna, “layer mana yang harus saya periksa berikutnya?”