Uptime Kuma คืออะไร? เฝ้าดูเว็บล่มด้วยตัวเอง และทำไมต้องรันแยกเครื่อง

อัปเดต 2026-08-22อ่าน ~9 นาที

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

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

แต่มีเงื่อนไขหนึ่งที่คนพลาดกันบ่อยมาก และเป็นประเด็นหลักของบทความนี้ — เครื่องที่รัน Uptime Kuma ต้องเป็นคนละเครื่องกับสิ่งที่มันเฝ้าดู ไม่อย่างนั้นระบบเตือนภัยจะดับไปพร้อมกับสิ่งที่มันควรจะเตือน

Uptime Kuma คืออะไร

Uptime Kuma คือเครื่องมือ uptime monitoring แบบ self-hosted หมายความว่าคุณเอาไปติดตั้งบนเซิร์ฟเวอร์ของตัวเองแล้วใช้งานได้เลย ไม่ต้องสมัครบริการรายเดือนกับใคร หน้าที่หลักของมันคือคอยตรวจสอบเป็นรอบว่าเว็บไซต์ เซิร์ฟเวอร์ หรือบริการที่คุณกำหนดไว้ยังตอบสนองปกติอยู่หรือไม่ ถ้าไม่ตอบสนองก็ส่งแจ้งเตือนออกไปตามช่องทางที่ตั้งไว้

โครงการนี้พัฒนาโดย Louis Lam และเปิดซอร์สโค้ดบน GitHub ภายใต้สัญญาอนุญาต MIT ซึ่งเป็นไลเซนส์แบบเปิดกว้าง ใช้งานในเชิงพาณิชย์ได้ ตัวโปรแกรมไม่มีค่าลิขสิทธิ์ ค่าใช้จ่ายที่คุณจ่ายจริงมีเพียงค่าเครื่องที่เอาไปรันเท่านั้น

หน้าตาการใช้งานเป็นเว็บแดชบอร์ดที่เปิดผ่านเบราว์เซอร์ มีกราฟแสดงสถานะย้อนหลังของแต่ละรายการที่เฝ้าดู เพิ่มรายการใหม่ได้จากหน้าเว็บโดยไม่ต้องแก้ไฟล์ตั้งค่า และยังสร้างหน้าสถานะสาธารณะ (status page) เพื่อประกาศสถานะระบบให้ผู้ใช้ดูเองได้ด้วย

💡 สรุปสั้น: Uptime Kuma = ยามเฝ้าประตูที่คอยเคาะประตูเว็บคุณทุกไม่กี่สิบวินาที ถ้าไม่มีใครมาเปิดก็โทรบอกคุณทันที — ตัวมันเองไม่ได้ทำให้เว็บล่มน้อยลง แต่ทำให้คุณรู้เร็วขึ้นมาก

ตรวจสอบอะไรได้บ้าง

หลายคนเข้าใจว่า Uptime Kuma เช็คได้แค่ว่าเว็บเปิดขึ้นหรือไม่ ซึ่งเป็นแค่ส่วนเดียว จริง ๆ แล้วมันรองรับการตรวจสอบหลายประเภท ตั้งแต่ระดับเครือข่ายไปจนถึงระดับฐานข้อมูล ตารางด้านล่างสรุปประเภทที่ใช้บ่อยที่สุดสำหรับคนทำเว็บและดูแลเซิร์ฟเวอร์

