Saat ChatGPT, Claude, dan Grok Terganggu Bersamaan

Pada 3 September 2026, ChatGPT dan Codex, Claude, serta Grok mengalami gangguan pada pagi yang sama di Amerika, mulai sekitar pukul 21.43 WIB. Masing-masing penyedia melaporkan penyebab berbeda. Jika produk Anda bergantung pada satu API AI, siapkan cara agar pekerjaan utama tetap berjalan ketika layanan itu tidak merespons.

Apa yang sebenarnya terjadi 3 September 2026?

Tiga insiden terpisah terjadi dalam rentang waktu yang berdekatan.

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.

Gemini tetap dapat digunakan, sedangkan Cursor, alat pemrograman berbasis AI, ikut terdampak karena menggunakan model yang sedang terganggu. Pilihan model cadangan perlu memperhitungkan ketergantungan semacam ini.

Microsoft membantah dugaan bahwa gangguan Azure menjadi penyebab bersama, sedangkan Cloudflare menyatakan layanannya beroperasi normal. Laporan yang dirujuk tidak mengidentifikasi akar masalah bersama.

Mengapa cadangan dari vendor lain belum tentu cukup?

Menurut keterangan penyedia, ketiga insiden memiliki penyebab yang berbeda. Kejadian bersamaan ini tidak membuktikan adanya satu sumber gangguan. Namun, mengandalkan vendor berbeda tetap memerlukan pengujian jalur cadangan.

Bagi pengguna layanan, akibat langsungnya sama: fitur tidak tersedia. Laporan analisis insiden (postmortem) membantu perbaikan berikutnya, tetapi tidak memulihkan waktu kerja yang sudah hilang.

Ini merupakan risiko ketergantungan pada layanan luar. Semakin banyak bisnis Indonesia memakai AI, semakin penting pula pengelolaan risiko tersebut. 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). Salah satu pola yang perlu diperiksa ialah satu kunci API digunakan untuk memanggil layanan langsung tanpa jalur cadangan. 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?

Waktu kejadian perlu diperhatikan oleh tim di Indonesia. Pukul 07.43 waktu Pasifik itu 21.43 WIB. Pulihnya pukul 12.38 waktu Pasifik, alias 02.38 WIB dini hari. Rentang ini bertepatan dengan malam hingga dini hari di Indonesia.

Pekerjaan otomatis pada jam tersebut dapat terganggu sebelum petugas menyadarinya: ekstraksi dokumen, pembuatan laporan dini hari, balasan percakapan untuk pelanggan di zona waktu lain, atau klasifikasi data untuk dasbor pagi berikutnya.

Tiga pola kerusakan yang berulang di skenario seperti itu:

• Hilang diam-diam. Pekerjaan memanggil API dan menerima galat 500, tetapi tidak dicoba ulang. Sistem hanya mencatat peringatan yang tidak diperiksa. Dalam contoh ini, kegagalan baru diketahui pada Senin ketika laporan kekurangan 400 baris.
• Percobaan ulang tanpa batas. Pekerjaan terus menghubungi alamat layanan (endpoint) yang tidak tersedia hingga seluruh batas waktunya habis. Catatan sistem terlihat aktif, tetapi pekerjaan tidak selesai.
• Request menggantung. Endpoint yang dipakai pelanggan memanggil model tanpa batas waktu tunggu. Permintaan menumpuk, koneksi habis, dan matinya satu fitur berubah jadi matinya seluruh aplikasi.

Pola ketiga dapat memperluas dampak gangguan. Pelanggan mungkin masih bisa bekerja tanpa fitur AI, tetapi halaman pembayaran yang ikut berhenti akan menghambat transaksi.

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, pengiriman pesanan, pengiriman alarm, pencatatan absensi. Kalau transaksinya tidak bisa tuntas tanpa model menjawab, Anda sedang menaruh proses bisnis di atas uptime milik orang lain.

Kelompokkan panggilan AI berdasarkan dampaknya terhadap penyelesaian pekerjaan.

Saat meninjau sistem, saya sering menemukan panggilan AI yang tanpa sengaja menghalangi pekerjaan utama. Contohnya validasi berbasis model atau pengelompokan otomatis yang harus selesai sebelum data dapat disimpan. Pisahkan pekerjaan itu agar kegagalan model tidak menghentikan penyimpanan.

