คู่มือ DigitalOcean Monitoring & Alerts 2026

A practical guide to DigitalOcean's free built-in Monitoring, Alert Policies, and Uptime Checks for developers running Droplets in production.

DigitalOcean มีระบบ Monitoring และ Alert Policy ให้ใช้ฟรีในตัวสำหรับทุก Droplet โดยไม่มีค่าใช้จ่ายเพิ่มเติม ครอบคลุมการเก็บ metric พื้นฐานอย่าง CPU, RAM, Disk และ Bandwidth พร้อม Uptime Check ฟรี 1 รายการต่อบัญชี บทความนี้อธิบายวิธีติดตั้งและตั้งค่าทั้งระบบแบบเป็นขั้นตอน รวมถึงจุดที่ควรระวังก่อนนำไปใช้กับงาน production จริง

Monitoring ในตัวฟรี เก็บอะไรบ้าง (CPU/RAM/Disk/Bandwidth)

DigitalOcean Monitoring เป็นฟีเจอร์ในตัวที่เปิดใช้งานได้ฟรีสำหรับทุก Droplet ไม่มีค่าใช้จ่ายเพิ่มไม่ว่าจะมี Droplet กี่ตัวก็ตาม ระบบจะเก็บ metric ระดับโครงสร้างพื้นฐาน (infrastructure-level) หลักๆ 4 กลุ่ม คือ การใช้งาน CPU (เปอร์เซ็นต์ของแต่ละ core), การใช้งาน Memory หรือ RAM, การใช้งานและ I/O ของ Disk รวมถึงพื้นที่ที่เหลือ และ Bandwidth ทั้งขาเข้า (inbound) และขาออก (outbound) เป็นหน่วย bit ต่อวินาที นอกจากนี้ยังมี Load Average ของระบบให้ดูประกอบด้วย ข้อมูลทั้งหมดแสดงเป็นกราฟย้อนหลังในหน้า Control Panel ของแต่ละ Droplet ภายใต้แท็บ Monitoring ทำให้เห็นแนวโน้มการใช้ทรัพยากรได้โดยไม่ต้อง SSH เข้าเครื่องแล้วรัน top หรือ htop ทุกครั้ง สิ่งสำคัญที่ต้องเข้าใจคือ Monitoring ของ DigitalOcean ไม่ใช่ observability stack แบบเต็มรูปแบบ มันไม่มี log aggregation, ไม่มี distributed tracing, ไม่มี APM สำหรับดู performance ระดับ application หรือ query database เจาะลึก มันตอบโจทย์แค่คำถามพื้นฐานว่า "เครื่องนี้กำลังใช้ทรัพยากรเท่าไหร่ และผิดปกติหรือไม่" ซึ่งเพียงพอสำหรับ Droplet ทั่วไปที่รันเว็บแอปหรือ API ขนาดกลาง แต่ถ้าต้องการดู latency ต่อ endpoint, error rate ต่อ route หรือ query ที่ช้าในฐานข้อมูล จำเป็นต้องใช้เครื่องมือเสริมแยกต่างหาก บาง metric อย่าง CPU, Disk I/O และ Bandwidth จะแสดงผลได้ทันทีจากระดับ hypervisor โดยไม่ต้องติดตั้งอะไรเพิ่ม แต่ metric ที่ละเอียดกว่านั้นอย่าง Memory usage ที่แม่นยำระดับ process จำเป็นต้องติดตั้ง Monitoring Agent ก่อน ซึ่งจะอธิบายในหัวข้อถัดไป

DigitalOcean Monitoring is a free built-in feature available for every Droplet at no extra cost, regardless of how many Droplets you have. The system collects four main infrastructure-level metrics: CPU usage (percentage per core), Memory/RAM usage, Disk usage and I/O (read/write), plus inbound and outbound Bandwidth (in bits per second). It also shows the system Load Average. All data appears as graphs in the Control Panel's Monitoring tab for each Droplet, letting you see resource trends without SSH-ing in and running top or htop every time. It's important to understand that DigitalOcean Monitoring is not a full observability stack — it lacks log aggregation, distributed tracing, and APM for application-level performance or database query analysis. It simply answers the basic question: "How much is this machine using, and is it abnormal?" This covers typical Droplets running small-to-medium web apps or APIs. To see endpoint latency, error rates per route, or slow database queries, you'll need separate tools. Some metrics like CPU, Disk I/O, and Bandwidth report instantly from the hypervisor without additional setup, but accurate Memory usage requires installing the Monitoring Agent, covered next.

