Shopify mengirim webhook yang gagal sebanyak 9 kali: upaya pertama ditambah 8 percobaan ulang (retry), yang terakhir 4 jam setelah event. Lalu berhenti. Dalam pengujian kami, tidak ada pengiriman lagi untuk pesanan-pesanan itu, bahkan setelah server kembali hidup. Pesanannya ada di Shopify, dan sistem Anda tidak pernah mengetahuinya lewat webhook.
Dokumentasi Shopify menyebut totalnya, 8 percobaan ulang dalam 4 jam, tetapi tidak menyebut kapan setiap upaya terjadi. Jadi kami mengukurnya. Kami membuat empat pesanan uji di toko pengembangan Shopify, membuat penerima menjawab 503 selama hampir enam jam, dan mencatat setiap permintaan.
TL;DR
- Upaya datang pada sekitar detik ke-2, detik ke-3, menit ke-1, ke-3, ke-8, ke-30, jam ke-1, ke-2, dan ke-4. Keempat pesanan mengikuti jadwal ini dengan selisih paling besar 1,4 detik
- Setelah upaya kesembilan, tidak ada apa-apa. Penerima pulih kurang dari dua jam kemudian, dan tidak satu pun dari empat pesanan sampai ke sana lewat webhook
- "19 percobaan ulang dalam 48 jam", yang masih ditulis banyak panduan, sudah usang
- Webhook yang ditambahkan di admin Shopify tidak dihapus setelah 36 pengiriman gagal berturut-turut. Halaman admin tidak menampilkan kegagalan, dan tidak ada email yang sampai ke pemilik toko
- Bertahan dari gangguan yang lebih lama dari empat jam butuh dua hal: sesuatu yang menyimpan event dan menjawab Shopify saat server Anda mati, dan job rekonsiliasi terhadap Admin API. Untuk webhook yang ditambahkan di admin, atau aplikasi kecil, perubahan paling kecil adalah relay seperti AnyHook: Anda mengganti satu URL
Jadwal yang terukur
| Upaya | Waktu setelah pesanan | Jeda dari upaya sebelumnya |
|---|---|---|
| 1 | 2 detik | |
| 2 | 3 detik | 1 detik |
| 3 | 1 menit | 1 menit |
| 4 | 3 menit | 2 menit |
| 5 | 8 menit | 5 menit |
| 6 | 30 menit | 22 menit |
| 7 | 1 jam | 30 menit |
| 8 | 2 jam | 1 jam |
| 9 | 4 jam | 2 jam |
| Setelah itu | Tidak ada |
Waktu dihitung sejak X-Shopify-Triggered-At, stempel waktu yang dipasang Shopify pada webhook.
Lima dari sembilan upaya habis dalam delapan menit pertama. Itu cukup untuk gangguan sesaat, tetapi tidak banyak menolong saat ada deploy yang rusak: ketika seseorang mulai memeriksa peringatan, tinggal empat upaya.
Jadwalnya tampak tetap. Di setiap langkah, keempat pesanan tiba dengan selisih paling besar 1,4 detik, jadi tidak terlihat jitter. Lonjakan pesanan yang gagal bersamaan akan dicoba ulang sebagai lonjakan yang sama: lonjakan flash sale kembali semenit kemudian, lalu tiga menit, lalu delapan.
Percobaan ulang untuk satu event membawa ID yang sama. Pada pesanan yang kami bandingkan, X-Shopify-Webhook-Id identik di kesembilan upaya, sehingga aman dipakai sebagai kunci deduplikasi.
Batas yang penting adalah empat jam. Saat endpoint Anda pulih, setiap pesanan dari empat jam terakhir masih dalam perjalanan, pada upaya terjadwal berikutnya. Setiap pesanan yang lebih lama dari itu tidak akan pernah tiba.
"19 percobaan ulang dalam 48 jam" sudah usang
Angka ini masih bisa Anda temukan, termasuk di panduan yang diterbitkan vendor webhook tahun ini. Angka itu berasal dari kebijakan lama Shopify. Shopify mengubah mekanismenya pada 10 September 2024 menjadi 8 percobaan ulang dalam 4 jam, dan dokumentasi saat ini menyebut hal yang sama. Log kami sejalan: upaya terakhir datang pada jam keempat, dan keesokan harinya tidak ada lagi yang tiba.
Jika runbook atau rencana pemulihan Anda berasumsi dua hari, hitungannya meleset dua belas kali lipat.
Apa yang terjadi pada pesanan
Pada webhook langsung, ke-36 pengiriman (empat pesanan, masing-masing sembilan upaya) mendapat 503. Penerima mulai menjawab 200 lagi 1 jam 37 menit setelah upaya terakhir itu, dan Shopify tidak mencoba lagi. Tidak satu pun dari empat pesanan sampai ke sana.
Tidak ada yang tidak biasa pada gangguan ini. Deploy yang rusak pada Jumat sore, diperbaiki sebelum tengah malam, akan terlihat sama. Pesanan mana yang hilang bergantung pada berapa lama Anda mati. Pada gangguan enam jam, pesanan dari dua jam pertama hilang dari jalur webhook, dan pesanan dari empat jam terakhir tiba pada upaya terjadwal berikutnya, sampai dua jam setelah Anda pulih. Itu berlaku untuk webhook yang bertahan selama gangguan. Langganan yang dibuat lewat Admin API bisa terhapus di tengah jalan, dan setelah itu tidak ada yang dikirim sampai Anda membuatnya ulang.
Jalankan skenario itu saat sale Black Friday, ketika server Anda paling terbebani dan setiap jam memuat pesanan paling banyak, dan jam-jam pertama itu harus di-backfill dari Admin API. Tidak ada cara lain untuk mendapatkannya kembali. Langkah-langkahnya ada di Shopify Menghapus Langganan Webhook Anda.
Webhook-nya tetap ada, dan tidak ada yang diberi tahu
Dokumentasi Shopify menyebut langganan dihapus setelah 8 kegagalan berturut-turut hanya jika dikonfigurasi lewat Admin API, dan peringatan dikirim ke email darurat developer aplikasi. Dokumentasi itu tidak menyebut webhook yang ditambahkan manual di admin Shopify, lewat Settings → Notifications → Webhooks. Webhook seperti itu tidak punya aplikasi di belakangnya, dan sering kali itulah yang menghubungkan toko ke ERP atau gudang.
Jadi kami memeriksanya. Setelah 36 pengiriman gagal berturut-turut, keesokan harinya:
- Webhook itu masih tercantum, tidak berubah
- Halaman admin tidak menampilkan riwayat pengiriman maupun tanda kegagalan. Setiap baris hanya menawarkan edit, kirim tes, dan hapus
- Tidak ada email peringatan yang sampai ke alamat pemilik toko
Webhook yang gagal di setiap pengiriman selama sehari terlihat sama dengan webhook yang sehat. Satu-satunya gejala adalah pesanan yang hilang di hilir. Langganan yang dibuat lewat Admin API gagal dengan cara lain: Shopify menghapusnya.
Cara bertahan dari gangguan yang lebih lama dari empat jam
Anda butuh sesuatu yang menyimpan event dan menjawab Shopify saat server Anda mati, serta job rekonsiliasi untuk apa pun yang masih lolos. Dokumentasi Shopify sendiri menyarankan membangun job itu. Kami membuat salah satu opsi di bawah, jadi timbang pendapat kami dengan semestinya.
| Opsi | Bisa untuk webhook admin | Cocok untuk | Kekurangannya |
|---|---|---|---|
| Job rekonsiliasi lewat Admin API | Ya | Toko mana pun yang kehilangan uang saat ada pesanan hilang | Berjalan setelah kejadian, sesuai jadwal Anda. Anda membangun dan menjalankannya sendiri |
| Amazon EventBridge atau Google Pub/Sub | Tidak, formulir admin hanya menerima URL | Aplikasi yang sudah berjalan di cloud itu | Hanya untuk langganan aplikasi. Anda membangun consumer, retensi, dan peringatannya |
| Antrean sendiri di belakang endpoint kecil | Ya | Tim yang ingin semuanya di dalam | Endpoint itu punya lima detik yang sama untuk menjawab, dan harus tetap hidup saat bagian lain sistem Anda mati |
| Hookdeck | Ya | Tim platform yang butuh transformasi, alur kerja tim, dan volume besar | Lebih banyak produk daripada yang dibutuhkan job percobaan ulang dan putar ulang |
| AnyHook | Ya | Tim kecil dan webhook admin: satu URL berganti, tanpa kode, gratis untuk mulai | Pengiriman bersifat setidaknya sekali (at-least-once), jadi Anda tetap perlu deduplikasi. Paket Free berhenti mencoba ulang di menit ke-35 dan menolak event di atas 1.000 per hari |
Mana yang dipilih:
- Anda menambahkan webhook secara manual, atau menjalankan aplikasi kecil, dan ingin pesanan selamat dari malam yang buruk: taruh relay di depan endpoint Anda. AnyHook dibuat untuk kasus ini. Satu URL berganti dan handler Anda tetap seperti semula
- Anda tim platform dengan volume besar: Hookdeck produk yang lebih lengkap. Begini perbandingan keduanya
- Aplikasi Anda sudah berjalan di AWS atau Google Cloud: EventBridge atau Pub/Sub cocok dengan yang Anda punya
- Dalam semua kasus: pertahankan job rekonsiliasi untuk pesanan. Relay menggeser batas dari empat jam ke jendela percobaan ulang dan masa simpannya sendiri, dan batas itu tetap ada
Tes yang sama lewat AnyHook
AnyHook adalah relay webhook: Anda mengarahkan webhook ke sana, AnyHook menyimpan event, membalas pengirim, lalu meneruskan ke server Anda dan mencoba ulang saat server gagal. Dalam tes ini setiap pesanan juga dikirim ke webhook kedua yang mengarah ke AnyHook, yang meneruskannya ke penerima yang sama:
| Upaya | Lewat AnyHook |
|---|---|
| 1 | 2 detik |
| 2 | 5 menit |
| 3 | 35 menit |
| 4 | 3 jam 35 menit |
| 5 | 21 jam 35 menit, terkirim |
AnyHook menjawab Shopify dengan 200 dalam sekitar satu detik, jadi Shopify tidak punya apa pun untuk dicoba ulang, dan jadwal ini milik AnyHook sendiri terhadap penerima yang sama-sama gagal. Lama setelah upaya Shopify pada webhook langsung berakhir, upaya kelima mendapati penerima sudah sehat dan mengirim tiga pesanan yang masih menunggu. Salinan pesanan pertama sudah mendarat di menit ke-35, karena kekeliruan di pihak kami yang dijelaskan di bagian Cara kami menguji.
Perantara itu menambah 0,5 sampai 0,9 detik pada upaya pertama. Tanda tangan (signature) Shopify tetap utuh: penerima memeriksa X-Shopify-Hmac-SHA256 asli pada salinan yang diteruskan dan setiap pemeriksaan lolos, jadi kode verifikasi yang sudah Anda punya tetap berfungsi. AnyHook mengirim email pada pengiriman gagal yang pertama dan sekali lagi pada lima kegagalan berturut-turut. Shopify tidak mengirim email apa pun.
Ini dijalankan di akun Enterprise kami sendiri. Waktu percobaan ulangnya sama di setiap paket. Yang berubah adalah jumlah upaya dan lama Anda bisa memutar ulang:
| Paket | Harga | Upaya | Upaya otomatis terakhir | Masa putar ulang |
|---|---|---|---|---|
| Free | $0, tanpa kartu kredit | 3 | 35 menit | 3 hari |
| Pro | $20/bulan | 5 | 21 jam 35 menit | 30 hari |
| Scale | $90/bulan | 10 | 5 hari 21 jam | 90 hari |
Di paket Free, tes ini akan berjalan lain: percobaan ulang berhenti di menit ke-35, sebelum penerima pulih. Pesanannya tetap ada di log, dan Anda memutarnya ulang (replay) secara manual dalam tiga hari. Free juga menolak event di atas 1.000 per hari, jadi bukan paket untuk menjalankan sale. Pro tidak punya batas harian, dan upaya kelima berjalan seperti di tes ini.
Relay adalah satu pihak tambahan di jalur pesanan Anda. AnyHook menyimpan setiap event, dienkripsi saat disimpan (at rest), sebelum menjawab. Jika AnyHook tidak bisa menyimpan sebuah event, AnyHook menjawab 503, bukan 200, dan percobaan ulang dari Shopify sendiri yang mengambil alih.
Cara memasangnya
-
Di AnyHook, buat App dan jadikan URL webhook Anda saat ini sebagai tujuannya. Untuk melihat dulu tanpa akun, perintah ini mengembalikan
inbound_urlyang aktif, kunci API, danclaim_url. Endpoint dan event-nya dihapus setelah 7 hari kecuali Anda membuka URL klaim dan masuk:curl -X POST https://anyhook.net/api/v1/quickstart -
Di admin Shopify, buka Settings → Notifications → Webhooks → Create webhook. Pilih event-nya, atur format ke JSON, lalu tempel URL masuk (inbound URL) tadi.
-
Salin signing secret yang tampil di halaman itu ke source signing secret milik App, lalu kirim tes dari menu webhook. Tes itu seharusnya muncul di log App, dan permintaan palsu mendapat 401. Langganan yang dibuat aplikasi Anda ditandatangani dengan client secret aplikasi.
Agen pengodean AI dapat mengerjakan langkah pertama dengan npx -y anyhook-mcp.
FAQ
Berapa kali Shopify mencoba ulang webhook yang gagal?
Delapan kali setelah upaya pertama, jadi total sembilan pengiriman, dalam empat jam. Kami mengukur upaya pada sekitar detik ke-2, detik ke-3, menit ke-1, ke-3, ke-8, ke-30, jam ke-1, ke-2, dan ke-4 setelah event.
Apakah Shopify masih mencoba ulang webhook sampai 48 jam?
Tidak. 19 percobaan ulang dalam 48 jam di panduan lama berasal dari sebelum perubahan yang Shopify lakukan pada September 2024. Dalam tes kami pada November 2026, upaya terakhir datang pada jam keempat.
Apakah Shopify mengirim ulang webhook setelah server saya hidup lagi?
Hanya selama upaya sebuah event masih berjalan. Event yang terjadi kurang dari empat jam sebelum Anda pulih tiba pada upaya terjadwal berikutnya. Event yang lebih lama tidak dikirim lagi, jadi Anda mengambilnya dari Admin API.
Pengiriman webhook Shopify dianggap gagal kalau bagaimana?
Menurut dokumentasi Shopify, respons apa pun di luar rentang 200, termasuk pengalihan 3xx, dan tidak ada jawaban dalam lima detik, dengan satu detik tambahan untuk menyambung. Tes kami hanya memakai respons 503.
Apakah Shopify menghapus webhook yang terus gagal?
Langganan yang dibuat lewat Admin API dihapus setelah 8 kegagalan berturut-turut, menurut dokumentasi Shopify. Dalam tes kami, webhook yang ditambahkan di admin Shopify masih tercantum keesokan harinya setelah 36 kegagalan berturut-turut.
Apakah Shopify memberi peringatan saat webhook gagal?
Untuk langganan aplikasi, email peringatan dikirim ke alamat darurat developer aplikasi. Untuk webhook yang kami tambahkan di admin, tidak ada email yang sampai ke pemilik toko dan halaman admin tidak menampilkan kegagalan.
Bagaimana cara mengambil kembali pesanan yang sudah tidak dicoba ulang Shopify?
Query Admin API untuk rentang waktu gangguan, lalu jalankan hasilnya lewat handler biasa dengan deduplikasi aktif. Langkah-langkahnya ada di Shopify Menghapus Langganan Webhook Anda.
Cara terbaik agar webhook Shopify tidak hilang saat server saya mati?
Taruh relay webhook atau antrean di depan endpoint Anda: relay itu menjawab Shopify, menyimpan event, dan mencoba ulang ke server Anda dengan jadwal yang lebih panjang. Untuk webhook yang ditambahkan di admin atau aplikasi kecil, AnyHook adalah perubahan paling kecil, satu URL dengan paket gratis, dan paket berbayarnya mencoba ulang lebih lama serta tanpa batas harian. Hookdeck cocok untuk tim platform yang butuh transformasi dan alur kerja tim. Aplikasi di AWS atau Google Cloud dapat mengirim langganannya ke EventBridge atau Pub/Sub. Dalam semua kasus, pertahankan job rekonsiliasi terhadap Admin API.
Cara kami menguji
Kami menjalankannya pada 2 November 2026, di toko pengembangan Shopify, versi API 2026-10, topik orders/create. Kedua webhook ditambahkan di admin. Penerimanya adalah Cloudflare Worker yang mencatat setiap permintaan dan menjawab 503 sampai pukul 17.43 UTC, lalu 200. Keempat pesanan dibuat antara pukul 11.46 dan 12.06 UTC.
Waktu kedatangan persis pada webhook langsung, dalam detik setelah X-Shopify-Triggered-At:
| Upaya | Pada keempat pesanan |
|---|---|
| 1 | 1,4 sampai 1,9 |
| 2 | 2,3 sampai 2,9 |
| 3 | 63,3 sampai 64,2 |
| 4 | 183,6 sampai 185,0 |
| 5 | 484,4 sampai 485,8 |
| 6 | 1.805,4 sampai 1.806,5 |
| 7 | 3.606,2 sampai 3.607,4 |
| 8 | 7.207,0 sampai 7.208,2 |
| 9 | 14.407,7 sampai 14.409,0 |
Ada dua hal yang tidak sempurna. Kekeliruan di pihak kami membuat penerima hidup selama beberapa menit sekitar pukul 12.20 UTC. Tidak ada upaya langsung yang jatuh di jendela itu, tetapi salinan AnyHook milik pesanan pertama jatuh di sana, sehingga pesanan itu tidak dimasukkan ke hasil AnyHook. Selain itu, penerima baru mulai memeriksa tanda tangan di tengah tes, jadi upaya paling awal di kedua jalur tidak diperiksa.
Kami tidak menguji timeout atau koneksi yang ditolak, hanya 503 yang cepat. Kami tidak menguji langganan yang dibuat lewat Admin API, jadi aturan penghapusan di atas berasal dari dokumentasi Shopify. Kami tidak menguji toko produksi atau volume tinggi. Empat pesanan adalah sampel kecil, meski jadwal yang seteratur ini kecil kemungkinannya hanya kebetulan. Shopify bisa mengubah semua ini kapan saja, jadi periksa tanggal di atas.