---
title: "สายโทรแจ้งเตือนจาก Uptime Kuma: ทำให้มือถือของคุณดังจริง ๆ"
description: "Uptime Kuma มีผู้ให้บริการแจ้งเตือนกว่า 90 ราย แต่ไม่มีรายไหนโทรเข้ามือถือคุณ นี่คือวิธีเพิ่มสายโทรแจ้งเตือนเมื่อระบบล่ม โดยใช้ webhook เพียงตัวเดียว"
date: 2026-08-28
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Uptime Kuma
  - การมอนิเตอร์แบบ self-hosted
  - แจ้งเตือนด้วยสายโทรเข้า
  - การแจ้งเตือนผ่าน webhook
  - มอนิเตอร์ uptime
  - on-call
---

# สายโทรแจ้งเตือนจาก Uptime Kuma: ทำให้มือถือของคุณดังจริง ๆ

Uptime Kuma รองรับผู้ให้บริการแจ้งเตือนมากกว่า 90 ราย แต่ไม่มีรายไหนทำให้มือถือของคุณดัง หากอยากได้สายโทรเมื่อมอนิเตอร์ตัวใดล่ม ให้ส่งการแจ้งเตือนแบบ **Webhook** ของ Uptime Kuma ไปยังช่อง Echobell ที่ตั้งเป็น **โทรเข้า** คู่มือนี้ครอบคลุมทั้ง custom body ที่ต้องใช้ วิธีแยกการแจ้งเตือนตอนล่มออกจากตอนกลับมาทำงาน และข้อผิดพลาดสองอย่างที่ทำให้การตั้งค่าพังแบบเงียบ ๆ