ประเภทการตรวจสอบ	ตรวจอะไร	เหมาะกับกรณีไหน
HTTP(s)	ยิงคำขอไปที่ URL แล้วดูรหัสสถานะและเวลาตอบกลับ	เว็บไซต์และหน้าเว็บทั่วไป เป็นประเภทที่ใช้บ่อยที่สุด
HTTP(s) Keyword	ยิงเหมือนข้างบน แต่ตรวจเพิ่มว่ามีข้อความที่กำหนดอยู่ในหน้าไหม	จับกรณีเว็บตอบ 200 แต่เนื้อหาข้างในพัง เช่นขึ้นหน้า error ของระบบ
TCP Port	ลองเปิดการเชื่อมต่อไปยังพอร์ตที่ระบุ	บริการที่ไม่ใช่เว็บ เช่น SSH, mail server หรือพอร์ตของแอปเฉพาะทาง
Ping	ส่ง ICMP ไปถามว่าเครื่องยังตอบอยู่ไหม	เช็คว่าตัวเครื่องยังมีชีวิตอยู่ แม้บริการข้างในจะยังไม่ขึ้น
DNS	สอบถามเรกคอร์ด DNS ของโดเมนที่กำหนด	จับกรณีโดเมนชี้ผิด เรกคอร์ดถูกแก้ หรือ DNS ไม่ตอบ
ฐานข้อมูล (MySQL, PostgreSQL, MongoDB, MSSQL)	ลองเชื่อมต่อเข้าฐานข้อมูลจริง	เว็บที่พังเพราะฐานข้อมูลล่ม ทั้งที่ตัวเว็บเซิร์ฟเวอร์ยังทำงาน
Push	รอให้ระบบภายนอกยิงสัญญาณเข้ามาบอกว่ายังทำงานอยู่	งานเบื้องหลังที่ไม่มีพอร์ตให้เช็ค เช่นสคริปต์ backup หรือ cron job
Docker Container	ตรวจสถานะคอนเทนเนอร์ผ่าน Docker	เครื่องที่รันหลายบริการเป็นคอนเทนเนอร์และอยากรู้ว่าตัวไหนหยุดไป

💡 สำหรับเว็บทั่วไป แนะนำให้ใช้แบบ Keyword มากกว่า HTTP เปล่า ๆ เพราะเว็บที่ฐานข้อมูลล่มมักยังตอบรหัส 200 กลับมาพร้อมหน้าขาว ถ้าเช็คแค่รหัสสถานะ คุณจะไม่รู้เลยว่าเว็บใช้งานไม่ได้

แจ้งเตือนไปทางไหนได้บ้าง

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

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

ช่องทาง	ลักษณะ	ข้อสังเกต
Telegram	ส่งผ่านบอทเข้าแชทหรือกลุ่ม	ตั้งง่ายที่สุดช่องทางหนึ่ง เตือนเด้งทันทีบนมือถือ
Discord	ส่งเข้าห้องผ่าน webhook	เหมาะกับทีมที่ใช้ Discord อยู่แล้ว เก็บประวัติในห้องได้
Slack / Microsoft Teams	ส่งเข้าแชนแนลของทีม	เหมาะกับองค์กร แต่ต้องระวังการปิดแจ้งเตือนนอกเวลางาน
LINE	ส่งผ่าน LINE Messaging API	ใกล้ตัวคนไทยที่สุด แต่ต้องเตรียมบัญชีทางการและโทเคนก่อน
อีเมล (SMTP)	ส่งผ่านเซิร์ฟเวอร์ SMTP ที่คุณกำหนดเอง	ใช้เป็นช่องทางสำรองได้ดี แต่ไม่ควรใช้เป็นช่องทางหลักเพราะอาจเห็นช้า
Webhook	ยิง HTTP POST พร้อมข้อมูลสถานะไปยัง URL ที่กำหนด	ยืดหยุ่นที่สุด ต่อเข้าระบบ automation ของคุณเองได้
PagerDuty / Opsgenie / ntfy / Pushover	บริการแจ้งเตือนเฉพาะทางและ push บนมือถือ	เหมาะกับทีมที่มีเวรดูแลระบบและต้องการเสียงปลุกจริงจัง

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

ทำไมต้องรัน Uptime Kuma แยกเครื่อง (ประเด็นสำคัญที่สุด)

นี่คือจุดที่คนติดตั้งใหม่พลาดกันมากที่สุด และเป็นความผิดพลาดที่ทำให้ระบบเฝ้าระวังทั้งระบบไร้ความหมาย — การเอา Uptime Kuma ไปติดตั้งบนเซิร์ฟเวอร์เครื่องเดียวกับเว็บที่มันต้องเฝ้าดู

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

