---
title: "รับสายแจ้งเตือนเมื่อ API ของคุณล่ม"
description: "การแจ้งเตือนแบบพุชธรรมดามักจมหายไปกับสัญญาณรบกวนเมื่อ API ล้มเหลว มาดูวิธีตั้งค่าสายโทรแจ้งเตือนที่ปลุกคุณได้จริงเมื่อบริการสำคัญล่ม"
date: 2026-03-13
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - มอนิเตอร์ API
  - แจ้งเตือนที่มือถือ
  - เซิร์ฟเวอร์ล่ม
  - แจ้งเตือนวิกฤต
  - webhook
---

# รับสายแจ้งเตือนเมื่อ API ของคุณล่ม

การที่ API ของคุณล่มตอนตีสามไม่ใช่ปัญหา ปัญหาคือคุณเพิ่งมารู้ตอนเก้าโมงเช้า ตอนที่ผู้ใช้ถล่มกล่องอีเมลซัพพอร์ตของคุณไปเรียบร้อยแล้ว

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

สายโทรแจ้งเตือนเปลี่ยนสมการนี้ เมื่อการตรวจสอบสถานะ API ของคุณล้มเหลว มือถือของคุณจะดังขึ้นจริง ๆ เหมือนสายโทรเข้าเรื่องเร่งด่วนอื่น ๆ คุณรับสาย ฟังว่าเกิดอะไรขึ้น แล้วเริ่มแก้ได้ทันที แทนที่จะเป็นอีกหลายชั่วโมงถัดมา

## ทำไมการแจ้งเตือนแบบพุชจึงใช้ไม่ได้ผลกับบริการสำคัญ

สมาร์ตโฟนโดยเฉลี่ยได้รับการแจ้งเตือนแบบพุชวันละ 50 ถึง 100 ครั้ง การแจ้งเตือนว่า API ล่มของคุณต้องแข่งกับการอัปเดตแอป การแจ้งเตือนโซเชียลมีเดีย ข่าวสาร และแอปอื่น ๆ ทั้งเครื่อง เมื่อทุกอย่างเร่งด่วนไปหมด ก็เลยไม่มีอะไรรู้สึกเร่งด่วนเลย

สิ่งนี้สร้างรูปแบบที่อันตราย:

1. เครื่องมือมอนิเตอร์ของคุณตรวจพบว่า API คืนค่าข้อผิดพลาด 500
2. มันส่งการแจ้งเตือนแบบพุชไปที่มือถือของคุณ
3. มือถือของคุณวางคว่ำอยู่บนโต๊ะ พร้อมเปิดโหมดโฟกัสไว้
4. การแจ้งเตือนนอนนิ่งอยู่ตรงนั้นเงียบ ๆ จนกว่าจะมีคนสังเกตเห็น ซึ่งก็อีกหลายชั่วโมงถัดมา

สำหรับไมโครเซอร์วิสที่ไม่สำคัญ ความล่าช้านั้นแค่น่ารำคาญ แต่สำหรับ API การชำระเงิน บริการยืนยันตัวตน หรือแบ็กเอนด์ของผลิตภัณฑ์หลักของคุณ ความล่าช้านั้นแลกมาด้วยเงินและความไว้ใจจริง ๆ

## สายโทรแจ้งเตือนกับ Echobell ทำงานอย่างไร

Echobell ส่งการแจ้งเตือนในสามระดับความเร่งด่วน:

- **ปกติ (Active):** การแจ้งเตือนแบบพุชมาตรฐาน
- **สำคัญตามเวลา:** ทะลุโหมดโฟกัสของ iOS ได้ แต่ไม่ดังเป็นเสียงเรียกเข้า
- **โทรเข้า:** ทำให้มือถือของคุณดังเหมือนสายโทรเข้าปกติ

สำหรับความล้มเหลวของ API ที่กระทบผู้ใช้ ระดับโทรเข้าถือว่าเหมาะสม เพราะมันสะท้อนวิธีที่คุณจะรับมือกับสายโทรเร่งด่วนอื่น ๆ อยู่แล้ว คุณรับสายเพราะโทรศัพท์ดัง

การตั้งค่าตรงไปตรงมา:

1. สร้างช่องใน Echobell
2. ตั้งประเภทการแจ้งเตือนเป็น **โทรเข้า**
3. เชื่อมเครื่องมือมอนิเตอร์ของคุณผ่าน webhook
4. เมื่อการตรวจสอบสถานะล้มเหลว Echobell จะโทรหาคุณ

## ตั้งค่าสายโทรแจ้งเตือนจากเครื่องมือมอนิเตอร์ของคุณ

