Hitungan 24 Jam CRA Dimulai 11 September 2026: Pastikan Ada yang Mengangkat

Daftar Isi

Apa persisnya yang dimulai pada 11 September 2026?
Siapa yang sebenarnya terikat kewajiban ini?
Mengapa tenggat 24 jam adalah masalah peringatan?
Apa isi peringatan dini 24 jam itu sebenarnya?
Bagaimana cara menaruh ponsel yang berdering di depan hitungan 24 jam?
Langkah 1 — Buat saluran Panggilan khusus untuk kandidat CRA
Langkah 2 — Arahkan jalur deteksi Anda ke saluran itu
Langkah 3 — Gunakan kondisi agar hanya kandidat yang masuk akal yang berdering
Langkah 4 — Tangkap sistem yang hanya bisa mengirim email
Langkah 5 — Masukkan setiap perwakilan terdaftar ke saluran itu
Langkah 6 — Latih sebelum 11 September, bukan sesudahnya
Apa yang tidak dilakukan Echobell
FAQ
Apakah memakai Echobell membuat kami patuh CRA?
Kapan sebenarnya hitungan 24 jam itu mulai?
Kami perusahaan kecil. Apakah kami dikecualikan?
Kotak masuk keamanan kami dipantau pada jam kerja. Apakah itu belum cukup?
Bisakah tim kepatuhan, hukum, dan teknik mendapat peringatan yang sama?
Apakah ini membantu untuk kewajiban Pasal 14(8) memberi tahu pengguna?
Kami sudah melapor di bawah NIS2 atau DORA. Apakah ini sama?
Apakah panggilannya benar-benar menembus Jangan Ganggu?
Apakah ini hanya untuk iOS?
Apa yang sebaiknya kami taruh di payload webhook?
Terkait

Pada 11 September 2026, kewajiban pelaporan dalam EU Cyber Resilience Act mulai berlaku. Sejak tanggal itu, produsen yang mengetahui adanya kerentanan yang sedang aktif dieksploitasi pada produk dengan elemen digital — atau insiden parah yang memengaruhi produk tersebut — punya 24 jam untuk mengirim peringatan dini ke CSIRT koordinatornya dan ke ENISA (Komisi Eropa, Regulation (EU) 2024/2847).

Tenggat itu punya sifat yang tidak dimiliki kebanyakan tenggat kepatuhan: ia berjalan mengikuti jam dinding. Tidak ada pengecualian hari kerja, tidak ada jeda akhir pekan, dan tidak ada masa tenggang selagi penanggung jawab pelaporan Anda sedang di dalam pesawat. Dan platform tempat Anda melapor, Single Reporting Platform milik ENISA, berupa formulir web — "tidak ada Application Programming Interface yang akan disediakan pada tahap ini" (FAQ ENISA). Harus ada manusia bernama jelas yang masuk dan mengirimkannya.

Itulah yang membuat aturan 24 jam ini menjadi masalah peringatan sebelum menjadi masalah dokumen. Panduan ini menunjukkan cara mengarahkan momen "mengetahui" itu ke ponsel yang berdering memakai Echobell, sekaligus jujur soal bagian besar kesiapan CRA yang sama sekali tidak disentuh alat notifikasi mana pun.

Apa persisnya yang dimulai pada 11 September 2026?

Produsen produk dengan elemen digital wajib melaporkan kerentanan yang aktif dieksploitasi dan insiden parah melalui satu platform Uni Eropa, mengikuti hitungan waktu bertahap yang dimulai begitu mereka mengetahuinya. Semua hal lain dalam CRA — penandaan CE, persyaratan esensial di Annex I, penilaian kesesuaian — berlaku mulai 11 Desember 2027. Kewajiban pelaporan datang lima belas bulan lebih awal, dan berlaku untuk produk yang sudah beredar di pasar, bukan hanya untuk yang Anda rilis setelah tanggal tersebut (cyberresilienceact.eu).

Pasal 14 menetapkan dua jalur paralel dengan bentuk yang sama:

Tahap	Kerentanan yang aktif dieksploitasi — Ps. 14(2)	Insiden parah — Ps. 14(4)
Peringatan dini	Dalam 24 jam sejak mengetahuinya	Dalam 24 jam sejak mengetahuinya
Notifikasi	Dalam 72 jam sejak mengetahuinya	Dalam 72 jam sejak mengetahuinya
Laporan akhir	Paling lambat 14 hari setelah tindakan korektif atau mitigasi tersedia	Dalam satu bulan setelah notifikasi 72 jam