• CPU usage แยกตาม core เป็นเปอร์เซ็นต์
• Memory (RAM) usage ต้องติดตั้ง Agent เพื่อความแม่นยำ
• Disk usage และ Disk I/O (read/write)

ติดตั้ง Monitoring Agent

จุดที่ผู้ใช้มักถามมาคือ มีสองวิธีในการติดตั้ง Monitoring Agent (do-agent) บน Droplet วิธีแรกและง่ายที่สุดคือติ๊กเลือกช่อง "Monitoring" ตอนสร้าง Droplet ใหม่ในหน้า Create Droplet ระบบจะติดตั้ง Agent ให้อัตโนมัติผ่าน cloud-init ตั้งแต่ตอน boot เครื่องครั้งแรก โดยไม่ต้องทำอะไรเพิ่มเติม เหมาะกับ Droplet ที่เพิ่งสร้างใหม่ทุกตัว วิธีที่สองสำหรับ Droplet ที่มีอยู่แล้วและยังไม่มี Agent คือติดตั้งด้วยมือผ่าน SSH โดยรันสคริปต์ติดตั้งอย่างเป็นทางการ เช่น curl -sSL https://repos.insights.digitalocean.com/install.sh | sudo bash ซึ่งจะเพิ่ม repository และติดตั้งแพ็กเกจ do-agent ให้ทำงานเป็น systemd service (คำสั่งอาจมีการปรับปรุงเป็นระยะ แนะนำให้ตรวจสอบ syntax ล่าสุดที่หน้า docs.digitalocean.com ก่อนรันจริงในระบบ production) หลังติดตั้งเสร็จตรวจสอบสถานะได้ด้วย sudo systemctl status do-agent ควรเห็นสถานะ active (running) หาก Agent ไม่ทำงานหรือ metric ไม่ขึ้นในหน้า Dashboard ให้ตรวจสอบ log ด้วย journalctl -u do-agent -n 50 Agent ทำงานแบบ outbound-only คือส่งข้อมูล metric ออกไปหา endpoint ของ DigitalOcean ผ่าน HTTPS พอร์ต 443 เท่านั้น ไม่ได้เปิดพอร์ตรับการเชื่อมต่อเข้ามาที่ Droplet ดังนั้นโดยทั่วไปไม่ต้องแก้ไขกฎ Cloud Firewall เพิ่มเติมสำหรับ inbound แต่ถ้า Droplet ตั้งกฎ outbound แบบจำกัด (default deny) ต้องเปิดให้ outbound HTTPS ผ่านได้ก่อน Agent ถึงจะรายงานข้อมูลได้ตามปกติ สำหรับ Droplet ที่ใช้ Image แบบ custom หรือ minimal บาง distro อาจไม่รองรับสคริปต์ติดตั้งอัตโนมัติ ต้องเช็ค compatibility list ในเอกสารทางการก่อนเสมอ

• วิธีง่ายสุด: ติ๊กช่อง Monitoring ตอนสร้าง Droplet
• วิธีติดตั้งเอง: รันสคริปต์ install.sh ผ่าน SSH บน Droplet เดิม
• เช็คสถานะด้วย systemctl status do-agent
• Agent ส่งข้อมูลแบบ outbound HTTPS เท่านั้น ไม่ต้องเปิด inbound port

สร้าง Alert Policy แจ้งเตือนผ่าน Email/Slack

