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

สารบัญ

• ทำไม Uptime Kuma จึงโทรเข้ามือถือคุณเองไม่ได้
• สิ่งที่คุณต้องมี
• ขั้นตอนที่ 1 — สร้างช่องที่โทรหาคุณ
• ขั้นตอนที่ 2 — เพิ่ม Echobell เป็นการแจ้งเตือนแบบ webhook
• ขั้นตอนที่ 3 — ส่ง payload ที่คุณกรองได้
• ขั้นตอนที่ 4 — อย่าให้การแจ้งเตือนตอนกลับมาทำงานโทรหาคุณ
• ขั้นตอนที่ 5 — จูนมอนิเตอร์ไม่ให้ตีปลาหน้าไซ
• โทรเฉพาะนอกเวลาทำงาน
• แชร์การแจ้งเตือนให้ทีมของคุณ
• สิ่งที่การตั้งค่านี้ไม่ได้ให้คุณ
• การแก้ปัญหา
• คำถามที่พบบ่อย
• Uptime Kuma โทรศัพท์ได้เองเลยไหม
• ใช้กับ Uptime Kuma แบบ self-hosted ที่อยู่หลังไฟร์วอลล์ได้ไหม
• สายโทรจะทะลุโหมดห้ามรบกวนได้ไหม
• จะเลิกรับสายตอนบริการกลับมาทำงานได้อย่างไร
• ให้หลายคนได้รับสายจากมอนิเตอร์ตัวเดียวกันได้ไหม
• สรุป
• เนื้อหาที่เกี่ยวข้อง

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

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 เปิดค้างอยู่ในรีโปของ Uptime Kuma มาสักพักแล้ว ระหว่างนี้ ผู้ให้บริการแบบ Webhook ทั่วไปคือทางออก เพราะมันโพสต์อะไรก็ได้ไปยัง URL ไหนก็ได้ ซึ่งก็เพียงพอแล้ว

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

• อินสแตนซ์ Uptime Kuma ที่รันอยู่ (คู่มือนี้เขียนอิงเวอร์ชัน 2.x ส่วน custom body ของ webhook ใช้ได้กับ 1.23+ ด้วย)
• ติดตั้ง Echobell แล้ว (App Store / Google Play)
• เวลาห้านาที

อินสแตนซ์ 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 แล้วกรอก:

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

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

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

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

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

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

มีสองรายละเอียดใน 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

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

ช่องของ 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 สำหรับการแจ้งเตือนวิกฤต

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

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

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

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

สรุป

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

ดาวน์โหลด Echobell สำหรับ iPhone หรือรับได้ที่ Google Play แล้วลองต่อกับมอนิเตอร์ที่ไม่สำคัญสักตัวก่อน แล้วจงใจทำให้มันล้มเหลว จงเชื่อมั่นในเส้นทางนี้ก่อนที่จะพึ่งพามันจริง ๆ

---

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

• เอกสารการเชื่อมต่อ Uptime Kuma
• ข้อมูลอ้างอิงเงื่อนไขของช่อง
• การแจ้งเตือนจาก Upptime ด้วย Echobell
• สายโทรแจ้งเตือนเมื่อ API ของคุณล่ม
• คู่มือแก้อาการล้าจากการแจ้งเตือนสำหรับนักพัฒนา