พูดอีกแบบคือ ระบบเฝ้าระวังที่อยู่ในสิ่งที่มันเฝ้า จะรายงานได้เฉพาะตอนที่ทุกอย่างยังปกติดี ซึ่งเป็นตอนที่คุณไม่ต้องการรายงานอยู่แล้ว ปัญหาแบบเดียวกันนี้อธิบายไว้กว้าง ๆ ในเรื่องการแยกบริการออกจากกัน ซึ่งถ้าคุณยังไม่คุ้นกับการแยกงานคนละเครื่อง แนะนำอ่าน VPS คืออะไร ประกอบ เพราะการมีเครื่องเล็ก ๆ เพิ่มอีกหนึ่งเครื่องคือทางออกที่ตรงที่สุด ปัญหาที่ตามมาจากการรันรวมเครื่องมีดังนี้

เครื่องดับ = ระบบแจ้งเตือนดับตาม ไม่มีข้อความใดถูกส่งออกไป และคุณจะไม่มีทางรู้ว่าเกิดอะไรขึ้นเมื่อไหร่
แจ้งเตือนผิดพลาดเวลาเครื่องโหลดหนัก เพราะตัวมอนิเตอร์แย่ง CPU กับเว็บอยู่บนเครื่องเดียวกัน พอเว็บช้าตัวเช็คก็หมดเวลาไปด้วยแล้วรายงานว่าล่มทั้งที่ผู้ใช้จริงยังเข้าได้
มองไม่เห็นปัญหาระดับเครือข่ายและผู้ให้บริการ เช่นเส้นทางอินเทอร์เน็ตขาด ไฟร์วอลล์บล็อก หรือ IP ถูกบล็อกจากภายนอก เพราะการเช็คจากในเครื่องตัวเองไม่เคยออกไปทางเดียวกับผู้ใช้จริง
ตรวจไม่ได้เมื่อ Docker หรือบริการพื้นฐานของเครื่องมีปัญหา เพราะตัวมอนิเตอร์เองก็อาศัยสิ่งเดียวกันในการทำงาน
ประวัติสถานะขาดหาย ช่วงที่ล่มจริงจะกลายเป็นช่องว่างในกราฟ แทนที่จะเป็นบันทึกว่าล่มตอนไหนถึงตอนไหน ทำให้ย้อนตรวจสอบทีหลังไม่ได้

💡 หลักง่าย ๆ ข้อเดียว: ยามต้องยืนอยู่นอกบ้าน ไม่ใช่ในบ้าน — ให้ Uptime Kuma อยู่คนละเครื่อง (ยิ่งดีถ้าคนละศูนย์ข้อมูล) แล้วเช็คเว็บของคุณผ่านชื่อโดเมนจากอินเทอร์เน็ตภายนอก ทางเดียวกับที่ผู้ใช้จริงเข้าถึง

เทียบกับบริการ monitoring แบบเสียเงิน

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

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

หัวข้อ	Uptime Kuma (self-host)	บริการ monitoring แบบเสียเงิน
ค่าใช้จ่าย	ตัวโปรแกรมฟรี จ่ายแค่ค่าเครื่องที่เอาไปรัน	จ่ายรายเดือน มักคิดตามจำนวนรายการและความถี่
จำนวนรายการที่เฝ้าดู	ไม่จำกัดโดยตัวโปรแกรม ขึ้นกับกำลังเครื่องเท่านั้น	แพ็กเกจฟรีหรือระดับเริ่มต้นมักจำกัดจำนวน
จุดที่ยิงตรวจ	ยิงจากเครื่องคุณเครื่องเดียว เว้นแต่จะตั้งเพิ่มเอง	ยิงจากหลายประเทศให้อยู่แล้ว แยกแยะปัญหาเฉพาะภูมิภาคได้
ใครดูแลตัวระบบเฝ้าระวัง	คุณเอง ต้องอัปเดต สำรองข้อมูล และคอยดูว่าเครื่องยังอยู่	ผู้ให้บริการดูแลให้ ไม่ต้องอัปเดตเอง
ข้อมูลอยู่ที่ไหน	อยู่บนเครื่องคุณทั้งหมด ควบคุมเองได้เต็มที่	อยู่บนระบบของผู้ให้บริการ
ถ้าตัวระบบเฝ้าระวังเองล่ม	เงียบสนิท ไม่มีใครเตือน ต้องหาวิธีเฝ้าตัวเฝ้าอีกที	มีระบบสำรองของผู้ให้บริการรองรับ
ความยืดหยุ่นในการปรับแต่ง	สูง แก้ตั้งค่าได้ทุกอย่าง ต่อ webhook เข้าระบบตัวเองได้	จำกัดตามที่ผู้ให้บริการเปิดให้