Alert Policy คือกฎที่กำหนดว่าเมื่อ metric ใดค่าหนึ่งเกินเกณฑ์ที่ตั้งไว้ต่อเนื่องเป็นระยะเวลาหนึ่ง ให้ส่งการแจ้งเตือนออกไปยังช่องทางที่กำหนด สร้างได้จากเมนู Monitoring ในหน้า Control Panel แล้วเลือก Alert Policies จากนั้นกด Create Alert Policy ขั้นตอนหลักมีสี่ส่วน หนึ่งคือเลือก metric ที่จะเฝ้าดู เช่น CPU utilization, Memory utilization, Disk utilization, หรือ Bandwidth สองคือกำหนด threshold และระยะเวลา เช่น "CPU utilization สูงกว่า 80% ต่อเนื่อง 5 นาที" ระบบจะไม่แจ้งเตือนทันทีที่ค่าพุ่งชั่วขณะ แต่รอให้ค่าคงอยู่เกินเกณฑ์ตามระยะเวลาที่กำหนดก่อน ช่วยลดการแจ้งเตือนเท็จจาก traffic spike สั้นๆ สามคือเลือก Droplet เป้าหมาย ซึ่งเลือกได้ทั้งแบบระบุทีละตัวหรือใช้ Tag เพื่อให้ Alert Policy ครอบคลุม Droplet ทุกตัวที่มี Tag เดียวกันโดยอัตโนมัติ วิธีนี้สะดวกมากเมื่อมี Droplet จำนวนมากหรือมีการสร้าง/ลบ Droplet บ่อยผ่าน autoscaling หรือ automation เพราะไม่ต้องมาตั้ง policy ใหม่ทุกครั้งที่เพิ่มเครื่อง สี่คือเลือกช่องทางแจ้งเตือน ซึ่งรองรับ Email (ส่งไปยังอีเมลของบัญชีหรือ Team member ที่กำหนด) และ Slack ผ่านการเชื่อมต่อ Slack App เข้ากับ workspace โดยต้อง authorize สิทธิ์ให้ DigitalOcean โพสต์ข้อความเข้า channel ที่เลือกไว้ล่วงหน้าในหน้า Integrations หลังเชื่อมต่อสำเร็จ ทุก Alert Policy ที่เลือกช่องทาง Slack จะสามารถส่งข้อความเข้า channel นั้นได้ทันทีที่ metric เกิน threshold และจะส่งอีกครั้งเมื่อค่ากลับเข้าสู่ระดับปกติ (resolved) ทำให้ทีมรู้ทั้งจุดเริ่มและจุดจบของปัญหา

1. เลือก metric: CPU / Memory / Disk / Bandwidth
2. ตั้ง threshold และระยะเวลาที่ต้องเกินต่อเนื่อง เช่น 80% นาน 5 นาที
3. ผูก Alert Policy กับ Droplet เดี่ยวหรือทั้งกลุ่มผ่าน Tag

Uptime Check ฟรี 1 รายการต่อบัญชี

นอกจาก metric ระดับ Droplet แล้ว DigitalOcean ยังมีฟีเจอร์ Uptime Check ให้ใช้งานฟรี 1 รายการต่อบัญชี ทำหน้าที่ยิง request ไปยัง URL ที่กำหนด (HTTP หรือ HTTPS) จากหลายจุดตรวจสอบทั่วโลกเป็นระยะ เพื่อดูว่าเว็บไซต์หรือ API endpoint นั้นยังตอบสนองอยู่หรือไม่ พร้อมวัด response time ประกอบ ต่างจาก Monitoring ที่ดูทรัพยากรภายในเครื่อง Uptime Check ดูจากมุมมองภายนอกเหมือนผู้ใช้จริงเข้าเว็บ จึงช่วยจับปัญหาที่ Monitoring ภายในมองไม่เห็น เช่น DNS ผิดพลาด, SSL certificate หมดอายุ, หรือ Load Balancer front ล้มแต่ Droplet เบื้องหลังยังทำงานปกติ วิธีสร้างคือเข้าเมนู Monitoring แล้วเลือกแท็บ Uptime จากนั้นกด Create Check ใส่ URL ที่ต้องการตรวจสอบ เลือกภูมิภาคจุดตรวจ (check location) ที่ต้องการ และตั้งความถี่ในการตรวจ เมื่อสร้างแล้วสามารถผูก Alert Policy เข้ากับ Uptime Check นี้ได้เช่นเดียวกับ Droplet metric โดยเลือกเงื่อนไข เช่น down status หรือ response time สูงเกินกำหนด แล้วส่งแจ้งเตือนผ่าน Email หรือ Slack เช่นกัน ข้อจำกัดสำคัญที่ต้องรู้คือบัญชีหนึ่งได้ Uptime Check ฟรีเพียง 1 รายการเท่านั้น หากมีเว็บไซต์หรือ endpoint มากกว่าหนึ่งที่ต้องการเฝ้าดูสถานะจากภายนอก จำเป็นต้องพิจารณาใช้เครื่องมือเสริมเพิ่มเติม ซึ่งจะกล่าวถึงในหัวข้อถัดไป การมี Uptime Check แม้เพียง 1 รายการก็ยังดีกว่าไม่มีเลย ควรผูกไว้กับ endpoint ที่สำคัญที่สุดของระบบ เช่น หน้าแรกของเว็บหรือ health check endpoint ของ API หลัก