Cadangan seperti apa yang benar-benar menolong?

Berikut lima langkah yang saya prioritaskan saat menyiapkan jalur cadangan.

1. Simpan pekerjaan dalam antrean. Terima masukan pengguna, simpan secara persisten, lalu berikan respons tanpa menunggu AI. Proses latar belakang (worker) mengerjakan bagian AI setelahnya. Gangguan penyedia kemudian dapat ditangani sebagai keterlambatan pemrosesan. Polanya sama dengan yang membuat 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; tetapkan dari pengukuran waktu respons dan batas waktu yang dibutuhkan pengguna. Batas 20 sampai 30 detik mungkin sesuai untuk percakapan singkat, tetapi terlalu pendek untuk penalaran panjang atau penggunaan alat. 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. Siapkan dan uji penyedia kedua. Pemilihan model berdasarkan tugas juga dapat membantu pengendalian biaya. Mekanismenya serupa dengan bagi per tugas, batasi per hari, dan dapat digunakan untuk pengalihan saat gangguan. Jalur cadangan tetap harus diuji. Kirim sebagian kecil trafik asli ke penyedia kedua tiap minggu. Tanggal 3 September kemarin, tim dengan Gemini sebagai cadangan memiliki jalur yang tetap tersedia.

4. Jalur tanpa AI di lapis paling bawah. Ada kalanya dua penyedia sama-sama tak bisa dihubungi, atau beberapa layanan sejenis mengalami gangguan. Putuskan dari sekarang bentuk layanan terbatas: balasan dari templat, pengelompokan berbasis aturan, atau antrean pemeriksaan manusia. Pekerjaan mungkin lebih lambat, tetapi tetap dapat diselesaikan.

5. Cegah pekerjaan berbayar diproses dua kali. Idempotensi berarti permintaan yang sama tidak menghasilkan pekerjaan ganda. Gunakan kunci berdasarkan identitas pekerjaan, bukan setiap permintaan HTTP, lalu simpan respons pertama yang berhasil dengan kunci tersebut. Tanpa ini, badai percobaan ulang saat gangguan dapat mengirim pekerjaan dua kali. Penyimpanan hasil lokal tidak menjamin penyedia berhenti menagih bila panggilan pertama sudah diproses tetapi responsnya hilang; periksa dukungan idempotensi penyedia dan catat status yang belum pasti.

Apa yang perlu dicek minggu ini?

Mulailah dengan pencarian pada kode dan daftar panggilan API yang dapat diperiksa bersama tim.

• Daftar semua tempat kode Anda memanggil API AI. Termasuk yang di dalam pekerjaan terjadwal dan penangan webhook — di situ biasanya yang terlupa bersembunyi.
• Untuk tiap panggilan: apa yang terjadi setelah 30 detik tanpa jawaban? Kalau jawabannya "kurang tahu", periksa batas waktu tunggu dan penanganan galatnya.
• Percobaan ulangnya dibatasi, dan jedanya makin panjang? Percobaan ulang tanpa batas dapat memperberat gangguan layanan.
• Saat gagal, masukan pengguna disimpan atau hilang? Kehilangan masukan lebih buruk daripada menampilkan pesan galat.
• Apakah ada petugas yang menerima peringatan pukul 22.00 WIB? Dapatkah peringatan membedakan gangguan vendor dari kesalahan kode aplikasi? 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.

Perbedaan komitmen tersebut perlu diperhitungkan. Angka 99,9% terdengar aman sampai Anda sadar sedang menjual ulang 99,5% milik orang lain, dan selisihnya Anda tanggung sendiri.

Tentukan perilaku sistem saat AI tidak merespons

Penyedia AI dapat mengalami gangguan seperti layanan pembayaran atau pasokan listrik. Karena itu, rancangan aplikasi perlu menjelaskan pekerjaan yang tetap berjalan, pekerjaan yang ditunda, dan kapan petugas mengambil alih.

Gangguan tiga penyedia pada pagi yang sama mengingatkan pentingnya keputusan tersebut. Uji respons sistem ketika jawaban tidak datang, termasuk penyimpanan masukan, batas waktu, antrean, dan jalur tanpa AI.