Sending & Logs — Status dan Timeline
Setiap pesan yang dikirim lewat dashboard, REST API, atau SMTP tercatat di Sending & Logs: status terkini, alasan kegagalan bila ada, dan timeline event dari penyedia pengiriman.
Membuka log
Buka dashboard → Sending & Logs. Daftar mendukung filter status, pencarian (pengirim, penerima, subjek), dan rentang tanggal. Klik satu baris untuk membuka halaman detail pesan yang memuat timeline lengkap. Tombol Sinkronkan memaksa penarikan event terbaru dari penyedia bila Anda tidak ingin menunggu siklus sinkronisasi berikutnya.
Arti setiap status
Status pesan hanya bergerak maju. Event yang datang terlambat — misalnya laporanaccepted yang baru tiba setelah delivered — tidak pernah menurunkan status terbaru.
| Status | Artinya | Dana |
|---|---|---|
reserved | Permintaan diterima dan sedang diserahkan ke penyedia | Dicadangkan |
accepted | Penyedia menerima tanggung jawab mengirim; hasil akhir menyusul | Ditagihkan |
delivered | Penyedia melaporkan pesan tersampaikan ke server tujuan penerima | Ditagihkan |
failed | Penyedia menolak pada saat submit (deterministik) — tidak ada pengiriman yang terjadi | Dikembalikan otomatis |
rejected | Pesan ditolak setelah diterima penyedia (mis. kebijakan penerima) | Ditagihkan |
bounced | Pesan tidak bisa dikirim ke alamat tujuan (mailbox tidak ada, domain mati) | Ditagihkan |
complained | Penerima menandai pesan sebagai spam | Ditagihkan |
reconcile_pending | Hasil pengiriman belum pasti (gangguan di sisi penyedia) dan menunggu rekonsiliasi | Ditahan — belum dibebankan maupun dikembalikan |
Detail perilaku dana ada di Billing & Saldo.
Timeline event
Halaman detail pesan menampilkan setiap event yang dilaporkan penyedia, lengkap dengan waktu kejadian, jenis event, penerima (untuk pengiriman multi-penerima), kode/severity, dan alasan bila ada — misalnya550 5.1.1 mailbox unavailable untuk bounce. Event yang sama tidak pernah tercatat dua kali; laporan ulang dari penyedia diabaikan secara idempoten.
Bagaimana log diperbarui
- Real-time: penyedia mengirim event pengiriman ke Hubina begitu terjadi, dan pesan yang cocok langsung diperbarui. Mekanismenya dijelaskan di Webhook & Delivery Events.
- Fallback berkala: setiap 5 menit sistem menarik ulang event terbaru untuk pesan yang belum final, sehingga laporan yang gagal terkirim tetap masuk.
- Manual: tombol Sinkronkan di halaman log memicu penarikan segera.
Mendiagnosis dengan Sending & Logs
- Cari pesannya. Pakai pencarian: alamat penerima, subjek, atau pengirim. Untuk API, cocokkan juga dengan
idpesan (msg_…) yang dikembalikan saat kirim. - Lihat status terakhir.
reservedyang lama berarti pesan belum diserahkan; cek saldo dan status domain. - Baca timeline. Status
bounceddisertai alasan dari penyedia penerima — biasanya masalah di alamat tujuan, bukan di konfigurasi Anda. - Untuk status
reconcile_pending, jangan mengirim ulang: pesan mungkin sudah diterima penyedia. Sinkronkan ulang dan periksa kembali setelah beberapa menit. - Bandingkan dengan filter. Jika hanya satu alamat yang gagal, kemungkinan besar masalah penerima; jika semua gagal, periksa domain, saldo, dan kredensial lewat Troubleshooting.
Log berisi metadata, bukan isi pesan Yang tersimpan adalah pengirim, penerima, subjek, status, dan event dari penyedia. Isi email tidak pernah disimpan sehingga tidak bisa dilihat kembali dari dashboard.