DigitalOcean Monitoring & Alerts Guide 2026

DigitalOcean มีระบบ Monitoring และ Alert Policy ให้ใช้ฟรีในตัวสำหรับทุก Droplet โดยไม่มีค่าใช้จ่ายเพิ่มเติม

DigitalOcean provides free built-in Monitoring and Alert Policy features for every Droplet at no additional cost. These cover basic infrastructure metrics like CPU, RAM, Disk, and Bandwidth, plus one free Uptime Check per account. This guide walks through setup and configuration step by step, including key considerations for production workloads.

Free Built-in Monitoring — What It Tracks (CPU/RAM/Disk/Bandwidth)

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 per core as a percentage
• Memory (RAM) usage requires Agent for accuracy
• Disk usage and Disk I/O (read/write)

Installing the Monitoring Agent

A point users often miss: there are two ways to install the Monitoring Agent (do-agent) on a Droplet. The easiest is to check the "Monitoring" box when creating a new Droplet in Create Droplet — it installs automatically via cloud-init on first boot with no extra steps. This works best for any new Droplet. For existing Droplets without an Agent, install manually via SSH using the official install script, such as curl -sSL https://repos.insights.digitalocean.com/install.sh | sudo bash (the command may be updated periodically; check docs.digitalocean.com for the latest syntax before running on production). After installation, verify status with sudo systemctl status do-agent — you should see active (running). If the Agent won't start or metrics don't appear, check logs with journalctl -u do-agent -n 50. The Agent sends data outbound-only via HTTPS port 443 to DigitalOcean endpoints; it doesn't open any inbound ports on your Droplet, so you typically don't need to adjust Cloud Firewall inbound rules. However, if your Droplet restricts outbound by default (deny-all), you must allow outbound HTTPS first. Custom or minimal images may not support the automatic install script — always check the compatibility list in the official docs beforehand.

• Easiest: check Monitoring when creating a new Droplet
• Manual install: run install.sh via SSH on existing Droplets
• Check status with systemctl status do-agent
• Agent sends outbound HTTPS only; no inbound port changes needed

Creating Alert Policies for Email/Slack Notifications

An Alert Policy is a rule that sends a notification when a metric exceeds a threshold for a set duration. Create one from Monitoring > Alert Policies > Create Alert Policy in the Control Panel. There are four main steps. First, choose the metric to watch: CPU utilization, Memory utilization, Disk utilization, or Bandwidth. Second, set the threshold and duration — for example, "CPU over 80% for 5 minutes continuous." The system won't alert on brief spikes; it waits for the threshold to hold for the duration you specify, reducing false alarms from short traffic bursts. Third, select target Droplets by individual instance or by Tag to automatically cover all tagged Droplets, which is convenient for large fleets or auto-scaling since you don't re-configure when adding machines. Fourth, choose notification channels: Email (to account owner or Team members) or Slack (after connecting a Slack workspace in Integrations and granting authorization). Once connected, any Alert Policy choosing Slack will post to that channel when the metric exceeds the threshold and again when it resolves, keeping the team informed of both the start and end of an issue.

1. Choose metric: CPU / Memory / Disk / Bandwidth
2. Set threshold and minimum duration, e.g., 80% for 5 minutes
3. Assign Alert Policy to individual Droplets or Tag all related ones

Free Uptime Check — 1 per Account

Beyond Droplet metrics, DigitalOcean offers one free Uptime Check per account. It pings a specified URL (HTTP or HTTPS) from multiple check locations worldwide on a schedule to confirm your site or API endpoint is responding and measures response time. Unlike Monitoring, which views resources inside the machine, Uptime Check views from outside, like a real user visiting the site — it catches problems Monitoring can't, such as DNS failure, expired SSL certificates, or a Load Balancer up but backend Droplets down. Create one at Monitoring > Uptime > Create Check. Enter the URL to check, choose check locations, and set check frequency. After creation, link an Alert Policy to the Uptime Check by selecting conditions like down status or high response time, then send alerts via Email or Slack, just as with Droplet metrics. The key limitation is one free Uptime Check per account. If you need to monitor multiple endpoints or critical services, explore additional tools covered next. Even one Uptime Check is valuable — bind it to your most critical endpoint, such as a homepage or main API health check.

• 1 free Uptime Check per account; monitors from external global locations
• Measures both up/down status and response time
• Configure at Monitoring > Uptime > Create Check
• Link Alert Policies to Uptime Checks the same way as Droplet metrics
• For multiple endpoints, supplement with external tools

Integrating External Monitoring Tools