Bunyinya adalah "tanpa penundaan yang tidak semestinya dan dalam hal apa pun dalam 24 jam sejak produsen mengetahuinya" (Pasal 14). Dua puluh empat jam adalah batas atas, bukan target.

Pasal 14(5) menetapkan ambang untuk "parah": sebuah insiden memenuhi syarat jika ia merugikan, atau berpotensi merugikan, kemampuan produk untuk menjaga ketersediaan, keaslian, integritas, atau kerahasiaan data maupun fungsi yang sensitif atau penting, atau jika insiden itu telah atau berpotensi menyebabkan masuknya maupun dieksekusinya kode berbahaya. Frasa "berpotensi" itu penting — Anda bisa berkewajiban melapor sebelum ada satu pun hal yang benar-benar merugikan pelanggan.

Pasal 14(8) menambahkan kewajiban kedua yang berjalan paralel: Anda juga harus memberi tahu pengguna produk yang terdampak tentang kerentanan atau insiden tersebut, dan bila perlu tentang langkah korektif yang bisa mereka ambil. Itu audiens yang berbeda dari CSIRT, dengan jalurnya sendiri.

Siapa yang sebenarnya terikat kewajiban ini?

Produsen produk dengan elemen digital, di mana pun mereka berdomisili, ditambah steward perangkat lunak sumber terbuka dalam cakupan yang lebih sempit. Perusahaan di luar Uni Eropa yang menjual ke wilayah Uni tidak lolos dari kewajiban ini; regulasi mengharapkan ada pelaku ekonomi di Uni Eropa yang bertanggung jawab atas kewajiban terkait (cyberresilienceact.eu).

Anda melapor ke CSIRT yang ditunjuk sebagai koordinator di Negara Anggota tempat kedudukan utama Anda di Uni Eropa, sekaligus ke ENISA — tetapi Anda mengirimkannya sekali saja, lewat Single Reporting Platform, yang meneruskannya ke keduanya (Komisi Eropa).

Steward perangkat lunak sumber terbuka termasuk dalam cakupan untuk sebagian ketentuan tertentu: kewajiban Pasal 14(1) berlaku sejauh mereka terlibat dalam pengembangan produk dengan elemen digital, dan Pasal 14(3) serta 14(8) berlaku sejauh insiden parah memengaruhi sistem jaringan dan informasi yang mereka sediakan untuk pengembangan itu. Jika Anda menjadi steward proyek yang dipakai luas, bacalah Pasal 24 berdampingan dengan Pasal 14 alih-alih mengasumsikan salah satu ekstrem.

Pasal 15 juga memperbolehkan pelaporan sukarela — atas kerentanan, ancaman siber, insiden, dan nyaris celaka — baik oleh produsen maupun siapa saja. Laporan sukarela tidak menciptakan kewajiban baru, tetapi platformnya sama, dan masalah "harus ada orang yang terjaga" juga berlaku.

Mengapa tenggat 24 jam adalah masalah peringatan?

Karena hitungannya dimulai saat Anda mengetahui, dan pengetahuan itu jarang datang pada jam kerja. Pemicunya adalah sebuah fakta yang sampai ke organisasi Anda, bukan keputusan yang dibuat organisasi Anda.

Perhatikan dari mana fakta itu biasanya berasal. Seorang peneliti keamanan mengirim email ke security@ pukul 23.40 di hari Sabtu. Pelanggan di hilir membuka tiket dukungan yang menggambarkan adanya eksploitasi. Umpan CVE atau KEV menyala untuk komponen yang Anda pakai. EDR Anda sendiri menandai eksekusi di sistem build. Catatan kesiapan dari DLA Piper menyoroti versi rantai pasok dari masalah ini secara khusus: produsen sering bukan pihak pertama yang tahu, dan informasi datang lewat importir, distributor, peneliti, atau pemasok komponen (DLA Piper).

Setiap jalur itu berujung pada sebuah notifikasi yang, dengan setelan Anda saat ini, kemungkinan besar dikirim tanpa suara — email di kotak masuk bersama, pesan Slack di kanal yang tak dipantau semalaman, tiket di antrean yang baru ditriase hari Senin. Tidak satu pun dari mereka gagal. Semuanya terkirim dengan benar, kepada tak seorang pun.

Tiga detail membuat celahnya lebih parah daripada kelihatannya:

Tidak ada API. ENISA menyatakan dengan gamblang bahwa tidak ada API pelaporan yang akan disediakan pada tahap ini. Anda tidak bisa menyuruh skrip mengirimkan peringatan dini selagi semua orang tidur.
Aksesnya disiapkan per orang, jauh-jauh hari. Perwakilan yang berwenang mendaftar dengan akun EU Login, dan CSIRT koordinator yang ditunjuk memvalidasi kewenangan mereka setelah akses pertama. Ada perwakilan utama dan cadangan sekunder, dan undangan untuk cadangan itu kedaluwarsa setelah tujuh hari (FAQ ENISA, cyberresilienceact.eu). Kalau satu-satunya orang yang bisa melapor tak bisa dihubungi, tenggatnya tidak peduli.
Tingkat sanksinya yang tertinggi. Pasal 64 menempatkan ketidakpatuhan terhadap kewajiban Pasal 13 dan 14 pada rentang denda administratif "hingga EUR 15.000.000 atau, jika pelanggarnya adalah suatu usaha, hingga 2,5% dari total omzet tahunan globalnya pada tahun buku sebelumnya, mana yang lebih tinggi" (Pasal 64).

Satu catatan jujur untuk poin terakhir itu, karena mengubah perhitungan bagi tim kecil: Pasal 64 mengecualikan produsen yang tergolong usaha mikro atau usaha kecil dari denda administratif karena tidak memenuhi tenggat di Pasal 14(2)(a) atau 14(4)(a) — yaitu khusus peringatan dini 24 jam. Kewajiban melapornya tetap ada, dan pengecualian itu tidak meluas ke notifikasi 72 jam atau bagian lain Pasal 14. Bacalah pasalnya, dan mintalah nasihat hukum, alih-alih mengandalkan tulisan blog untuk menentukan di mana posisi perusahaan Anda.

Apa isi peringatan dini 24 jam itu sebenarnya?

Sangat sedikit — dan justru itu intinya. Panduan ENISA menyebut satu set kolom wajib yang kecil pada tahap peringatan dini: jenis notifikasi (kerentanan atau insiden), tingkat notifikasi, waktu pelaporan, informasi pelapor, nama produsen atau steward, produknya, sebuah judul, dan untuk insiden apakah ada dugaan perbuatan melawan hukum atau berniat jahat. Kolom opsional pada tahap itu mencakup CVE ID atau EUVD ID.

Gambaran teknis yang lebih lengkap — sifat umum kerentanan atau eksploitasinya, penilaian awal, langkah korektif dan mitigasi — masuk ke notifikasi 72 jam, bukan ke 24 jam pertama.

Jadi peringatan dini bukan proyek riset. Ia adalah formulir singkat yang bisa diisi orang yang sudah siap dalam hitungan menit. Kendala yang mengikat bukanlah formulirnya, melainkan apakah orang yang sudah terdaftar, berwenang, dan terjaga mengetahuinya tepat waktu. Itu masalah perutean notifikasi, dan itu bisa diselesaikan hari ini.

Bagaimana cara menaruh ponsel yang berdering di depan hitungan 24 jam?

Echobell mengubah panggilan webhook atau sebuah email menjadi peringatan yang berdering dan bergetar seperti panggilan masuk, dan itulah yang membuatnya menembus Mode Fokus iOS dan Jangan Ganggu (lihat menembus Mode Fokus iOS). Penyiapan di bawah ini berdampingan dengan proses tiket dan PSIRT yang sudah Anda jalankan — bukan menggantikannya.

Langkah 1 — Buat saluran Panggilan khusus untuk kandidat CRA

Di aplikasi, buat sebuah saluran lalu setel jenis notifikasinya ke Panggilan (jenis notifikasi). Beri nama sesuai keputusan yang dipicunya, bukan sesuai sumber datanya: "CRA — hitungan 24 jam mungkin sudah mulai" lebih baik daripada "Peringatan keamanan".

Saluran ini harus tetap sepi. Kalau ia berdering untuk setiap advisory, setiap pemindaian gagal, dan setiap pembaruan dependensi, orang akan berhenti mengangkatnya, dan Anda sudah menghabiskan satu-satunya saluran nyaring Anda untuk kebisingan. Arahkan hal-hal itu ke tempat lain — panduan kelelahan peringatan membahas pemisahannya.

Salin URL webhook saluran dari halaman detailnya; bentuknya seperti https://hook.echobell.one/t/<channel-token>. Perlakukan sebagai rahasia, karena siapa pun yang memegangnya bisa membuat ponsel tim Anda berdering (panduan webhook).

