---
title: "Peringatan Panggilan Telepon Prometheus Alertmanager: Bangun Hanya untuk yang Kritis"
description: "Alertmanager tidak punya receiver suara. Arahkan peringatan Prometheus ke panggilan telepon hanya untuk severity kritis: konfigurasi webhook, kondisi, dan jebakan Watchdog."
date: 2026-09-04
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Prometheus
  - Alertmanager
  - peringatan panggilan telepon
  - notifikasi webhook
  - Kubernetes
  - on-call
---

# Peringatan Panggilan Telepon Prometheus Alertmanager: Bangun Hanya untuk yang Kritis

Alertmanager tidak punya receiver suara. Untuk mendapat panggilan telepon saat sebuah peringatan Prometheus terpicu, tambahkan receiver `webhook_configs` yang mengarah ke saluran Echobell dengan jenis langganan **Panggilan**. Panduan ini membahas YAML persisnya, kondisi yang mencegah peringatan yang sudah pulih ikut menelepon Anda, perutean berdasarkan severity, dan peringatan Watchdog yang kalau dibiarkan akan membuat ponsel Anda berdering tiap empat jam selamanya.

Prometheus adalah tumpukan metrik bawaan bagi sebagian besar infrastruktur yang dibangun dalam satu dekade terakhir, dan [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) memang benar-benar baik di bagian yang sulit: mendeduplikasi peringatan, mengelompokkannya, membisukannya saat pemeliharaan, dan menekan kebisingan hilir ketika sebuah dependensi hulu gagal.

Yang tidak akan ia lakukan adalah membangunkan siapa pun.

## Mengapa Alertmanager tidak bisa membuat ponsel Anda berdering sendiri

Alertmanager menyediakan receiver untuk email, Slack, PagerDuty, OpsGenie, Discord, Telegram, Pushover, Webex, MS Teams, dan belasan lainnya. Semuanya mengirimkan sebuah *pesan*, dan pesan tunduk pada sakelar dering, Do Not Disturb, serta Mode Fokus iOS. Pukul 03.00, itu berarti peringatannya datang dan tidak terjadi apa-apa.

Tidak ada `voice_configs`. Pilihan yang biasanya diambil orang adalah:

- **PagerDuty / OpsGenie / Splunk On-Call** — ini memang bisa menelepon, dan semuanya platform manajemen insiden lengkap dengan harga per kursi yang setimpal. Jawaban yang tepat jika Anda butuh rotasi dan pohon eskalasi; berlebihan jika yang Anda butuhkan hanyalah ponsel yang berdering. (OpsGenie khususnya sedang [dihentikan](/id/blog/opsgenie-end-of-life-alternatives), dan itulah sebabnya begitu banyak tim mengevaluasi ulang lapisan ini sekarang.)
- **Jembatan SMS** seperti [Sachet](https://github.com/messagebird/sachet) — Anda menjalankan satu layanan lagi, membayar gateway per pesan, dan SMS pun tetap mendarat sebagai pesan. Di iOS, sebuah SMS tidak menembus Mode Fokus kecuali pengirimnya ada di daftar izin Anda.
- **Perekat berbasis Twilio** — tulis receiver webhook kecil, beli sebuah nomor, bayar per panggilan, dan kini Anda memiliki sepotong infrastruktur produksi yang tugas satu-satunya adalah membuat ponsel berdering.

**Receiver webhook** generik adalah pintu keluarnya. Ia mengirim payload JSON yang terdokumentasi ke URL mana pun, dan itu sudah cukup.

## Yang Anda butuhkan

- Penyiapan Prometheus + Alertmanager yang sudah berjalan, dan akses untuk mengedit `alertmanager.yml`
- Echobell terpasang ([App Store](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-alertmanager-phone-call-alerts-id&mt=8) / [Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid))
- Sepuluh menit

Panduan ini ditulis berdasarkan Alertmanager 0.31. Payload webhook sudah berada di `version: "4"` selama bertahun-tahun, jadi rilis 0.2x berperilaku sama persis.

Alertmanager Anda butuh HTTPS keluar ke `hook.echobell.one`. Ia **tidak** perlu bisa dijangkau dari internet, jadi Alertmanager di dalam sebuah cluster, VPC, atau homelab pun berjalan baik.

## Langkah 1 — Buat saluran yang menelepon Anda

Di Echobell, buat saluran bernama semisal `Prometheus Critical`. Setel jenis notifikasi langganannya ke **Panggilan**. Inilah pengaturan yang menentukan: peringatan bertipe Panggilan datang sebagai layar panggilan masuk dan berdering menembus Mode Fokus iOS dan Do Not Disturb, hal yang tidak bisa dilakukan notifikasi push.

Setel templatnya agar membaca payload Alertmanager secara langsung:

```
Title: 🔴 {{commonLabels.alertname}} on {{commonLabels.instance}}
Body: {{commonAnnotations.summary}}
{{commonAnnotations.description}}
```

Dan, di Pengaturan Lanjutan, sebuah **Templat Tautan** agar catatan notifikasinya langsung melompat ke grafik:

```
{{alerts[0].generatorURL}}
```

Lalu salin **URL Webhook** saluran tersebut:

```
https://hook.echobell.one/t/<channel-token>
```

Perlakukan URL itu sebagai rahasia — siapa pun yang memegangnya bisa membuat ponsel Anda berdering.

## Langkah 2 — Tambahkan receiver webhook

Di `alertmanager.yml`:

```yaml
route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-critical

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false
```

Muat ulang dengan `curl -X POST http://localhost:9093/-/reload` atau `SIGHUP`.

Perhatikan `send_resolved: false`. **Nilai bawaan untuk receiver webhook adalah `true`**, berbeda dari kebanyakan receiver Alertmanager lain, jadi menghilangkannya berarti ponsel Anda berdering saat layanan rusak *dan* berdering lagi saat ia pulih sendiri. Panggilan kedua itulah yang melatih orang mengabaikan yang pertama. Langkah 4 menunjukkan cara mendapatkan kembali pemberitahuan pemulihan tanpa deringan.

## Langkah 3 — Pahami apa yang sebenarnya datang

Alertmanager mengelompokkan peringatan, lalu mengirim satu payload POST per kelompok:

```json
{
  "version": "4",
  "groupKey": "{}:{alertname=\"HighErrorRate\"}",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "echobell-critical",
  "groupLabels": { "alertname": "HighErrorRate" },
  "commonLabels": { "alertname": "HighErrorRate", "severity": "critical" },
  "commonAnnotations": { "summary": "Error rate above 5% for 10m" },
  "externalURL": "http://alertmanager.internal:9093",
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "HighErrorRate", "instance": "api-7d9f:8080" },
      "annotations": { "summary": "Error rate above 5% for 10m" },
      "startsAt": "2026-09-04T02:41:07.351Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "http://prometheus:9090/graph?g0.expr=...",
      "fingerprint": "a1b2c3d4e5f60718"
    }
  ]
}
```

Echobell membaca body JSON apa adanya, jadi setiap bidang di atas tersedia di templat dan kondisi. Akses bersarang bisa dengan salah satu sintaks — `{{commonLabels.severity}}` atau `{{alerts[0].labels["instance"]}}`.

Dua sifat payload ini menentukan semua hal di bawah:

**`status` di tingkat teratas bernilai `firing` jika *ada* peringatan mana pun dalam kelompok itu yang sedang firing.** Ia baru menjadi `resolved` setelah semua peringatan dalam kelompok tersebut pulih. Itu menjadikannya patokan yang bersih untuk menyaring.

**`commonLabels` hanya memuat label yang sama-sama dimiliki setiap peringatan dalam kelompok.** Inilah kejutan yang paling sering terjadi. Jika `group_by` cukup luas sehingga satu webhook membawa `HighErrorRate` dari tiga instance berbeda, maka `commonLabels.instance` tidak ada dan `{{commonLabels.instance}}` dirender sebagai string kosong. Cara menanganinya dibahas lebih lanjut di bawah.

## Langkah 4 — Kirim pemulihan sebagai push yang tenang

Anda tetap ingin tahu ketika sesuatu pulih — Anda hanya tidak ingin ditelepon soal itu. Tambahkan saluran Echobell kedua bernama `Prometheus Recovered`, setel jenis notifikasinya ke **Normal**, lalu beri templat berikut:

```
Title: ✅ {{commonLabels.alertname}} resolved
Body: {{commonAnnotations.summary}}
```

dan, di Pengaturan Lanjutan, **kondisi** ini:

```
status == "resolved"
```

Kondisi adalah ekspresi yang dievaluasi sebelum apa pun dikirim. Jika ekspresinya bernilai salah, Echobell menerima permintaannya dan tidak mengirim apa-apa.

Lalu arahkan receiver yang sama ke kedua saluran — satu receiver bisa memuat beberapa `webhook_configs`:

```yaml
receivers:
  - name: echobell-critical
    webhook_configs:
      # Membuat ponsel berdering. Hanya saat firing.
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false
      # Push yang tenang. Kondisi saluran membuang paruh firing-nya.
      - url: "https://hook.echobell.one/t/<recovery-channel-token>"
        send_resolved: true
```

Saluran pemulihan menerima payload firing maupun resolved lalu membuang yang firing. Hasilnya: gangguan membuat ponsel berdering, pemulihan datang sebagai push yang Anda baca pagi hari.

## Langkah 5 — Rutekan berdasarkan severity, bukan berdasarkan segalanya

Rute tangkap-semua yang mengirim setiap peringatan ke saluran panggilan adalah mesin penghasil panggilan telepon yang diabaikan. Pisahkan berdasarkan severity di Alertmanager, tempat pohon perutean memang seharusnya berada:

```yaml
route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-warning

  routes:
    # Watchdog tidak pernah sampai ke manusia. Lihat Langkah 6.
    - matchers:
        - alertname = "Watchdog"
      receiver: "null"

    - matchers:
        - severity = "critical"
      receiver: echobell-critical
      group_wait: 10s
      repeat_interval: 1h

receivers:
  - name: "null"

  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false

  - name: echobell-warning
    webhook_configs:
      - url: "https://hook.echobell.one/t/<normal-channel-token>"
        send_resolved: true
```

Rute dievaluasi dari atas ke bawah dan **kecocokan pertama yang menang** — `continue` bernilai bawaan `false`. Jadi urutannya penting: rute `Watchdog` harus berada di atas apa pun yang jika tidak akan menelannya.

Jika Anda lebih suka memakai satu saluran dan menyaring di sisi Echobell, kondisi setaranya adalah:

```
status == "firing" && commonLabels.severity == "critical"
```

Melakukannya di Alertmanager biasanya lebih baik, karena `severity` di sana juga menentukan `group_wait` dan `repeat_interval`. Melakukannya di Echobell lebih baik ketika Anda tidak bisa membuat perubahan konfigurasi disetujui hari ini.

## Langkah 6 — Jebakan Watchdog

Jika Anda menjalankan [kube-prometheus-stack](https://github.com/prometheus-operator/kube-prometheus), Anda punya sebuah peringatan bernama `Watchdog` yang ekspresinya `vector(1)`. Ia memang *dirancang* untuk terus firing selamanya — keberadaannya agar sistem eksternal bisa menyadari saat Prometheus sendiri berhenti. Konfigurasi bawaan mengarahkannya ke receiver `null`.

Arahkan rute tangkap-semua ke saluran panggilan tanpa mengecualikannya, dan Watchdog akan menelepon ponsel Anda setiap `repeat_interval`, selamanya, mulai saat itu juga. Inilah penyebab nomor satu orang menyimpulkan bahwa peringatan lewat telepon "tidak berhasil".

Pertahankan rute `null` dari Langkah 5. Lalu, bila mau, lakukan hal yang berguna dengannya: ubah Watchdog menjadi dead man's switch yang sungguhan.

```yaml
    - matchers:
        - alertname = "Watchdog"
      receiver: deadmansswitch
      group_wait: 0s
      group_interval: 1m
      repeat_interval: 50s

receivers:
  - name: deadmansswitch
    webhook_configs:
      - url: "https://hc-ping.com/<your-check-uuid>"
        send_resolved: false
```

Echobell tidak bisa menjadi dead man's switch itu sendiri — ia memberi peringatan ketika sebuah permintaan *datang*, bukan ketika permintaan berhenti datang. Jadi kirim ping Watchdog ke layanan yang memang dibangun untuk mendeteksi kesunyian ([Healthchecks.io](https://healthchecks.io), Cronitor, Dead Man's Snitch), lalu arahkan webhook "check went down" dari *layanan itu* ke saluran panggilan Echobell Anda. Kini sebuah panggilan telepon berarti "sistem pemantauannya sendiri mati", yaitu satu peringatan yang paling ingin Anda dengar dan paling jarang dikonfigurasi orang.

## Menyetel agar ia tidak "mengaku ada serigala"

Tiga pengaturan Alertmanager melakukan sebagian besar pekerjaannya, ditambah satu di Prometheus:

| Pengaturan | Di mana | Fungsinya |
| --- | --- | --- |
| `for:` | Aturan peringatan | Berapa lama kondisinya harus bertahan sebelum ia firing sama sekali. Garis pertahanan pertama Anda terhadap gangguan dua detik. |
| `group_wait` | Rute | Berapa lama menunggu peringatan lain sebelum notifikasi pertama. Bawaannya 30s; turunkan ke `10s` untuk yang kritis. |
| `group_interval` | Rute | Jeda minimum sebelum notifikasi tentang peringatan *baru* dalam kelompok yang sudah ada. Bawaannya 5m. |
| `repeat_interval` | Rute | Seberapa sering peringatan yang belum pulih diberitahukan ulang. **Bawaannya 4h** — jadi gangguan tengah malam menelepon Anda pukul 03.00 dan lagi pukul 07.00. |

`repeat_interval` adalah yang layak dipikirkan. Empat jam terlalu lama untuk membiarkan sesuatu rusak; dua puluh menit adalah mesin yang membuat Anda menonaktifkan salurannya. Satu jam untuk yang kritis adalah titik awal yang masuk akal.

Jika Anda ingin panggilan yang tak terjawab langsung dicoba ulang alih-alih menunggu `repeat_interval` berikutnya, aktifkan **Coba Ulang Panggilan Gagal** di pengaturan aplikasi Echobell.

## Hanya berdering di luar jam kerja

Saat jam kerja, Anda mungkin sudah menatap dasbor. Variabel waktu sistem Echobell (semuanya UTC) memungkinkan sebuah saluran berperilaku berbeda menurut jam, tanpa perlu rute Alertmanager kedua:

```
status == "firing" && (hour >= 17 || hour < 9)
```

Itu menelepon Anda hanya di luar pukul 09.00–17.00 UTC. Arahkan saluran kedua bertipe Normal ke kebalikannya untuk push di siang hari:

```
status == "firing" && hour >= 9 && hour < 17
```

Tambahkan `dayOfWeek >= 1 && dayOfWeek <= 5` untuk memperlakukan akhir pekan sebagai di luar jam kerja juga. Ingat bahwa semuanya selalu dihitung dalam UTC — sesuaikan dengan zona waktu Anda sendiri. Pembahasan lebih lengkap ada di [notifikasi jendela waktu memakai kondisi UTC](/id/blog/time-window-notifications-using-utc-conditions).

## Menangani masalah `commonLabels` yang kosong

Ketika sebuah kelompok memuat peringatan dari beberapa instance, `commonLabels.instance` menghilang dan judul notifikasi Anda berbunyi `🔴 HighErrorRate on `.

Tiga jalan keluar, berurutan sesuai preferensi:

1. **Masukkan labelnya ke `group_by`.** Jika `group_by` menyertakan `instance`, maka setiap peringatan dalam satu kelompok memilikinya dan `commonLabels.instance` selalu ada. Biayanya: notifikasi jadi lebih banyak — satu per instance alih-alih satu per nama peringatan.
2. **Baca peringatan pertama saja.** `{{alerts[0].labels.instance}}` selalu terisi. Ia hanya salah satu dari kemungkinan banyak, jadi padukan dengan jumlahnya: `{{alerts[0].labels.instance}} (+{{alerts.length}} alerts)`.
3. **Rancang labelnya agar tetap terbaca saat kosong.** Echobell tidak punya operator nilai bawaan — `{{a || "unknown"}}` merender teks harfiah `true`, bukan nilai cadangan — jadi tulis `Instance: {{commonLabels.instance}}` di barisnya sendiri, di mana nilai kosong jelas terlihat kosong alih-alih menjadi kalimat yang rusak.

## Menjaga payload tetap kecil

Sebuah kelompok yang mencakup seratus pod menghasilkan body JSON yang besar, dan Echobell menolak body pemicu di atas 1 MiB dengan HTTP 413. Batasi di Alertmanager:

```yaml
      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false
        max_alerts: 20
```

Alertmanager lalu mengirim paling banyak dua puluh peringatan dan menyetel `truncatedAlerts` ke jumlah yang ia buang, yang bisa Anda tampilkan di isi pesan:

```
Body: {{commonAnnotations.summary}}
Alerts: {{alerts.length}} (+{{truncatedAlerts}} truncated)
```

## Membagikan peringatannya ke tim Anda

Saluran Echobell bisa dibagikan lewat tautan langganan, dan setiap pelanggan memilih jenis notifikasinya sendiri. Karena itu, rute yang sama bisa menelepon insinyur on-call sekaligus mendarat sebagai push biasa bagi semua orang lain — tanpa harga per kursi, dan tanpa aturan perutean tambahan di Alertmanager.

Ini juga selaras dengan alasan banyak tim meng-host Prometheus sendiri sejak awal: metrik dan aturan peringatan Anda tetap berada di infrastruktur Anda, dan Echobell menyimpan isi serta riwayat notifikasi di perangkat, bukan di servernya.

## Yang tidak diberikan penyiapan ini

Berterus terang soal batasannya menyelamatkan Anda dari migrasi yang buruk kelak. Echobell adalah lapisan pengiriman, bukan platform manajemen insiden. Ia tidak punya:

- Jadwal rotasi on-call atau serah terima follow-the-sun
- Pohon eskalasi yang memanggil orang kedua ketika yang pertama tidak menjawab
- Linimasa insiden, pelacakan pengakuan, atau perkakas postmortem

Jika tim Anda membutuhkannya, Anda butuh PagerDuty, Grafana Cloud IRM, atau sejenisnya. Yang dicakup panduan ini adalah celah spesifik yang ditinggalkan Alertmanager: mengubah peringatan yang firing menjadi ponsel yang benar-benar berdering. Bagi operator perorangan, tim kecil, dan homelab, biasanya itulah seluruh kebutuhannya.

## Pemecahan masalah

**Tidak ada apa pun yang datang.** Periksa dulu log Alertmanager sendiri (`level=error component=dispatcher`), lalu pastikan rutenya memang mengarah ke receiver Anda — `amtool config routes test severity=critical alertname=HighErrorRate` memberi tahu receiver mana yang akan menerima sebuah peringatan tanpa perlu menunggu ada yang firing.

**Echobell mengembalikan HTTP 404.** Token salurannya salah atau salurannya sudah dihapus. Token yang tidak dikenal menghasilkan 404, bukan keberhasilan senyap.

**Echobell mengembalikan 200 dengan `"notificationTriggered": false`.** Kondisi Anda bernilai salah. Body responsnya juga memuat `"conditionsMet": false`, yang merupakan cara tercepat membedakan "kondisi saya salah" dari "webhook saya tidak pernah sampai". Periksa `status == "firing"` terhadap apa yang benar-benar dikirim Alertmanager — status di tingkat teratas, bukan `alerts[0].status`.

**HTTP 413.** Payload melampaui 1 MiB. Setel `max_alerts` seperti di atas.

**HTTP 405.** Saluran mengaktifkan **POST Only** dan ada yang mengirim GET. Alertmanager memakai POST, jadi ini biasanya berarti Anda menguji URL-nya di peramban.

**Judulnya punya celah kosong.** `commonLabels` tidak memuat label itu untuk kelompok ini. Lihat bagian di atas.

**Tidak ada dering, tetapi notifikasinya datang.** Jenis notifikasi langganannya Normal atau Peka Waktu, bukan Panggilan. Jenis notifikasi dipilih per pelanggan, jadi periksa di perangkat yang tidak berdering.

**Menguji tanpa merusak produksi.** Tambahkan aturan dengan `expr: vector(1)`, `alertname` yang khas, dan `severity: critical`, biarkan firing sekali, lalu hapus. Atau picu satu secara manual:

```bash
curl -X POST http://localhost:9093/api/v2/alerts -H 'Content-Type: application/json' -d '[
  {"labels":{"alertname":"EchobellTest","severity":"critical"},
   "annotations":{"summary":"Testing the phone call path"}}
]'
```

## Pertanyaan yang sering diajukan

### Bisakah Prometheus Alertmanager melakukan panggilan telepon secara bawaan?

Tidak. Alertmanager punya receiver untuk email, Slack, PagerDuty, OpsGenie, dan banyak lainnya, tetapi tidak ada receiver suara atau SMS. Panggilan telepon menuntut Anda mengarahkan receiver webhook generik ke layanan yang bisa melakukannya, seperti Echobell, atau membayar platform manajemen insiden.

### Apakah panggilannya menembus Do Not Disturb?

Ya. Jenis notifikasi Panggilan di Echobell tampil sebagai panggilan masuk, yang berdering menembus Mode Fokus iOS dan Do Not Disturb. Lihat [menembus Mode Fokus iOS untuk peringatan kritis](/id/blog/how-to-bypass-ios-focus-mode-for-critical-alerts) untuk detail dan pengaturan yang terlibat.

### Apakah ini berfungsi dengan Alertmanager di balik firewall atau di dalam Kubernetes?

Ya. Webhook-nya adalah permintaan HTTPS keluar dari Alertmanager, jadi ia hanya perlu menjangkau `hook.echobell.one`. Alertmanager Anda tidak perlu alamat publik atau ingress.

### Bagaimana cara berhenti ditelepon saat sebuah peringatan pulih?

Setel `send_resolved: false` pada konfigurasi webhook yang mengarah ke saluran panggilan Anda. Receiver webhook bernilai bawaan `true`, berbeda dari kebanyakan receiver Alertmanager lain, jadi ini bersifat opt-out, bukan opt-in. Untuk tetap menerima kabar pemulihan secara tenang, tambahkan saluran kedua dengan kondisi `status == "resolved"`.

### Mengapa ponsel saya berdering tiap empat jam untuk peringatan yang sama?

Itu `repeat_interval`, yang bawaannya `4h`. Alertmanager memberitahukan ulang peringatan yang masih firing pada irama itu. Setel per rute — `1h` untuk yang kritis adalah pilihan yang lazim. Jika panggilannya mulai muncul segera setelah Anda menambahkan rute tangkap-semua, biang keroknya lebih mungkin peringatan `Watchdog` yang selalu firing; lihat Langkah 6.

### Bisakah beberapa orang ditelepon untuk peringatan yang sama?

Bisa. Bagikan salurannya ke rekan tim dan setiap pelanggan memilih jenis notifikasinya sendiri. Semua yang berlangganan saluran panggilan akan ditelepon, tanpa biaya per kursi.

### Sebaiknya saya menyaring severity di Alertmanager atau di kondisi Echobell?

Utamakan Alertmanager: perutean di sana juga memungkinkan Anda menyetel `group_wait` dan `repeat_interval` per severity, dan pohon perutean tetap tersimpan di kontrol versi bersama konfigurasi lain Anda. Pakai kondisi Echobell ketika Anda tidak bisa mengubah konfigurasi Alertmanager, atau untuk penyaringan yang tidak dikenal Alertmanager — seperti waktu dalam sehari.

## Penutup

Penyiapannya terdiri dari satu receiver, satu `send_resolved: false`, dan pohon perutean yang menjauhkan segala hal selain `severity: critical` dari saluran panggilan. Ia membiarkan aturan peringatan, pengelompokan, pembisuan, dan penekanan Anda persis seperti sedia kala, sekaligus menutup celah antara "Prometheus menyadarinya" dan "seorang manusia menyadarinya".

[Unduh Echobell untuk iPhone](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-alertmanager-phone-call-alerts-id&mt=8) atau [dapatkan di Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid), lalu picu peringatan `EchobellTest` di atas sebelum Anda mengandalkan jalur ini untuk hal yang sungguhan.

---

## Terkait

- [Dokumentasi integrasi Prometheus](/id/docs/developer/prometheus)
- [Referensi kondisi saluran](/id/docs/conditions)
- [Notifikasi panggilan Grafana](/id/blog/grafana-call-notification)
- [Peringatan panggilan telepon Uptime Kuma](/id/blog/uptime-kuma-phone-call-alerts)
- [Panduan developer untuk mengatasi kelelahan peringatan](/id/blog/fix-alert-fatigue-developer-guide)