💡 ทางสายกลางที่หลายคนใช้คือใช้ Uptime Kuma เป็นตัวหลักเพราะยืดหยุ่นและไม่จำกัดจำนวนรายการ แล้วเสริมบริการภายนอกแบบแพ็กเกจฟรีอีกหนึ่งเจ้าไว้คอยเช็คเฉพาะเครื่อง Uptime Kuma เอง เพื่อไม่ให้เกิดจุดบอดว่าตัวเฝ้าล่มแล้วไม่มีใครรู้

สเปก VPS ที่ควรใช้

เอกสารของโครงการระบุเพียงว่าต้องใช้ Node.js เวอร์ชัน 20.4 ขึ้นไปสำหรับการติดตั้งแบบไม่ใช้ Docker และรองรับ Linux ดิสโทรหลัก ๆ แต่ไม่ได้ระบุความต้องการขั้นต่ำด้าน CPU แรม หรือพื้นที่ดิสก์ไว้อย่างเป็นทางการ ในทางปฏิบัติ Uptime Kuma กินทรัพยากรน้อยมากเมื่อเทียบกับเครื่องมือมอนิเตอร์ตัวอื่น เพราะงานหลักของมันคือยิงคำขอสั้น ๆ เป็นรอบแล้วบันทึกผล ไม่ได้ประมวลผลข้อมูลหนัก ๆ

สิ่งที่ทำให้กินทรัพยากรเพิ่มคือจำนวนรายการที่เฝ้าดูและความถี่ที่ตั้งไว้ ยิ่งเฝ้าเยอะและถี่ ยิ่งใช้ CPU และดิสก์มากขึ้น เพราะประวัติทุกรอบถูกเก็บลงฐานข้อมูล ตารางด้านล่างคือแพ็กเกจ VPS ของ Plusweb ทุกตัวมี 1 Public IPv4 ในตัว ตัวเลขในวงเล็บคือราคาต่อเดือนเมื่อชำระรายปี

แพ็กเกจ	CPU	RAM	SSD	ราคา/เดือน (รายปี)	เหมาะกับ
VPS-00	1 vCore	1 GB	15 GB	150฿ (120฿)	เฝ้าดูไม่กี่สิบรายการ ใช้เป็นเครื่องมอนิเตอร์อย่างเดียว
VPS-01	1 vCore	3 GB	30 GB	250฿ (200฿)	เฝ้าดูจำนวนมากขึ้น หรือเก็บประวัติยาว และมีที่เหลือให้เครื่องมืออื่น
VPS-02	2 vCores	4 GB	60 GB	350฿ (280฿)	อยากรวมเครื่องมือดูแลระบบตัวอื่นไว้บนเครื่องเดียวกัน
VPS-03	4 vCores	8 GB	100 GB	600฿ (480฿)	ใช้เป็นเครื่องเครื่องมือกลางของทีม ไม่ใช่แค่มอนิเตอร์

💡 สำหรับคนส่วนใหญ่ VPS-00 ที่ 150฿ ต่อเดือน (120฿ เมื่อชำระรายปี) เพียงพอสำหรับงานเฝ้าดูล้วน ๆ แล้ว ประเด็นไม่ได้อยู่ที่สเปกต้องแรง แต่อยู่ที่ต้องเป็นคนละเครื่องกับสิ่งที่เฝ้าดู

