Saat ChatGPT, Claude, dan Grok Mati Bareng

Saat ChatGPT, Claude, dan Grok Mati Bareng

Tanggal 3 September 2026, ChatGPT dan Codex, Claude, dan Grok tumbang dalam pagi yang sama di Amerika — sekitar pukul 21.43 WIB ke atas buat kita di sini. Penyebabnya beda-beda menurut masing-masing vendor. Kalau produk Anda menggantungkan satu AI API, yang perlu dibenahi bukan pilihan vendornya. Yang perlu ada: jalan yang tetap jalan waktu API-nya diam.

Apa yang sebenarnya terjadi 3 September 2026?

Tiga insiden terpisah, jatuh di rentang jam yang sama.

OpenAI menyebut penyebabnya salah routing, mulai sekitar pukul 07.43 waktu Pasifik, dan ChatGPT beserta Codex tidak bisa dipakai sebagian pengguna. Anthropic mengalami gangguan sebagian di Claude.ai, Claude Code, dan Claude API — disebut masalah infrastruktur, dengan model Opus yang paling akhir pulih. xAI menunjuk pusat komputasi mereka di Memphis. The Register mencatat ketiganya pada 3 September 2026, dan 9to5Google mencatat semuanya pulih sekitar pukul 12.38 waktu Pasifik di hari yang sama. Laporan pengguna di Downdetector untuk OpenAI saja menembus puluhan ribu, menurut liputan Axios hari itu.

Dua hal justru lebih penting daripada urutan waktunya. Gemini tetap hidup. Dan Cursor, tool coding berbasis AI, ikut pincang — karena dia memanggil model-model yang sedang mati.

Dugaan penyebab bersama gugur di hari yang sama. Ketiganya memang menaruh beban besar di Microsoft Azure, jadi Azure langsung jadi tersangka. Microsoft membantah, Cloudflare bilang layanan mereka normal, dan sampai sekarang tidak ada satu pun penyedia yang mengumumkan akar masalah bersama.

Kenapa tiga vendor yang tak berhubungan bisa tumbang berbarengan?

Menurut keterangan resmi, mereka tidak berbagi penyebab. Tiga kerusakan sendiri-sendiri, satu jendela waktu. Ini kebetulan sial — atau tanda bahwa pasarnya sudah begitu terpusat sampai kebetulan sial jadi hal biasa.

Buat yang membeli layanannya, bedanya cuma di teori. Fitur Anda mati. Tulisan postmortem yang nanti Anda baca tidak akan mengembalikan empat jam itu.

Yang terjadi sebenarnya risiko ketergantungan biasa, cuma bajunya baru. Dan bisnis Indonesia sedang berjalan cepat ke arah sana. Studi AWS bersama Strand Partners, Unlocking Indonesia's AI Potential 2026, mencatat 40% perusahaan di Indonesia sudah memakai AI — naik dari 25% setahun sebelumnya (diberitakan 7 Agustus 2026). Bentuk pemakaiannya rata-rata seragam: satu API key ditempel di satu layanan, dipanggil langsung, tanpa rencana kedua. Pola ketergantungan yang sama sudah kita kenal saat berburu titik tunggal kegagalan di sistem lain.

Apa yang rusak di sistem bisnis Indonesia jam 21.43 WIB?

Jamnya justru inti cerita buat kita. Pukul 07.43 waktu Pasifik itu 21.43 WIB. Pulihnya pukul 12.38 waktu Pasifik, alias 02.38 WIB dini hari. Seluruh kejadian lewat waktu Indonesia sudah tidur.

Tidak ada yang menonton, jadi tidak ada yang tertangkap manusia. Yang kena justru pekerjaan yang ditinggal jalan sendiri: ekstraksi dokumen semalaman, laporan yang digenerate dini hari, balasan chat otomatis ke pelanggan beda zona waktu, klasifikasi data yang mengisi dashboard besok pagi.

Tiga pola kerusakan yang berulang di skenario seperti itu:

• Hilang diam-diam. Job memanggil API, dapat error 500, tidak ada percobaan ulang, cuma menulis warning yang tidak dibaca siapa-siapa. Pekerjaannya tidak pernah terjadi. Baru ketahuan Senin, waktu laporan kurang 400 baris.
• Badai retry. Kebalikannya. Job mencoba ulang terus-terusan ke endpoint yang sudah mati, menghabiskan seluruh jatah waktunya, dan tidak menyelesaikan apa pun — walau di log kelihatan sibuk.
• Request menggantung. Endpoint yang dipakai pelanggan memanggil model tanpa batas waktu tunggu. Request menumpuk, koneksi habis, dan matinya satu fitur berubah jadi matinya seluruh aplikasi.

Yang ketiga itu yang mahal. Fitur AI tidak bisa dipakai memang bikin kesal. Fitur AI menyeret halaman checkout ikut mati adalah percakapan yang jauh berbeda dengan klien.

Bagian mana yang tidak boleh menunggu jawaban AI?

Satu aturan sudah menutup sebagian besar masalahnya: panggilan AI tidak boleh berada di jalur yang wajib selesai. Penarikan pembayaran, akses pintu, submit order, pengiriman alarm, pencatatan absensi. Kalau transaksinya tidak bisa tuntas tanpa model menjawab, Anda sedang menaruh proses bisnis di atas uptime milik orang lain.