[Uptime Kuma](https://github.com/louislam/uptime-kuma) คือระบบมอนิเตอร์ uptime แบบ self-hosted ที่ได้รับความนิยมที่สุดในตอนนี้ ด้วยดาวบน GitHub ราว 90,000 ดวง และเวอร์ชัน 2.5.0 ที่ออกในเดือนสิงหาคม 2026 มันตรวจสอบได้ทั้งปลายทาง HTTP พอร์ต TCP เรกคอร์ด DNS คอนเทนเนอร์ Docker และอื่น ๆ อีกมาก และเก่งเรื่องการตรวจจับการล่มจริง ๆ

จุดที่มันทิ้งคุณไว้กลางทางคือช่วงสุดท้าย: การส่งการแจ้งเตือนไปถึงคนที่กำลังหลับอยู่

## ทำไม Uptime Kuma จึงโทรเข้ามือถือคุณเองไม่ได้

รายชื่อการแจ้งเตือนของ Uptime Kuma ยาวมาก ทั้ง Telegram, Discord, Slack, อีเมล, Gotify, ntfy และอีกหลายสิบราย แต่ทุกรายส่ง *ข้อความ* และข้อความก็ขึ้นอยู่กับสวิตช์ปิดเสียงของมือถือ โหมดห้ามรบกวน และโหมดโฟกัสของ iOS ตอนตีสามนั่นแปลว่าการแจ้งเตือนมาถึงแล้วก็ไม่มีอะไรเกิดขึ้น

ไม่มีผู้ให้บริการในตัวแบบ "โทรหามือถือฉัน" ตัวเลือกที่คนมักลงเอยด้วยคือ:

- **Twilio** — คุณสร้างระบบโทรด้วยเสียงต่อยอดจากมันได้ แต่ผู้ให้บริการ Twilio ใน Uptime Kuma ส่งเป็น SMS การจะโทรด้วยเสียงหมายถึงต้องเขียนบริการตัวกลาง ซื้อเบอร์ และจ่ายรายครั้ง
- **PagerDuty, Zenduty, Spike.sh, Splunk On-Call** — พวกนี้โทรได้จริง และเป็นแพลตฟอร์มจัดการเหตุการณ์แบบเต็มรูปแบบพร้อมราคาต่อผู้ใช้ที่สมน้ำสมเนื้อกัน เป็นคำตอบที่ถูกต้องถ้าคุณต้องการตารางเวรและนโยบายการยกระดับ แต่หนักเกินไปถ้าคุณแค่อยากให้โทรศัพท์ดัง
- **SMS gateway** — SMS ก็ยังมาถึงในรูปข้อความอยู่ดี และบน iOS ข้อความจะไม่ทะลุโหมดโฟกัส เว้นแต่ผู้ส่งจะอยู่ในรายชื่อที่อนุญาตไว้

[คำขอฟีเจอร์สำหรับการแจ้งเตือนแบบโทร VoIP](https://github.com/louislam/uptime-kuma/issues/3812) เปิดค้างอยู่ในรีโปของ Uptime Kuma มาสักพักแล้ว ระหว่างนี้ ผู้ให้บริการแบบ **Webhook** ทั่วไปคือทางออก เพราะมันโพสต์อะไรก็ได้ไปยัง URL ไหนก็ได้ ซึ่งก็เพียงพอแล้ว

## สิ่งที่คุณต้องมี

- อินสแตนซ์ Uptime Kuma ที่รันอยู่ (คู่มือนี้เขียนอิงเวอร์ชัน 2.x ส่วน custom body ของ webhook ใช้ได้กับ 1.23+ ด้วย)
- ติดตั้ง Echobell แล้ว ([App Store](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-uptime-kuma-phone-call-alerts-th&mt=8) / [Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid))
- เวลาห้านาที

อินสแตนซ์ Uptime Kuma ของคุณต้องต่อ HTTPS ขาออกไปยัง `hook.echobell.one` ได้ แต่**ไม่จำเป็น**ต้องเข้าถึงได้จากอินเทอร์เน็ต เพราะนี่เป็น webhook ขาออก ระบบมอนิเตอร์ที่รันบนเซิร์ฟเวอร์ที่บ้านหรือในเครือข่ายส่วนตัวจึงใช้งานได้สบาย

## ขั้นตอนที่ 1 — สร้างช่องที่โทรหาคุณ

ใน Echobell ให้สร้างช่องชื่ออะไรทำนอง `Production Down` แล้วตั้งประเภทการแจ้งเตือนของการติดตามเป็น **โทรเข้า** นี่คือการตั้งค่าที่สำคัญ เพราะการแจ้งเตือนแบบโทรเข้าจะมาถึงในรูปหน้าจอสายเรียกเข้า และดังทะลุโหมดโฟกัสกับห้ามรบกวนของ iOS ได้ ซึ่งการแจ้งเตือนแบบพุชทำไม่ได้

ตั้งเทมเพลตเป็น:

```
Title: 🔴 {{monitor}} is down
Body: {{message}}
Target: {{target}}
```

จากนั้นคัดลอก **Webhook URL** ของช่อง ซึ่งมีหน้าตาแบบนี้:

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

ให้ถือว่า URL นั้นเป็นความลับ เพราะใครที่ถือมันไว้ก็ทำให้มือถือคุณดังได้

## ขั้นตอนที่ 2 — เพิ่ม Echobell เป็นการแจ้งเตือนแบบ webhook

ใน Uptime Kuma ให้ไปที่ **Settings → Notifications → Setup Notification** แล้วกรอก:

| ช่อง | ค่า |
| --- | --- |
| Notification Type | `Webhook` |
| Friendly Name | `Echobell — Down` |
| Post URL | URL ของ webhook จาก Echobell ของคุณ |
| Request Body | `Custom Body` |

ปล่อย **Additional Headers** ว่างไว้

## ขั้นตอนที่ 3 — ส่ง payload ที่คุณกรองได้

นี่คือขั้นตอนที่คู่มือส่วนใหญ่ข้ามไป และเป็นขั้นตอนที่ชี้ขาดว่าคุณจะได้ระบบแจ้งเตือนหรือเครื่องผลิตสัญญาณรบกวน

วางข้อความนี้ลงใน **Custom Body**:

```json
{
  "monitor": "{{name}}",
  "target": "{{hostnameOrURL}}",
  "message": "{{ msg | strip_newlines }}",
  "up": "{{ heartbeatJSON['status'] }}"
}
```

Uptime Kuma เรนเดอร์ custom body ด้วย Liquid และเปิดให้ใช้ตัวแปรเหล่านี้:

| ตัวแปร | เก็บอะไรไว้ |
| --- | --- |
| `{{name}}` | ชื่อที่ตั้งไว้ของมอนิเตอร์ |
| `{{hostnameOrURL}}` | ชื่อโฮสต์หรือ URL ที่ถูกตรวจสอบ |
| `{{status}}` | `🔴 Down`, `✅ Up` หรือ `⚠️ Test` |
| `{{msg}}` | เหตุผลที่คนอ่านเข้าใจ เช่น `connect ECONNREFUSED 10.0.0.4:443` |
| `{{ monitorJSON['...'] }}` | อ็อบเจกต์มอนิเตอร์ทั้งก้อน |
| `{{ heartbeatJSON['...'] }}` | อ็อบเจกต์ heartbeat ทั้งก้อน |

มีสองรายละเอียดใน payload นั้นที่ตั้งใจใส่ไว้:

**`strip_newlines` บน `msg`** ข้อความของ Uptime Kuma มักมีการขึ้นบรรทัดใหม่ และการขึ้นบรรทัดใหม่ดิบ ๆ ในสตริง JSON ทำให้ JSON ไม่ถูกต้อง หากไม่ใส่ตัวกรองนี้ webhook ของคุณจะล้มเหลวเป็นครั้งคราว เฉพาะกับข้อผิดพลาดที่ข้อความบังเอิญตัดบรรทัดพอดี ถ้า Uptime Kuma ของคุณใหม่พอที่จะมีตัวกรอง `json` ของ Liquid การใช้ `"message": {{ msg | json }}` (สังเกตว่าไม่ต้องมีเครื่องหมายคำพูดครอบ) จะปลอดภัยยิ่งกว่า เพราะมัน escape เครื่องหมายคำพูดให้ด้วย

**ใช้ `heartbeatJSON['status']` แทน `{{status}}`** ตัวแปร `status` เรนเดอร์ออกมาเป็นข้อความอิโมจิ ซึ่งเอาไปเปรียบเทียบได้ลำบาก ส่วนสถานะของ heartbeat เป็นตัวเลขล้วน:

- `0` — ล่ม
- `1` — ทำงานปกติ
- `2` — รอตรวจสอบ
- `3` — อยู่ระหว่างบำรุงรักษา

การใส่เครื่องหมายคำพูดครอบ (`"up": "{{ ... }}"`) ก็สำคัญเช่นกัน และขั้นตอนที่ 5 จะอธิบายว่าทำไม

## ขั้นตอนที่ 4 — อย่าให้การแจ้งเตือนตอนกลับมาทำงานโทรหาคุณ

การแจ้งเตือนหนึ่งรายการของ Uptime Kuma จะทำงานทั้งตอนล่ม *และ* ตอนกลับมาทำงาน ถ้าปล่อยไว้แบบนั้น ระบบจะโทรหาคุณตอนบริการพัง แล้วโทรอีกครั้งตอนมันหายเอง สายที่สองนี่แหละที่สอนให้คนเริ่มเพิกเฉยต่อสายแรก

ให้แยกทั้งสองออกจากกันด้วย**เงื่อนไข**ของ Echobell ซึ่งถูกประเมินก่อนจะมีการส่งอะไรออกไป

**ที่ช่อง `Production Down`** (ประเภทการแจ้งเตือน **โทรเข้า**) ให้ตั้งเงื่อนไขเป็น:

```
up == "0"
```

**สร้างช่องที่สอง** ชื่อ `Production Recovered` ตั้งประเภทการแจ้งเตือนเป็น **ปกติ** แล้วให้เงื่อนไขว่า:

```
up == "1"
```

พร้อมเทมเพลต:

```
Title: ✅ {{monitor}} is back up
Body: {{message}}
```

จากนั้นเพิ่มการแจ้งเตือนแบบ webhook อันที่สองใน Uptime Kuma โดยใช้ custom body เดิม มอนิเตอร์ชุดเดิม แต่ชี้ไปยัง URL ของช่องสำหรับการกลับมาทำงาน การแจ้งเตือนทั้งสองรายการจะได้รับทุกอีเวนต์ แล้วแต่ละช่องก็จะทิ้งครึ่งที่ตัวเองไม่สนใจไป

ผลลัพธ์: ตอนล่มโทรเข้า ส่วนตอนกลับมาทำงานมาถึงเป็นพุชเงียบ ๆ ให้คุณอ่านตอนเช้า

## ขั้นตอนที่ 5 — จูนมอนิเตอร์ไม่ให้ตีปลาหน้าไซ

สายโทรที่กลายเป็นแค่เน็ตสะดุดสองวินาที แย่กว่าการไม่โทรเลย เพราะสายถัดไปก็จะถูกปัดทิ้งไปด้วย การตั้งค่าสามอย่างของ Uptime Kuma ทำงานส่วนใหญ่ตรงนี้ให้ และทั้งหมดอยู่ที่ตัวมอนิเตอร์เอง:

- **Retries** — ตั้งเป็น `2` หรือ `3` Uptime Kuma จะทำเครื่องหมายว่ามอนิเตอร์ล่มก็ต่อเมื่อล้มเหลวติดต่อกันครบจำนวนนี้ ซึ่งช่วยกรองแพ็กเก็ตที่หายไปครั้งเดียวออก
- **Heartbeat Retry Interval** — ความเร็วในการตรวจซ้ำระหว่างที่ล้มเหลว 20–30 วินาทีถือว่าสมดุลดี เมื่อรวมกับการลองใหม่ 3 ครั้ง คุณจะตรวจพบเหตุล่มจริงภายในราวหนึ่งนาที
- **Resend Notification if Down X times consecutively** — ตั้งเป็นราว `10` แล้ว Uptime Kuma จะโทรอีกครั้งหากบริการยังล่มอยู่หลังตรวจอีกสิบรอบ ถือเป็นนโยบายการยกระดับแบบหยาบ ๆ ที่ได้ผลจริง

ถ้าคุณอยากให้สายที่ยังไม่มีคนรับพยายามโทรซ้ำทันที แทนที่จะรอรอบการส่งซ้ำ ให้เปิด **Retry Failed Call** ในหน้าตั้งค่าแอปของ Echobell

## โทรเฉพาะนอกเวลาทำงาน

ระหว่างวันทำงาน คุณคงกำลังจ้องแดชบอร์ดอยู่แล้ว โทรศัพท์ที่ดังขึ้นจึงเป็นการขัดจังหวะที่ไม่จำเป็น ตัวแปรเวลาระบบของ Echobell (เป็น UTC ทั้งหมด) ทำให้ช่องเดียวมีพฤติกรรมต่างกันตามชั่วโมงได้:

```
up == "0" && (hour >= 17 || hour < 9)
```

เงื่อนไขนั้นจะโทรหาคุณเฉพาะนอกช่วง 09:00–17:00 UTC จากนั้นชี้ช่องที่สองแบบประเภทปกติไปที่เงื่อนไขตรงข้าม เพื่อรับพุชในเวลากลางวัน:

```
up == "0" && hour >= 9 && hour < 17
```

อย่าลืมเผื่อค่าชดเชยสำหรับโซนเวลาของคุณเอง เพราะตัวแปรเหล่านี้คำนวณเป็น UTC เสมอ อ่านฉบับเต็มได้ที่[การแจ้งเตือนตามช่วงเวลาด้วยเงื่อนไข UTC](/th/blog/time-window-notifications-using-utc-conditions)

## แชร์การแจ้งเตือนให้ทีมของคุณ

ช่องของ Echobell แชร์ให้เพื่อนร่วมทีมได้ผ่านลิงก์ติดตาม และผู้ติดตามแต่ละคนเลือกประเภทการแจ้งเตือนของตัวเองได้ มอนิเตอร์ตัวเดียวกันจึงโทรเข้ามือถือของวิศวกรที่เข้าเวร on-call ขณะที่มาถึงคนอื่นเป็นพุชธรรมดา โดยไม่ต้องจ่ายรายผู้ใช้ และไม่ต้องตั้งกฎการจัดเส้นทางแยกใน Uptime Kuma

เรื่องนี้ยังเข้ากันดีกับเหตุผลด้านความเป็นส่วนตัวที่ทำให้คุณเลือก self-host ตั้งแต่แรก: มอนิเตอร์ของคุณอยู่บนโครงสร้างพื้นฐานของคุณเอง ส่วน Echobell ก็เก็บเนื้อหาและประวัติการแจ้งเตือนไว้บนเครื่อง ไม่ได้เก็บบนเซิร์ฟเวอร์ของตัวเอง

## สิ่งที่การตั้งค่านี้ไม่ได้ให้คุณ

การพูดตรง ๆ เรื่องขอบเขตจะช่วยให้คุณไม่ต้องย้ายระบบแบบเจ็บตัวในภายหลัง Echobell เป็นชั้นส่งการแจ้งเตือน ไม่ใช่แพลตฟอร์มจัดการเหตุการณ์ มันไม่มี:

- ตารางเวร on-call หรือการส่งต่อเวรข้ามโซนเวลา
- ผังการยกระดับที่เรียกคนที่สองโดยอัตโนมัติ
- ไทม์ไลน์ของเหตุการณ์ การติดตามการตอบรับ หรือเครื่องมือทำ postmortem

ถ้าทีมของคุณต้องการสิ่งเหล่านี้ คุณต้องใช้ PagerDuty, Grafana Cloud IRM หรือระบบทำนองนั้น สิ่งที่การตั้งค่านี้ครอบคลุมคือช่องว่างเฉพาะจุดที่ Uptime Kuma ทิ้งไว้ นั่นคือการเปลี่ยนเหตุล่มที่ตรวจพบให้เป็นโทรศัพท์ที่ดังจริง ๆ สำหรับคนทำงานคนเดียว ทีมเล็ก ๆ และ homelab นั่นมักคือความต้องการทั้งหมดแล้ว

## การแก้ปัญหา

**กดปุ่ม Test แล้วไม่มีอะไรเกิดขึ้น** เป็นเรื่องปกติเมื่อใช้ payload ข้างต้น และมันทำให้ทุกคนงงในครั้งแรก เมื่อคุณกด Test นั้น Uptime Kuma ไม่มี heartbeat ให้เรนเดอร์ `{{ heartbeatJSON['status'] }}` จึงกลายเป็นสตริงว่าง และไม่มีเงื่อนไขไหนตรงเลย หากต้องการทดสอบให้ถูกวิธี ให้สร้างมอนิเตอร์ TCP ทิ้ง ๆ ที่ชี้ไปยังพอร์ตที่ไม่มีอะไรฟังอยู่ (`127.0.0.1:9`) แล้วปล่อยให้มันล้มเหลว

**webhook ล้มเหลวเป็นครั้งคราว** เกือบทุกครั้งเป็นปัญหาการขึ้นบรรทัดใหม่ ให้ตรวจสอบว่า `msg` ผ่าน `strip_newlines` แล้ว มันจะพังเฉพาะกับข้อความข้อผิดพลาดที่บังเอิญมีการขึ้นบรรทัดใหม่ จึงดูเหมือนเกิดขึ้นแบบสุ่ม

**Echobell ตอบ `success: false` พร้อมสถานะ HTTP 200** แปลว่าโทเคนของช่องผิดหรือช่องถูกลบไปแล้ว Echobell ตอบ `200` ให้กับโทเคนที่ไม่รู้จักแต่มีความยาวถูกต้อง ดังนั้นให้ดูที่ JSON ใน body ไม่ใช่ที่สถานะโค้ด

**HTTP 405** ช่องเปิดโหมด **POST Only** ไว้ แล้วมีอะไรบางอย่างส่ง GET มา Uptime Kuma ส่งแบบ POST อยู่แล้ว กรณีนี้จึงมักแปลว่าคุณเอา URL ไปทดสอบในเบราว์เซอร์

**ไม่มีเสียงเรียกเข้า แต่การแจ้งเตือนมาถึง** แปลว่าประเภทการแจ้งเตือนของการติดตามเป็นแบบปกติหรือสำคัญตามเวลา ไม่ใช่โทรเข้า ประเภทการแจ้งเตือนเลือกได้รายผู้ติดตาม จึงต้องไปตรวจที่เครื่องที่ไม่ดัง

## คำถามที่พบบ่อย

### Uptime Kuma โทรศัพท์ได้เองเลยไหม

ไม่ได้ Uptime Kuma มีผู้ให้บริการแจ้งเตือนกว่า 90 ราย แต่ทุกรายส่งเป็นข้อความ การโทรศัพท์ต้องส่ง webhook ไปยังบริการที่โทรได้ เช่น Echobell หรือใช้แพลตฟอร์มจัดการเหตุการณ์แบบเสียเงิน

### ใช้กับ Uptime Kuma แบบ self-hosted ที่อยู่หลังไฟร์วอลล์ได้ไหม

ได้ webhook เป็นคำขอ HTTPS ขาออกจากอินสแตนซ์ Uptime Kuma ของคุณ จึงต้องการแค่เข้าถึง `hook.echobell.one` ได้เท่านั้น อินสแตนซ์ของคุณไม่จำเป็นต้องมีที่อยู่สาธารณะ

### สายโทรจะทะลุโหมดห้ามรบกวนได้ไหม

ได้ ประเภทการแจ้งเตือนแบบโทรเข้าของ Echobell แสดงผลเป็นสายเรียกเข้า ซึ่งดังทะลุโหมดโฟกัสและห้ามรบกวนของ iOS ดูรายละเอียดและการตั้งค่าที่เกี่ยวข้องได้ที่[การทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)

### จะเลิกรับสายตอนบริการกลับมาทำงานได้อย่างไร

ให้ใช้สองช่องพร้อมเงื่อนไข คือ `up == "0"` สำหรับช่องแบบโทรเข้า และ `up == "1"` สำหรับช่องแจ้งการกลับมาทำงานที่ใช้ความสำคัญปกติ แล้วชี้การแจ้งเตือนแบบ webhook ไปที่แต่ละช่อง ขั้นตอนที่ 4 ข้างบนอธิบายไว้แล้ว

### ให้หลายคนได้รับสายจากมอนิเตอร์ตัวเดียวกันได้ไหม

ได้ แชร์ช่องให้เพื่อนร่วมทีม แล้วผู้ติดตามแต่ละคนก็เลือกประเภทการแจ้งเตือนของตัวเอง ทุกคนที่ติดตามช่องแบบโทรเข้าจะได้รับสาย

## สรุป

การตั้งค่าทั้งหมดมีแค่ webhook หนึ่งตัว custom body หนึ่งชุด และเงื่อนไขสองข้อ มันไม่แตะต้องมอนิเตอร์ ตรรกะการลองใหม่ และหน้าสถานะของ Uptime Kuma ที่คุณมีอยู่เลย แต่ปิดช่องว่างระหว่าง "ระบบมอนิเตอร์สังเกตเห็น" กับ "คนสังเกตเห็น" ได้

[ดาวน์โหลด Echobell สำหรับ iPhone](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-uptime-kuma-phone-call-alerts-th&mt=8) หรือ[รับได้ที่ Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) แล้วลองต่อกับมอนิเตอร์ที่ไม่สำคัญสักตัวก่อน แล้วจงใจทำให้มันล้มเหลว จงเชื่อมั่นในเส้นทางนี้ก่อนที่จะพึ่งพามันจริง ๆ

---

## เนื้อหาที่เกี่ยวข้อง

- [เอกสารการเชื่อมต่อ Uptime Kuma](/th/docs/developer/uptime-kuma)
- [ข้อมูลอ้างอิงเงื่อนไขของช่อง](/th/docs/conditions)
- [การแจ้งเตือนจาก Upptime ด้วย Echobell](/th/blog/upptime-alerts-with-echobell)
- [สายโทรแจ้งเตือนเมื่อ API ของคุณล่ม](/th/blog/phone-call-alerts-api-downtime)
- [คู่มือแก้อาการล้าจากการแจ้งเตือนสำหรับนักพัฒนา](/th/blog/fix-alert-fatigue-developer-guide)