A point users often miss: when DigitalOcean's built-in Monitoring isn't enough — needing log aggregation, more than 1 Uptime Check, or a fully customizable dashboard — several options exist. A popular developer approach is to self-host Prometheus on a separate Droplet, run node_exporter on target Droplets to expose system metrics for Prometheus to scrape, then attach Grafana for dashboards and detailed alert rules — far more flexible than the basic Alert Policy but requires managing an extra server at no recurring cost. Alternatively, use a SaaS agent like Datadog or New Relic, which installs similarly to do-agent but covers APM, log management, and distributed tracing at the vendor's monthly cost (separate from DigitalOcean fees). For multiple Uptime Checks without extra cost, self-host Uptime Kuma on a small Droplet — it monitors as many endpoints as you need and includes a public Status Page. DigitalOcean also exposes a Metrics API; use your Personal Access Token to pull raw metrics into an external system if you already have a central dashboard and want to integrate DigitalOcean data alongside other infrastructure.

• Prometheus + node_exporter + Grafana for fully customizable dashboards and alerts
• Datadog / New Relic agents for complete APM, logging, and tracing (separate fees)
• Self-host Uptime Kuma to monitor unlimited endpoints free
• DigitalOcean Metrics API to pull raw data into your central dashboard

When to Use This Feature (Real Use Cases)

DigitalOcean's built-in Monitoring and Alert Policy work best when you want basic infrastructure visibility without added cost or complexity. First use case: solo developers or small teams running a few Droplets for side projects or MVPs. Enabling free Monitoring with Alert Policies for CPU or Disk near-full warns you before downtime without enterprise tool investment. Second: agencies managing many customer Droplets. Using Tags with Alert Policies lets you configure once and cover all related machines automatically, reducing duplicate setup when you onboard new customers or expand. Third: early-stage startups not yet ready for full observability stacks. Free Monitoring plus one Uptime Check on your main endpoint is a sensible start before adopting complex tools as you grow. Fourth: teams using a Load Balancer across multiple Droplets. Alert Policies tagged per backend group let you catch a failing machine before the Load Balancer sheds it, enabling faster fixes than waiting for customer reports. Fifth: tracking Disk usage before the filesystem fills and crashes the system. All these scenarios benefit from no-cost baseline monitoring.

• Solo projects / MVPs needing basic alerts without cost
• Agencies managing multiple customer Droplets via Tags
• Early-stage startups not yet ready for full observability platforms

Common Mistakes and Fixes

From multiple reviews, the most frequent mistake is forgetting to install the Monitoring Agent on an existing Droplet, then wondering why Memory metrics don't appear or show blank. Always verify with systemctl status do-agent first; if absent, install per the earlier section. Second: setting Alert Policy thresholds too tight, such as CPU over 50%, causing alert fatigue — so many false alarms that the team ignores actual problems. Fix: observe real baseline usage for 1–2 weeks, then set thresholds meaningfully above normal peaks, not instant on any spike. Third: misunderstanding that the free Uptime Check covers all your endpoints when it only covers one per account, leaving blind spots when other endpoints fail. Plan for backup monitoring tools from the start if you have multiple critical endpoints. Fourth: creating an Alert Policy but not fully configuring the notification channel or connecting Slack correctly, or a Slack channel later being deleted or archived without notice — the Policy "silent" even though it runs. Test notifications by triggering one manually at least once after setup. Fifth: skipping Tags entirely, forcing you to re-configure Alert Policies for every new Droplet, which gets forgotten when teams are busy or automation creates instances.

• Forgot Agent install — Memory metrics missing — check systemctl status do-agent first
• Thresholds too tight → alert fatigue — baseline measurement before tuning
• Misthinking free Uptime Check covers all endpoints when only 1 allowed
• Alert Policy created but notification channel broken or Slack channel deleted — test real send

Best Practices

First: enable Monitoring every time you create a new Droplet as a default habit — it costs nothing and avoids retrofit installations. Second: standardize Tags early (prod/staging by environment, web/db/worker by role) and bind Alert Policies to Tags, not individual Droplets, so new instances auto-inherit alerts the moment they receive the same Tag. Third: set thresholds from real observations, not guesses, and revisit them whenever a Droplet size or workload changes significantly. Fourth: dedicate your one free Uptime Check to the single most critical endpoint, such as a central health check endpoint reflecting overall system state, then supplement with self-hosted Uptime Kuma or external tools for secondary endpoints. Fifth: don't rely on Monitoring alone for high-stakes production systems — add Prometheus/Grafana or a SaaS observability service once your system needs deep log analysis and request tracing. Finally: test at least one Alert Policy manually after setup (e.g., simulate high CPU) to confirm notifications reach their intended channels. Keep this aligned with current DigitalOcean pricing and terms, as of July 2026.

• Enable Monitoring on every new Droplet as default practice
• Standardize Tags early; bind Alert Policies to Tags, not individual Droplets
• Set thresholds from real baseline; revisit when Droplet size or workload changes
• Use your 1 free Uptime Check on the most critical endpoint; supplement with Uptime Kuma for others

Get $200 Free Credit →