Uptime monitoring เป็นการตรวจสอบว่าเว็บไซต์หรือ API ยังตอบรับ request ได้หรือไม่ จากจุดภายนอกที่ไม่ใช่เซิร์ฟเวอร์เอง เมื่อระบบล่ม tool เหล่านี้จะแจ้งเตือนผ่าน email, SMS, Slack หรือ webhook ให้ทีม oncall รู้ทันที และบันทึก downtime history เพื่อคำนวณ SLA ในแต่ละเดือน
บทความนี้เปรียบเทียบ 6 tool ยอดนิยม ทั้งแบบ self-hosted ที่รันบน VPS เองได้ฟรี และแบบ SaaS ที่ไม่ต้อง manage server พร้อมตัวอย่างการ deploy Uptime Kuma ด้วย Docker Compose และคำแนะนำในการเลือกให้เหมาะกับขนาดทีมและงบประมาณ
Self-Hosted vs SaaS
ข้อต่างพื้นฐาน 2 แบบช่วยตัดสินใจเลือก tool ที่เหมาะกับ workflow ของทีม
- Self-hosted — รันบน VPS/เซิร์ฟเวอร์เอง ควบคุมข้อมูลได้ 100% ไม่มีค่าใช้จ่ายรายเดือน แต่ต้อง maintain เอง และถ้า monitor server ล่มจะไม่รู้ (ต้องมี external monitor คุม monitor)
- SaaS — ใช้บริการของผู้ให้บริการภายนอก จ่ายรายเดือน ไม่ต้อง manage ได้ probe จากหลาย region ทั่วโลก เหมาะกับทีมที่ต้องการ uptime ของบริการเอง ไม่ใช่ของ monitor
Uptime Kuma (Self-Hosted, Open Source)
Uptime Kuma เป็น open source tool ที่ได้รับความนิยมสูงใน community DevOps/SysAdmin เพราะ UI สวย setup ง่าย รองรับ monitor หลายรูปแบบ เช่น HTTP(s), TCP, Ping, DNS, Docker container, Keyword, JSON query, SSL certificate expiry และ Steam game server
- ข้อดี — ฟรี 100%, UI modern, มี status page ในตัว, notification รองรับ 90+ channel, multi-user ตั้งแต่ version 1.23
- ข้อเสีย — probe จากจุดเดียว (ที่ monitor ทำงาน), ถ้าต้องการ multi-region ต้อง deploy หลาย instance แล้วรวมเอง
- เหมาะกับ — ทีมเล็กถึงกลาง, homelab, internal service monitoring
# docker-compose.yml - Uptime Kuma
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
volumes:
- ./data:/app/data
ports:
- "3001:3001"รันด้วย docker compose up -d แล้วเปิด http://server-ip:3001 ตั้ง admin account แล้วเริ่ม add monitor ได้ทันที — UI ให้ตั้ง interval 20s-24h, retry logic, tag สำหรับ grouping และ maintenance window สำหรับ suppress alert ขณะ deploy
Statuspage (SaaS, Atlassian)
Statuspage จาก Atlassian เป็น tool ที่เน้นการสื่อสาร status กับ customer ไม่ใช่ monitor เอง ใช้คู่กับ tool อื่นที่ detect incident แล้ว push status ผ่าน API มาแสดง status page สาธารณะ
- ข้อดี — status page UI สวย professional, subscribe ผ่าน email/SMS/RSS, integrate กับ Opsgenie/PagerDuty/Jira, historical uptime report ย้อนหลัง
- ข้อเสีย — ไม่ได้ monitor เอง ต้อง integrate กับ tool อื่น, ราคาเริ่ม $29/month, component limit ใน plan เริ่มต้น
- เหมาะกับ — SaaS company ที่ต้องการ public status page ให้ customer ตรวจสอบได้
UptimeRobot (SaaS)
UptimeRobot เป็น SaaS ที่ได้รับความนิยมสูงเพราะมี free tier ที่ใช้งานได้จริง — free plan ให้ 50 monitor ตรวจสอบทุก 5 นาที พร้อม email alert ไม่จำกัด เหมาะกับ personal project หรือ small business
- ข้อดี — free tier ใจป้ำ, probe จาก 13 region, setup 5 นาที, public status page ฟรี
- ข้อเสีย — free tier ตรวจได้ทุก 5 นาทีเท่านั้น ไม่ realtime, advanced feature เช่น maintenance window, SSL monitor ต้องใช้ paid plan
- เหมาะกับ — personal website, blog, small project ที่ uptime requirement ไม่ strict มาก
Pingdom (SaaS, SolarWinds)
Pingdom เป็น SaaS ระดับ enterprise ที่มีมานานกว่า 15 ปี ให้บริการทั้ง uptime monitor, page speed test, transaction monitor (ทดสอบ login flow) และ real user monitoring
- ข้อดี — probe จาก 100+ location ทั่วโลก, interval ตั้งแต่ 1 นาที, reporting ละเอียด, integrate กับ tool อื่นได้เยอะ
- ข้อเสีย — ราคาสูง เริ่ม $15/month สำหรับ 10 check, ไม่มี free tier (trial 14 วันเท่านั้น)
- เหมาะกับ — e-commerce, enterprise ที่ต้องการ global coverage และ detail report
Gatus (Self-Hosted, Developer-focused)
Gatus เป็น open source tool ที่เน้น developer-friendly ใช้ YAML config ในการ define monitor แทน UI ทำให้ version control ได้ เหมาะกับทีมที่ใช้ GitOps หรือ Infrastructure as Code
# config.yaml - Gatus
endpoints:
- name: api-health
url: "https://api.example.com/health"
interval: 60s
conditions:
- "[STATUS] == 200"
- "[RESPONSE_TIME] < 500"
- "[BODY].status == UP"
alerts:
- type: slack
failure-threshold: 3
success-threshold: 2
- name: tcp-database
url: "tcp://db.example.com:5432"
interval: 30s
conditions:
- "[CONNECTED] == true"- ข้อดี — config as code, lightweight (Go binary), รองรับ condition ซับซ้อน (body, header, response time), Kubernetes-native
- ข้อเสีย — UI พื้นฐาน, ไม่มี multi-user, community เล็กกว่า Uptime Kuma
- เหมาะกับ — DevOps team ที่ชอบ declarative config, Kubernetes/GitOps workflow
Healthchecks.io (SaaS + Self-Hosted)
Healthchecks.io เป็น tool ที่ออกแบบเฉพาะสำหรับ monitor cron jobs และ scheduled tasks ไม่ใช่ web uptime — หลักการคือ job ต้อง “ping” endpoint ภายในเวลาที่กำหนด ถ้าไม่ ping จะ alert ทันที
# crontab entry
0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://hc-ping.com/uuid-here- ข้อดี — ฟรีและ open source สำหรับ self-hosted, free tier SaaS มี 20 check, รองรับ schedule แบบ cron expression, API-friendly
- ข้อเสีย — เฉพาะ scheduled task, ไม่ใช่ HTTP monitor ทั่วไป
- เหมาะกับ — monitor backup job, data pipeline, batch process
เปรียบเทียบแบบเคียงกัน
| Tool | Type | Free Tier | Probe Region | Config |
|---|---|---|---|---|
| Uptime Kuma | Self-hosted | ฟรี 100% | 1 (ที่ deploy) | Web UI |
| Gatus | Self-hosted | ฟรี 100% | 1 (ที่ deploy) | YAML |
| Healthchecks.io | Both | ฟรี/20 check | ไม่เกี่ยว | Web UI/API |
| UptimeRobot | SaaS | 50 check/5min | 13 | Web UI |
| Pingdom | SaaS | ไม่มี | 100+ | Web UI |
| Statuspage | SaaS | ไม่มี | – | API push |
คำแนะนำในการเลือก
- งบประมาณจำกัด + ทีมเล็ก — UptimeRobot free tier หรือ Uptime Kuma self-hosted
- Enterprise, SLA สำคัญ — Pingdom หรือ Datadog Synthetic สำหรับ global probe + detailed report
- DevOps team, config as code — Gatus + Git repo + CI/CD pipeline
- Backup/cron job monitor — Healthchecks.io
- Public status page — Statuspage หรือ Uptime Kuma status page (ฟรี)
Best Practices
- Monitor หลายจุด — อย่าใช้แค่ probe เดียว ถ้าเป็น self-hosted ให้ deploy 2-3 region
- Monitor the monitor — ใช้ external SaaS (UptimeRobot free) monitor ตัว self-hosted monitor อีกชั้น
- Threshold ต่างกัน — check ทุก 1 นาทีสำหรับ critical service, 5 นาทีสำหรับทั่วไป
- Alert ไม่ spam — ตั้ง retry 2-3 ครั้งก่อน fire alert เพื่อลด false positive จาก network glitch
- Secret management — ไม่ใส่ API token ใน URL ตรง ๆ ใช้ custom header แทน
- Maintenance window — mute alert ช่วง deploy/maintenance เพื่อไม่รบกวน oncall
สรุป
การเลือก uptime monitoring tool ไม่มีคำตอบเดียว ขึ้นอยู่กับ budget, ขนาดทีม, ความต้องการ global coverage, และ workflow ที่ใช้อยู่ ทีมส่วนใหญ่ที่เริ่มต้นใช้ Uptime Kuma self-hosted ได้ฟรี และเพิ่ม SaaS เมื่อโตขึ้นเพื่อ monitor ตัว self-hosted อีกชั้น การผสม self-hosted กับ SaaS เป็น pattern ที่ให้ทั้ง control และ resilience
สิ่งสำคัญกว่าการเลือก tool คือการตั้งค่าที่ถูกต้อง — interval ที่เหมาะสม, retry logic, alert threshold และ escalation path ที่ชัดเจน tool ไหนก็ใช้ได้ ถ้า team ให้เวลาปรับ config ให้เข้ากับ workflow ของทีมและ user พฤติกรรมของระบบ