ภาพรวมการติดตั้งบน VPS

วิธีติดตั้งที่โครงการแนะนำคือผ่าน Docker Compose ส่วนทางเลือกอื่นมีทั้งการรันด้วยคำสั่ง docker run ตรง ๆ และการติดตั้งแบบไม่ใช้ Docker ด้วย Node.js คู่กับ PM2 สำหรับให้ทำงานเบื้องหลัง ถ้ายังไม่คุ้นกับ Docker แนะนำอ่าน Docker คืออะไร ก่อน และถ้าอยากจัดการคอนเทนเนอร์ผ่านหน้าเว็บแทนการพิมพ์คำสั่ง ลองดู Portainer ประกอบ ขั้นตอนโดยรวมเป็นดังนี้

1เตรียม VPS หนึ่งเครื่องที่ไม่ใช่เครื่องเดียวกับเว็บที่จะเฝ้าดู ติดตั้ง Linux แล้วอัปเดตแพ็กเกจให้เรียบร้อยก่อนเริ่ม
2ตั้งค่าความปลอดภัยพื้นฐานของเครื่อง เช่นสร้างผู้ใช้ที่ไม่ใช่ root เปิดใช้กุญแจ SSH แทนรหัสผ่าน และตั้งไฟร์วอลล์ให้เปิดเฉพาะพอร์ตที่จำเป็น
3ติดตั้ง Docker และ Docker Compose ลงบนเครื่อง หรือถ้าเลือกทางไม่ใช้ Docker ก็ติดตั้ง Node.js เวอร์ชัน 20.4 ขึ้นไปพร้อม Git และ PM2
4สร้างไฟล์ตั้งค่า Compose ตามตัวอย่างในเอกสารของโครงการ จุดสำคัญคือต้องผูก volume ไว้กับโฟลเดอร์บนเครื่องจริง เพราะฐานข้อมูลและประวัติทั้งหมดเก็บอยู่ตรงนั้น
5สั่งเปิดบริการด้วย docker compose up แล้วรอให้คอนเทนเนอร์ทำงาน จากนั้นเปิดเว็บแดชบอร์ดผ่านพอร์ตที่กำหนดไว้
6ตั้งบัญชีผู้ดูแลในหน้าจอแรกที่เปิดขึ้นมา ใช้รหัสผ่านที่แข็งแรง แล้วเปิดการยืนยันตัวตนสองชั้นในหน้าตั้งค่าความปลอดภัยทันที
7ชี้โดเมนย่อยสักตัวมาที่เครื่องนี้ แล้วตั้ง reverse proxy ให้เปิดผ่าน HTTPS จากนั้นปิดไม่ให้เข้าถึงพอร์ตดิบจากภายนอก
8เพิ่มรายการที่ต้องการเฝ้าดูทีละตัวจากหน้าเว็บ เลือกประเภทให้ตรงกับสิ่งที่ตรวจ และตั้งชื่อให้อ่านแล้วรู้ทันทีว่าคืออะไร
9ตั้งช่องทางแจ้งเตือนอย่างน้อยสองช่อง แล้วกดทดสอบส่งจริงทุกช่องก่อนถือว่าติดตั้งเสร็จ
10ตั้งการสำรองข้อมูลของโฟลเดอร์ volume ไว้ที่อื่น เพราะถ้าเครื่องมอนิเตอร์เสีย ประวัติและรายการทั้งหมดจะหายไปด้วย

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

ตั้งค่าที่คนมักพลาด

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