• ฟรี 1 Uptime Check ต่อบัญชี ตรวจจาก external location จริง
• วัดทั้งสถานะ up/down และ response time
• ตั้งค่าที่เมนู Monitoring > Uptime > Create Check
• ผูก Alert Policy กับ Uptime Check ได้เหมือน metric ของ Droplet
• เกิน 1 endpoint ต้องพึ่งเครื่องมือภายนอกเสริม

เชื่อมต่อกับเครื่องมือ Monitoring ภายนอก

จุดที่ผู้ใช้มักถามมาคือ เมื่อ Monitoring ในตัวของ DigitalOcean ไม่พอสำหรับความต้องการที่ซับซ้อนขึ้น เช่น ต้องการ log aggregation, ต้องการ Uptime Check มากกว่า 1 endpoint, หรือต้องการ dashboard ที่ปรับแต่งได้อิสระ มีทางเลือกหลายแบบให้เชื่อมต่อเพิ่ม แนวทางที่นิยมในหมู่ developer คือติดตั้ง Prometheus บน Droplet แยกต่างหาก แล้วใช้ node_exporter รันบน Droplet เป้าหมายเพื่อ expose metric ระดับระบบให้ Prometheus ดึงไปเก็บ จากนั้นต่อ Grafana เข้ามาทำ dashboard และตั้ง alert rule ได้ละเอียดกว่า Alert Policy พื้นฐานมาก วิธีนี้ต้องดูแลเซิร์ฟเวอร์เพิ่มเองแต่ควบคุมได้เต็มที่และไม่เสียค่าบริการรายเดือนเพิ่ม อีกทางเลือกคือใช้ agent ของบริการ SaaS อย่าง Datadog หรือ New Relic ซึ่งติดตั้ง agent บน Droplet คล้ายกับ do-agent แต่ให้ฟีเจอร์ครบกว่ามาก ทั้ง APM, log management, distributed tracing โดยมีค่าใช้จ่ายตามแผนของผู้ให้บริการนั้นๆ ซึ่งแยกต่างหากจากค่า DigitalOcean เอง สำหรับใครที่ต้องการ Uptime Check หลาย endpoint โดยไม่เสียค่าใช้จ่ายเพิ่ม ทางเลือกที่ได้รับความนิยมคือ self-host Uptime Kuma บน Droplet เล็กๆ ตัวหนึ่ง ซึ่งทำหน้าที่คล้าย Uptime Check ของ DigitalOcean แต่ตรวจได้หลาย endpoint ไม่จำกัด พร้อมมี Status Page สาธารณะให้ลูกค้าหรือทีมดูได้ นอกจากนี้ DigitalOcean ยังเปิด Metrics API ให้ดึงข้อมูล metric ดิบออกไปประมวลผลเองในระบบภายนอกได้ผ่าน Personal Access Token เหมาะสำหรับทีมที่มี dashboard กลางของตัวเองอยู่แล้วและต้องการรวมข้อมูลจาก DigitalOcean เข้าไปในที่เดียวกับ infrastructure อื่น

• Prometheus + node_exporter + Grafana สำหรับ dashboard และ alert ที่ปรับแต่งได้เต็มที่
• Datadog / New Relic agent สำหรับ APM และ log management ครบวงจร (มีค่าบริการแยกจาก DO)
• Self-host Uptime Kuma เพื่อเพิ่มจำนวน endpoint ที่ตรวจสอบได้เกิน 1 รายการฟรี
• DigitalOcean Metrics API ดึง metric ดิบไปรวมกับ dashboard กลางขององค์กร

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