Setel templat yang mudah dibaca di layar kunci pada pukul 02.00 oleh orang yang setengah sadar:

Title: Possible CRA report — {{product}}
Body: {{kind}} — {{summary}} (aware since {{time}} UTC)

{{time}}, {{date}}, {{hour}} dan variabel waktu sistem lainnya selalu disisipkan dalam UTC, jadi notifikasinya tetap mencatat stempel waktu meski pengirim lupa menyertakannya. Stempel waktu itu bukan bukti hukum kapan pengetahuan itu dimulai, tetapi berguna sebagai patokan saat Anda menyusun ulang linimasanya nanti.

Langkah 2 — Arahkan jalur deteksi Anda ke saluran itu

Sistem apa pun yang bisa memanggil webhook dapat memicu saluran ini. Kolom yang Anda kirim akan menjadi variabel templat:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "actively exploited vulnerability",
    "summary": "researcher report, working exploit attached",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

Variabel khusus externalLink menjadi tautan yang bisa diklik di catatan notifikasi, sehingga saat mengangkat panggilan, si penanggap hanya berjarak satu ketukan dari tiket yang memuat detailnya.

Yang layak dihubungkan, kira-kira urut berdasarkan seberapa sering ia menjadi sinyal pertama:

Antrean PSIRT atau penerimaan laporan keamanan Anda — sebuah webhook ketika sebuah isu diberi label sebagai kandidat CRA.
Security advisory GitHub dan peringatan Dependabot pada repositori yang membangun produk yang Anda rilis (integrasi GitHub).
SIEM, EDR, atau WAF Anda, untuk deteksi terhadap infrastruktur build, rilis, atau penandatanganan — Pasal 14(5) secara eksplisit mencakup insiden yang bisa menyebabkan masuknya kode berbahaya.
Umpan intelijen kerentanan yang sudah Anda konsumsi, disaring ke komponen yang muncul di SBOM Anda sendiri.

Langkah 3 — Gunakan kondisi agar hanya kandidat yang masuk akal yang berdering

Inilah langkah yang menjaga kredibilitas saluran. Kondisi Echobell mengevaluasi variabel dan header HTTP yang sama dengan yang dipakai templat Anda, dan sebuah saluran hanya terpicu ketika ekspresinya bernilai benar:

craCandidate == true && confirmed == true

Atau gunakan header sebagai gerbang jika sistem pengirim tidak bisa mengatur isi bodinya:

header["x-cra-severity"] == "reportable"

Tetapkan ambangnya pada "orang yang kompeten sebaiknya melihat ini dalam satu jam", bukan pada "ini pasti wajib dilaporkan". Memutuskan apakah Pasal 14 berlaku adalah penilaian yang butuh manusia dengan fakta lengkap; tugas saluran ini adalah mempertemukan manusia itu dengan faktanya secepat mungkin. Menyaring terlalu ketat di sini adalah kesalahan yang mahal, karena laporan yang tak pernah Anda mulai lebih buruk daripada panggilan yang ternyata tak perlu.

Langkah 4 — Tangkap sistem yang hanya bisa mengirim email

Sebagian besar kontak pertama dari luar perusahaan Anda datang sebagai email — dari peneliti, pelanggan, CSIRT nasional, vendor komponen. Setiap saluran Echobell bisa punya alamatnya sendiri, jadi satu aturan penerusan di security@ mengubah pesan-pesan itu menjadi panggilan (pemicu email).

Pemicu email menyediakan from, to, subject, text, dan html sebagai variabel, sehingga Anda bisa menyaring tanpa mem-parsing apa pun:

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

Mintalah pelapor rutin dan pemasok utama Anda memakai penanda subjek yang disepakati, lalu cocokkan dengannya. Ini detail kontrak yang kecil tetapi mengubah kotak masuk yang tak terstruktur menjadi sinyal yang bisa dirutekan.

Langkah 5 — Masukkan setiap perwakilan terdaftar ke saluran itu

Bagikan saluran itu kepada semua orang yang benar-benar bisa melapor: perwakilan berwenang utama, cadangan sekunder, dan pemimpin keamanan yang berwenang memutuskan soal Pasal 14. Setiap pelanggan memilih jenis notifikasinya sendiri, sehingga orang yang sedang bertugas bisa memakai Panggilan sementara sisanya memakai Peka Waktu.