แพลตฟอร์มมอนิเตอร์ส่วนใหญ่ส่ง webhook ได้เมื่อการตรวจสอบล้มเหลว นี่คือวิธีต่อสายมันเข้าด้วยกัน

### ใช้การตรวจสอบสถานะที่คุณมีอยู่แล้ว

ถ้าคุณมีปลายทางสำหรับตรวจสอบสถานะอยู่แล้ว (เช่น `/health` หรือ `/status`) ให้ตั้งระบบมอนิเตอร์ให้เรียกมันตามช่วงเวลาสม่ำเสมอ และเมื่อผลลัพธ์ไม่ใช่ 200 ก็ให้ทริกเกอร์ webhook

Echobell รับ payload ของ webhook ที่มีหัวข้อและเนื้อหาได้:

```bash
curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "title": "API DOWN: payment-service",
    "body": "Health check failed - 500 error at 03:42 UTC",
    "notificationType": "calling",
    "externalLink": "https://your-dashboard.example.com/incidents/123"
  }'
```

ฟิลด์ `notificationType: calling` นี่เองที่ทำให้โทรศัพท์ดัง

### ควรใส่อะไรไว้ในการแจ้งเตือน

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

- **ชื่อบริการ** — API หรือไมโครเซอร์วิสตัวไหนที่ล้มเหลว
- **ประเภทข้อผิดพลาด** — หมดเวลา ข้อผิดพลาด 5xx หรือถูกปฏิเสธการเชื่อมต่อ
- **เวลา** — ความล้มเหลวเริ่มขึ้นเมื่อไร
- **ลิงก์** — จะไปตรวจสอบต่อได้ที่ไหนทันที

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

## เลือกระดับความเร่งด่วนให้เหมาะสม

ไม่ใช่ทุกความล้มเหลวของ API ที่ต้องโทรหา ใช้การแจ้งเตือนแบบโทรเข้ากับ:

- บริการชำระเงินและออกใบเรียกเก็บ
- ปลายทางการยืนยันตัวตนและการเข้าสู่ระบบ
- API ของผลิตภัณฑ์หลักที่ผู้ใช้เรียกใช้โดยตรง
- บริการที่ระบบสำคัญอื่น ๆ พึ่งพาอยู่

ใช้การแจ้งเตือนแบบสำคัญตามเวลากับ:

- บริการรองที่สำคัญแต่ไม่กระทบรายได้โดยตรง
- สภาพแวดล้อม development หรือ staging
- สัญญาณเตือน (อัตราข้อผิดพลาดสูงที่ยังไม่ถึงขั้นล่ม)

ใช้การแจ้งเตือนแบบปกติกับ:

- งานเบื้องหลังที่ไม่สำคัญ
- ตัวชี้วัดเชิงข้อมูลที่ไม่ต้องลงมือทำอะไร

การแบ่งระดับแบบนี้ทำให้คุณยังได้รับการแจ้งเตือน โดยไม่เกิดอาการล้าจากการแจ้งเตือน

## ขยายไปยังหลายบริการ

หากคุณดูแล API มากกว่าหนึ่งตัว ให้สร้างช่องแยกสำหรับแต่ละบริการหรือแต่ละกลุ่มบริการ:

- `production-payment-api` — ระดับโทรเข้า
- `production-user-api` — ระดับโทรเข้า
- `production-analytics-api` — สำคัญตามเวลา
- `staging-all` — สำคัญตามเวลา

วิธีนี้ทำให้คุณปรับความเร่งด่วนได้ทีละบริการ API การชำระเงินของคุณสมควรได้รับสายโทร ส่วนไปป์ไลน์วิเคราะห์ข้อมูลอาจจะไม่

## ประโยชน์ที่แท้จริง

คุณค่าของสายโทรแจ้งเตือนไม่ได้อยู่ที่เสียงเรียกเข้า แต่อยู่ที่การเปลี่ยนแปลงพฤติกรรมที่มันสร้างขึ้น:

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

สำหรับบริการสำคัญ ความต่างตรงนี้แหละคือหัวใจทั้งหมด

---

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

- [สายโทรแจ้งเตือนสำหรับเหตุการณ์วิกฤต](/th/features/call-notifications)
- [การแจ้งเตือนผ่าน webhook สำหรับ iPhone](/th/features/webhooks)
- [การแจ้งเตือนในโหมดโฟกัส](/th/focus-mode-alerts)
- [แจ้งเตือนเซิร์ฟเวอร์ล่มด้วยสายโทรเข้า](/th/server-down-phone-call-alerts)
- [การแจ้งเตือนด้วยสายโทรจาก Grafana](/th/blog/grafana-call-notification)
- [มอนิเตอร์ uptime ด้วย Echobell](/th/blog/upptime-alerts-with-echobell)
- [การทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)