Monitoring และ Alert Policy ในตัวของ DigitalOcean เหมาะที่สุดกับสถานการณ์ที่ต้องการการมองเห็น (visibility) ขั้นพื้นฐานโดยไม่อยากเพิ่มค่าใช้จ่ายหรือความซับซ้อนของระบบ กลุ่มแรกคือนักพัฒนาเดี่ยวหรือทีมเล็กที่รัน Droplet ไม่กี่ตัวสำหรับโปรเจกต์ side project หรือ MVP การเปิด Monitoring ฟรีพร้อม Alert Policy แจ้งเตือนเมื่อ CPU หรือ Disk ใกล้เต็ม ช่วยให้รู้ล่วงหน้าก่อนเว็บล่มโดยไม่ต้องลงทุนกับเครื่องมือ enterprise กลุ่มที่สองคือเอเจนซี่หรือ freelance ที่ดูแล Droplet ของลูกค้าหลายราย การใช้ Tag ผูกกับ Alert Policy ทำให้ตั้งกฎแจ้งเตือนครั้งเดียวครอบคลุมทุกเครื่องของลูกค้ากลุ่มเดียวกัน ลดงานตั้งค่าซ้ำซ้อนเมื่อรับลูกค้าใหม่หรือขยาย Droplet เพิ่ม กลุ่มที่สามคือสตาร์ทอัพช่วงเริ่มต้นที่ยังไม่พร้อมลงทุนกับ observability stack เต็มรูปแบบ การใช้ Monitoring ฟรีของ DigitalOcean ร่วมกับ Uptime Check 1 endpoint สำหรับหน้าแรกหรือ API หลัก เป็นจุดเริ่มต้นที่สมเหตุสมผลก่อนจะขยับไปใช้เครื่องมือที่ซับซ้อนกว่าเมื่อระบบโตขึ้น กลุ่มสุดท้ายคือทีมที่ใช้ Load Balancer กระจายโหลดไปหลาย Droplet อยู่แล้ว การตั้ง Alert Policy ตาม Tag ของกลุ่ม Droplet หลัง Load Balancer ช่วยให้รู้ทันทีเมื่อมี Droplet ตัวใดตัวหนึ่งเริ่มมีปัญหาก่อนที่ Load Balancer จะตัดออกจาก pool ทำให้ทีมเข้าไปแก้ไขได้ทันเวลา แทนที่จะรู้ทีหลังจากลูกค้าแจ้งเข้ามาเอง

• โปรเจกต์เดี่ยว/MVP ที่ต้องการแจ้งเตือนพื้นฐานโดยไม่มีค่าใช้จ่ายเพิ่ม
• เอเจนซี่ดูแล Droplet ลูกค้าหลายรายผ่าน Tag เดียวกัน
• สตาร์ทอัพช่วงต้นที่ยังไม่พร้อมลงทุน observability stack เต็มรูปแบบ

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

จากการรีวิวหลายรอบ ข้อผิดพลาดที่พบบ่อยที่สุดคือลืมติดตั้ง Monitoring Agent บน Droplet ที่สร้างไว้ก่อนหน้าที่ยังไม่มี Agent แล้วสงสัยว่าทำไม Memory usage ไม่ขึ้นในกราฟหรือขึ้นเป็นค่าว่าง วิธีแก้คือตรวจสอบสถานะ Agent ด้วย systemctl status do-agent ก่อนเสมอ หากยังไม่มีให้ติดตั้งเพิ่มตามขั้นตอนในหัวข้อก่อนหน้า ข้อผิดพลาดที่สองคือตั้ง threshold ของ Alert Policy เข้มงวดเกินไป เช่น CPU เกิน 50% ก็แจ้งเตือนทันที ทำให้เกิด alert fatigue คือแจ้งเตือนถี่จนทีมเริ่มเพิกเฉยและพลาดแจ้งเตือนที่สำคัญจริงๆ ไปด้วย วิธีแก้คือสังเกต baseline การใช้งานจริงของ Droplet สัก 1-2 สัปดาห์ก่อน แล้วตั้ง threshold ให้สูงกว่าค่าปกติพอสมควรพร้อมกำหนดระยะเวลาต่อเนื่องที่เหมาะสม ไม่ใช่แจ้งทันทีที่ค่าพุ่งชั่วขณะ ข้อผิดพลาดที่สามคือเข้าใจผิดว่า Uptime Check ฟรีครอบคลุมทุกเว็บไซต์หรือทุก endpoint ที่มี ทั้งที่จริงมีให้แค่ 1 รายการต่อบัญชี ทำให้เกิดจุดบอดที่ไม่มีใครรู้เมื่อ endpoint อื่นล่ม ต้องวางแผนเสริมด้วยเครื่องมือภายนอกตั้งแต่ต้นถ้ามีมากกว่า 1 endpoint ที่สำคัญ ข้อผิดพลาดที่สี่คือสร้าง Alert Policy เสร็จแล้วแต่ไม่ได้เลือกช่องทางแจ้งเตือนให้ครบ หรือเชื่อม Slack ไว้แต่ channel ถูกลบหรือ archive ไปภายหลังโดยไม่มีใครสังเกต ทำให้ Alert Policy "เงียบ" ทั้งที่ยังทำงานอยู่ ควรทดสอบส่งแจ้งเตือนจริงอย่างน้อยครั้งหนึ่งหลังตั้งค่าเสร็จ และข้อผิดพลาดสุดท้ายคือไม่ใช้ Tag เลย ทำให้ต้องตั้ง Alert Policy ซ้ำทุกครั้งที่เพิ่ม Droplet ใหม่ ซึ่งมักถูกลืมเมื่อทีมงานยุ่งหรือใช้ automation สร้าง Droplet อัตโนมัติ