Inilah inti dari seluruh latihan ini. SRP mensyaratkan manusia yang terdaftar dan tervalidasi. Jika hanya ada satu orang di perusahaan Anda yang terdaftar, tenggat 24 jam Anda punya satu titik kegagalan tunggal yang bergantung pada baterai ponsel.

Langkah 6 — Latih sebelum 11 September, bukan sesudahnya

Dua latihan, keduanya layak dilakukan bulan ini:

Jalur peringatannya. Jalankan perintah curl di atas dengan Jangan Ganggu benar-benar aktif, di ponsel yang memang akan berada di meja samping tempat tidur seseorang. Nyalakan Retry Failed Call di aplikasi agar panggilan yang gagal sekali akan dicoba lagi. Jalur eskalasi yang tak pernah diuji hanyalah asumsi.
Jalur pelaporannya. Telusuri satu laporan di atas kertas, memakai panduan pendaftaran dan pengiriman langkah demi langkah dari ENISA, yang diperbarui sampai Agustus 2026 (SRP ENISA). Buat akun EU Login sekarang, pastikan CSIRT mana yang menjadi koordinator Anda, dan kirimkan undangan perwakilan sekunder lebih awal — undangan itu kedaluwarsa setelah tujuh hari.

Latihan kedua punya kerumitan yang perlu Anda tahu: per panduan ENISA bulan Juli, URL publik platform itu masih tercantum sebagai "akan disediakan saat peluncuran", sehingga uji ujung ke ujung secara langsung belum memungkinkan (cyberresilienceact.eu). ENISA berkomitmen platform itu akan beroperasi pada 11 September 2026. Latih semua yang bisa Anda kendalikan dan jangan jadikan kesiapan platform sebagai alasan menunda kesiapan Anda sendiri.

Apa yang tidak dilakukan Echobell

Bersikap spesifik soal ini lebih penting daripada biasanya, karena topiknya menyangkut regulasi:

Ia tidak membuat Anda patuh. Echobell adalah kanal notifikasi. Menentukan cakupan produk Anda, menjalankan proses penanganan kerentanan, memutuskan apakah Pasal 14 berlaku, mendaftar ke SRP, dan melapor tepat waktu semuanya tetap tanggung jawab Anda. Tidak ada alat peringatan yang pernah memenuhi sebuah kewajiban pelaporan.
Ia tidak melaporkan apa pun. Tidak ada API untuk melapor, dan seandainya ada pun Echobell bukan pihak yang memanggilnya. Ia membuat ponsel berdering; manusia terdaftarlah yang mengerjakan sisanya.
Ia bukan stempel waktu legal. Variabel {{time}} mencatat kapan pemicu itu sampai ke Echobell, dalam UTC. Kapan "mengetahui" itu dimulai adalah pertanyaan faktual tentang organisasi Anda, dan catatan insiden Anda — bukan notifikasi push — yang mendokumentasikannya.
Ia tidak punya kebijakan eskalasi atau tanda terima. Tidak ada "kalau tak ada yang mengangkat dalam sepuluh menit, telepon orang berikutnya", tidak ada rotasi, tidak ada jejak audit siapa mengakui apa. Untuk itu Anda butuh platform insiden — lihat alternatif Opsgenie.
Ia tidak bisa menjamin pengiriman. Sebuah panggilan bergantung pada infrastruktur push, jaringan, dan ponsel yang terisi daya. Anggap ia sebagai lapisan yang mempersingkat jarak antara sebuah fakta datang dan seseorang mengetahuinya, bukan sebagai kontrol yang bisa Anda tunjukkan dalam audit.
Ia tidak mengikuti waktu lokal. Variabel waktu bawaan hanya UTC dan tidak mengikuti daylight saving. Kondisi yang membatasi jendela waktu perlu disesuaikan manual dua kali setahun.

FAQ

Apakah memakai Echobell membuat kami patuh CRA?

Tidak. CRA membebankan kewajiban pada produsen, dan tidak ada aplikasi notifikasi yang bisa melunasinya. Yang ditangani Echobell adalah satu mode kegagalan spesifik: peringatan dini 24 jam terlewat karena orang yang bisa melaporkannya baru tahu di hari kerja berikutnya. Itu mode kegagalan yang nyata dan umum, tetapi ia hanya satu bagian dari program kepatuhan yang jauh lebih besar.

Kapan sebenarnya hitungan 24 jam itu mulai?