ตั้งรอบตรวจถี่เกินไป — Uptime Kuma ตั้งรอบได้ถี่ระดับหลักสิบวินาที แต่ถี่เกินไปกับเป้าหมายภายนอกอาจถูกมองว่าเป็นทราฟฟิกผิดปกติจนโดนไฟร์วอลล์หรือ CDN บล็อก IP ของเครื่องมอนิเตอร์ สำหรับเว็บทั่วไป รอบระดับหนึ่งถึงห้านาทีก็เพียงพอ
ไม่ตั้งจำนวนครั้งก่อนแจ้งเตือน — ถ้าให้เตือนทันทีที่พลาดครั้งเดียว คุณจะโดนปลุกจากอาการสะดุดชั่วคราวของเครือข่ายบ่อยมาก ตั้งให้ต้องพลาดติดกันสองถึงสามรอบก่อนค่อยเตือนจะสมจริงกว่า
ไม่เคยทดสอบช่องทางแจ้งเตือน — ตั้งค่าไว้แล้วคิดว่าใช้ได้ แต่โทเคนหมดอายุ บอทถูกเตะออกจากกลุ่ม หรือกรอกปลายทางผิด กว่าจะรู้ก็ตอนที่เว็บล่มจริงแล้วไม่มีข้อความเข้ามา ควรกดทดสอบซ้ำเป็นระยะ ไม่ใช่แค่ตอนติดตั้ง
ลืมต่ออายุโดเมนและใบรับรอง SSL ของตัว Uptime Kuma เอง — เครื่องมือเฝ้าระวังก็มีโดเมนและใบรับรองเหมือนระบบอื่น ถ้าปล่อยหมดอายุ คุณจะเข้าแดชบอร์ดไม่ได้ในวันที่ต้องการดูมันที่สุด ทางแก้คือให้ Uptime Kuma เฝ้าดูโดเมนของตัวเองด้วย เพราะการตรวจแบบ HTTP(s) จะติดตามวันหมดอายุใบรับรองให้อยู่แล้ว
ใช้ IP แทนชื่อโดเมนตอนตั้งรายการ — การเช็คด้วย IP ตรง ๆ จะข้ามขั้นตอน DNS ไปทั้งหมด ถ้าโดเมนชี้ผิดหรือ DNS ล่ม ผู้ใช้เข้าเว็บไม่ได้แต่มอนิเตอร์ยังเขียวอยู่ ควรเช็คด้วยชื่อโดเมนเดียวกับที่ผู้ใช้ใช้
ไม่ตั้งช่วงปิดปรับปรุง — เวลาอัปเดตระบบตามแผน ถ้าไม่ประกาศช่วงปิดปรับปรุงไว้ ระบบจะยิงแจ้งเตือนรัว ๆ จนคนในทีมเริ่มชินและเพิกเฉยต่อการแจ้งเตือนทุกครั้งหลังจากนั้น
ไม่สำรองข้อมูล — ประวัติสถานะ รายการทั้งหมด และการตั้งค่าช่องทางแจ้งเตือนอยู่ในไฟล์ฐานข้อมูลในโฟลเดอร์ volume ถ้าไม่ได้สำรองไว้ที่อื่น การกู้เครื่องใหม่หมายถึงต้องตั้งใหม่ทั้งหมดตั้งแต่ต้น

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

สรุป

Uptime Kuma คือเครื่องมือ uptime monitoring แบบโอเพนซอร์สที่ติดตั้งบนเครื่องตัวเองได้ฟรี ตรวจได้ทั้งเว็บ พอร์ต ping DNS ฐานข้อมูล และคอนเทนเนอร์ พร้อมช่องทางแจ้งเตือนกว่า 90 ช่องทาง เหมาะกับคนที่อยากรู้ก่อนลูกค้าว่าระบบมีปัญหา โดยไม่ต้องผูกกับค่าบริการรายเดือน

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

ทางที่ตรงที่สุดคือแยกเครื่องเล็ก ๆ มาหนึ่งเครื่องไว้ทำหน้าที่นี้โดยเฉพาะ ดูตัวเลือกได้ที่ แพ็กเกจ VPS ของ Plusweb และถ้ายังลังเลว่าจะใช้ VPS หรือโฮสติ้งแบบแชร์ ลองอ่าน VPS ต่างจาก Web Hosting ยังไง ก่อน เพราะโฮสติ้งแบบแชร์ทั่วไปมักไม่ให้สิทธิ์ติดตั้งซอฟต์แวร์เองแบบนี้