• ลืมติดตั้ง Agent ทำให้ Memory metric ไม่แสดงผล — เช็คด้วย systemctl status do-agent
• Threshold เข้มงวดเกินไปจนเกิด alert fatigue — สังเกต baseline ก่อนตั้งค่า
• เข้าใจผิดว่า Uptime Check ฟรีครอบคลุมทุก endpoint ทั้งที่มีแค่ 1 รายการ
• ตั้ง Alert Policy แต่ช่องทางแจ้งเตือนใช้ไม่ได้จริง (Slack channel ถูกลบ) — ต้องทดสอบยิงจริง

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

แนวทางแรกคือติ๊กเปิด Monitoring ทุกครั้งตั้งแต่ตอนสร้าง Droplet ใหม่ เพราะไม่มีค่าใช้จ่ายเพิ่มและไม่ต้องมาติดตั้งย้อนหลังทีหลัง ควรทำให้เป็น default habit ของทุกทีม แนวทางที่สองคือวางระบบ Tag ให้เป็นมาตรฐานตั้งแต่ต้น เช่น แยกตาม environment (prod/staging) และตาม role (web/db/worker) แล้วผูก Alert Policy เข้ากับ Tag แทนการเลือก Droplet ทีละตัว เพื่อให้ Droplet ใหม่ที่สร้างขึ้นภายหลังถูกครอบคลุมโดยอัตโนมัติทันทีที่ติด Tag เดียวกัน แนวทางที่สามคือตั้ง threshold บนพื้นฐานข้อมูลจริงที่สังเกตได้ ไม่ใช่ตัวเลขที่เดาเอาเอง และทบทวน Alert Policy ทุกครั้งที่ Droplet เปลี่ยนขนาดหรือ workload เปลี่ยนไปอย่างมีนัยสำคัญ แนวทางที่สี่คือใช้ Uptime Check ฟรี 1 รายการกับ endpoint ที่สำคัญที่สุดเสมอ เช่น health check endpoint กลางที่สะท้อนสถานะรวมของระบบ แล้วเสริมด้วย self-host Uptime Kuma หรือเครื่องมือภายนอกสำหรับ endpoint รองอื่นๆ แนวทางที่ห้าคืออย่าพึ่งพา Monitoring ในตัวเพียงอย่างเดียวสำหรับระบบ production ที่มีความสำคัญสูง ควรพิจารณาเสริม Prometheus/Grafana หรือ SaaS observability tool เมื่อระบบโตถึงจุดที่ต้องการ log analysis และ tracing ระดับลึก แนวทางสุดท้ายคือทดสอบ Alert Policy จริงอย่างน้อยหนึ่งครั้งหลังตั้งค่า เช่น จำลอง CPU สูงด้วยเครื่องมือทดสอบ เพื่อให้แน่ใจว่าการแจ้งเตือนไปถึงช่องทางที่ตั้งไว้จริง ทั้งหมดนี้ควรทำควบคู่กับการตรวจสอบราคาและเงื่อนไขล่าสุดที่เว็บไซต์ทางการของ DigitalOcean เสมอ เนื่องจากข้อมูลในบทความนี้อ้างอิง ณ เดือนกรกฎาคม 2026

• เปิด Monitoring ทุกครั้งตอนสร้าง Droplet เป็นค่าเริ่มต้น
• วางมาตรฐาน Tag ตั้งแต่ต้นเพื่อให้ Alert Policy ครอบคลุม Droplet ใหม่อัตโนมัติ
• ตั้ง threshold จาก baseline จริง ไม่ใช่ตัวเลขเดา และทบทวนเป็นระยะ
• ใช้ Uptime Check ฟรีกับ endpoint สำคัญที่สุด เสริมด้วย Uptime Kuma สำหรับ endpoint อื่น

รับ $200 Free Credit →