Saat produsen mengetahui adanya kerentanan yang aktif dieksploitasi atau insiden parah tersebut. Regulasinya tidak mendefinisikan momen pastinya, dan "mengetahui" bergantung pada fakta serta seberapa cepat fakta itu bisa dipastikan (DLA Piper). Dalam praktiknya, ini mendorong triase yang cepat dan terdokumentasi: makin lebar jarak antara sinyal datang dan seseorang menilainya, makin sulit menjelaskannya di kemudian hari.

Kami perusahaan kecil. Apakah kami dikecualikan?

Tidak dari kewajiban melapor. Pasal 64 mengecualikan usaha mikro dan usaha kecil dari denda administratif khusus karena melewatkan tenggat 24 jam di Pasal 14(2)(a) atau 14(4)(a). Kewajiban melapornya tetap berlaku, notifikasi 72 jam dan laporan akhir tidak terpengaruh, dan definisi usaha mikro serta usaha kecil bukan hal yang boleh Anda asumsikan sendiri. Anggap itu keringanan yang sempit, bukan izin bebas.

Kotak masuk keamanan kami dipantau pada jam kerja. Apakah itu belum cukup?

Cukup hanya jika Anda siap kehilangan sampai dua pertiga jendela waktunya di akhir pekan biasa. Laporan yang datang pukul 18.00 hari Jumat menyisakan tenggat pukul 18.00 hari Sabtu. Pemantauan jam kerja adalah default yang baik untuk segala hal lain; hitungan 24 jam justru kasus yang tidak dicakupnya.

Bisakah tim kepatuhan, hukum, dan teknik mendapat peringatan yang sama?

Bisa, dan memang seharusnya. Bagikan satu saluran, maka setiap pelanggan diberi tahu pada pemicu yang sama, masing-masing memilih tingkat urgensinya sendiri. Insinyur yang memastikan adanya eksploitasi dan orang yang akan mengirimkan formulir perlu mulai pada menit yang sama, bukan bergiliran.

Apakah ini membantu untuk kewajiban Pasal 14(8) memberi tahu pengguna?

Secara tidak langsung. Pasal 14(8) mewajibkan pemberitahuan kepada pengguna terdampak tentang kerentanan atau insiden dan, bila perlu, langkah korektifnya. Itu komunikasi ke pelanggan, dan butuh kanal Anda sendiri. Echobell bisa membangunkan orang yang bertanggung jawab atas komunikasi itu bersamaan dengan orang yang bertanggung jawab atas pelaporannya, sehingga kedua alur kerja itu berjalan sejak awal bersamaan.

Kami sudah melapor di bawah NIS2 atau DORA. Apakah ini sama?

Tidak, meski bentuknya mirip. NIS2 dan DORA membebankan kewajiban pada entitas berdasarkan sektor dan tingkat kritikalitas; CRA membebankan kewajiban pada produsen berdasarkan produk yang mereka edarkan di pasar Uni Eropa. Satu organisasi bisa tunduk pada ketiganya, dengan hitungan waktu dan penerima laporan yang berbeda. Jika rezim-rezim itu juga berlaku untuk Anda, lihat peringatan pelaporan insiden DORA dan NIS2 — dan perhatikan bahwa lapisan peringatannya bisa dipakai bersama meski kewajibannya tidak.

Apakah panggilannya benar-benar menembus Jangan Ganggu?

Notifikasi panggilan dikirim sebagai peringatan bergaya panggilan, dan itulah yang membuatnya bisa menembus Mode Fokus di iOS. Ini bukan sihir: hasilnya tetap bergantung pada pengaturan sistem operasi, jaringan, dan ponsel yang terisi daya. Ujilah di perangkat yang sesungguhnya, dengan Mode Fokus benar-benar menyala, sebelum Anda mengandalkannya — dan aktifkan Retry Failed Call.

Apakah ini hanya untuk iOS?

Tidak. Echobell tersedia di iOS dan di Android lewat Google Play (rilis Android). Perilaku peringatan bergaya panggilan berbeda antarplatform, jadi ujilah di perangkat yang benar-benar akan dibawa penanggap.

Apa yang sebaiknya kami taruh di payload webhook?

Seminimal yang diperlukan untuk memutuskan apakah perlu bangun: produknya, jenis sinyalnya, satu baris konteks, dan sebuah externalLink ke tiket yang memuat detailnya. Echobell menyimpan isi dan riwayat notifikasi di perangkat serta hanya menyimpan akun, saluran, dan langganan di server (model privasi), tetapi kebiasaan yang benar untuk materi sensitif keamanan tetaplah mengirim penunjuk, bukan substansinya.