Pilah semua panggilan AI di sistem Anda jadi tiga lapis.

Baris ketiga itu bukan lelucon. Di kebanyakan sistem yang saya review, lapis menghalangi ternyata berisi satu-dua panggilan yang nyasar ke sana tanpa sengaja: validasi yang dulu dibikin "pintar", atau pengategori otomatis yang ditunggu tombol simpan. Memindahkannya biasanya cuma kerja satu sore.

Cadangan seperti apa yang benar-benar menolong?

Lima bagian, urut sesuai yang akan saya kerjakan duluan.

1. Antrekan, jangan panggil di tempat. Terima input pengguna, tulis ke penyimpanan yang tahan mati listrik, balas saat itu juga, dan biarkan worker di belakang yang mengurus bagian AI-nya. Perubahan sekecil ini mengubah mayoritas gangguan dari insiden jadi keterlambatan. Polanya sama dengan yang bikin aplikasi lapangan tetap hidup di sinyal seadanya: terima kerjanya dulu, sinkron belakangan.

2. Batasi waktu tunggu, lalu berhenti. Setiap panggilan AI diberi batas tunggu keras; 20 sampai 30 detik sudah longgar untuk satu chat completion. Pasangkan dengan circuit breaker — saklar yang otomatis berhenti memanggil sebuah layanan setelah gagal berkali-kali, supaya satu dependensi mati tidak menyeret sisanya. Percobaan ulang perlu jeda yang makin panjang, plus jitter: selisih acak kecil di tiap percobaan, supaya semua worker Anda tidak menyerbu endpoint di detik yang persis sama begitu layanannya hidup.

3. Penyedia kedua, yang anginnya dicek. Routing antar model kemungkinan besar sudah Anda inginkan demi biaya, dan pipanya sama persis: bagi per tugas, batasi per hari, lalu jalur cadangannya nyaris dapat gratis. Masalahnya, cadangan yang tidak pernah diuji itu ban serep yang tidak pernah dicek anginnya. Kirim sebagian kecil trafik asli ke penyedia kedua tiap minggu. Tanggal 3 September kemarin, tim yang sudah memasang Gemini sebagai cadangan tetap hidup.

4. Jalur tanpa AI di lapis paling bawah. Ada kalanya dua penyedia sama-sama tak bisa dihubungi, atau satu kelas layanan memang sedang apes. Putuskan dari sekarang bentuk versi seadanya: balasan template ketimbang balasan yang digenerate, aturan if-else ketimbang klasifikasi, antrean review manusia ketimbang persetujuan otomatis. Lebih lambat dan lebih bodoh masih jauh lebih baik daripada tidak bisa dipakai.

5. Idempotency untuk apa pun yang Anda bayar. Idempotency artinya permintaan yang sama dikirim dua kali tetap menghasilkan satu, bukan dua. Tempelkan kunci yang dibuat dari item pekerjaannya, bukan dari request HTTP-nya, lalu simpan respons sukses pertama di kunci itu. Tanpa ini, badai retry saat gangguan akan menagih Anda dua kali untuk hasil yang sudah Anda punya.

Apa yang perlu dicek minggu ini?

Sepuluh menit dengan grep dan satu spreadsheet sudah membawa Anda jauh.

• Daftar semua tempat kode Anda memanggil AI API. Termasuk yang di dalam cron job dan webhook handler — di situ biasanya yang terlupa bersembunyi.
• Untuk tiap panggilan: apa yang terjadi setelah 30 detik tanpa jawaban? Kalau jawabannya "kurang tahu", berarti panggilan itu tidak punya batas tunggu.
• Percobaan ulangnya dibatasi, dan jedanya makin panjang? Loop retry tanpa batas ke endpoint mati itu gangguan yang Anda buat sendiri.
• Saat gagal, input pengguna disimpan atau hilang? Kehilangan input lebih buruk daripada menampilkan pesan error.
• Ada yang dibangunkan alert jam 22.00 WIB, dan alert-nya bisa membedakan "vendornya mati" dari "kode kita rusak"? Dua hal itu butuh respons berbeda.
• Baca komitmen uptime di syarat layanan penyedia Anda, lalu baca yang Anda janjikan ke klien. Kalau janji Anda lebih ketat daripada janji mereka, Anda menjanjikan sesuatu yang bukan kendali Anda.

Poin terakhir ini yang sering menjerat. Angka 99,9% terdengar aman sampai Anda sadar sedang menjual ulang 99,5% milik orang lain, dan selisihnya Anda tanggung sendiri.

Yang tidak pernah berubah

Vendor AI akan tetap mengalami gangguan. Begitu juga payment gateway, begitu juga listrik, begitu juga jalan menuju kantor. Kita sudah lama terbiasa menyiapkan genset untuk mati lampu. Ketergantungan AI belum kita perlakukan setara.

Tiga penyedia, tiga penyebab, satu pagi. Tim yang nyaris tidak merasakan apa-apa pada 4 September bukan tim yang kebetulan memilih vendor paling benar. Mereka tim yang sudah memutuskan lebih dulu: apa yang terjadi kalau jawabannya tidak pernah datang.