💡 จำสามข้อนี้ก็พอ: แยกเครื่องเสมอ · เช็คด้วยชื่อโดเมนไม่ใช่ IP · และทดสอบช่องทางแจ้งเตือนจริงก่อนถือว่าเสร็จ

อยากมีเครื่องเฝ้าระวังแยกของตัวเอง?

VPS ของ Plusweb มีสิทธิ์ root เต็มและ Public IPv4 ในตัว เริ่มต้น 120฿/เดือน (รายปี) ติดตั้ง Uptime Kuma แยกจากเซิร์ฟเวอร์เว็บได้ทันที

ดูแพ็กเกจ VPS สั่งซื้อทันที

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

Uptime Kuma คืออะไรแบบสั้นที่สุด?

Uptime Kuma คือเครื่องมือโอเพนซอร์สแบบ self-hosted ที่คอยตรวจเป็นรอบว่าเว็บ เซิร์ฟเวอร์ หรือบริการที่คุณกำหนดยังตอบสนองปกติอยู่หรือไม่ ถ้าไม่ตอบสนองก็ส่งแจ้งเตือนออกไปตามช่องทางที่ตั้งไว้ พัฒนาโดย Louis Lam เผยแพร่ภายใต้สัญญาอนุญาต MIT ตัวโปรแกรมไม่มีค่าใช้จ่าย จ่ายแค่ค่าเครื่องที่เอาไปรัน

ติดตั้ง Uptime Kuma บนเซิร์ฟเวอร์เดียวกับเว็บได้ไหม?

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

Uptime Kuma ต้องใช้ VPS สเปกเท่าไหร่?

เอกสารของโครงการไม่ได้ระบุความต้องการขั้นต่ำด้าน CPU แรม หรือดิสก์ไว้อย่างเป็นทางการ ระบุเพียงว่าต้องใช้ Node.js 20.4 ขึ้นไปหากติดตั้งแบบไม่ใช้ Docker ในทางปฏิบัติมันกินทรัพยากรน้อย เครื่องเล็กอย่าง VPS-00 (1 vCore / 1 GB / 15 GB) ที่ 150฿ ต่อเดือนก็ใช้เฝ้าดูงานทั่วไปได้ ถ้าเฝ้าดูจำนวนมากหรือเก็บประวัติยาว ค่อยขยับไป VPS-01 (1 vCore / 3 GB / 30 GB)

Uptime Kuma แจ้งเตือนทาง LINE ได้ไหม?

ได้ Uptime Kuma มีผู้ให้บริการแจ้งเตือนในตัวมากกว่า 90 ราย ซึ่งรวมถึงการส่งผ่าน LINE Messaging API นอกเหนือจากช่องทางยอดนิยมอย่าง Telegram, Discord, Slack, Microsoft Teams, อีเมลผ่าน SMTP และ webhook ทั่วไป แนะนำให้ตั้งอย่างน้อยสองช่องทางที่ไม่พึ่งพาระบบเดียวกัน เผื่อกรณีช่องทางใดช่องทางหนึ่งมีปัญหาพร้อมกับเว็บของคุณ

Uptime Kuma ต่างจากบริการ monitoring แบบเสียเงินยังไง?

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

ต้องใช้ Docker ไหมถึงจะติดตั้ง Uptime Kuma ได้?

ไม่จำเป็น แต่ Docker Compose เป็นวิธีที่โครงการแนะนำเพราะติดตั้งง่ายและอัปเดตสะดวกที่สุด ทางเลือกอื่นคือรันด้วยคำสั่ง docker run ตรง ๆ หรือติดตั้งแบบไม่ใช้ Docker ด้วย Node.js 20.4 ขึ้นไปคู่กับ Git และ PM2 เพื่อให้ทำงานเบื้องหลัง ไม่ว่าจะเลือกวิธีไหน สิ่งที่ต้องระวังเหมือนกันคือข้อมูลทั้งหมดอยู่ในโฟลเดอร์ที่ผูกไว้ จึงต้องสำรองข้อมูลโฟลเดอร์นั้นเสมอ

GUIDES