Server Monitoring for Web Agencies: CPU, Memory, Disk, Network, and Containers

July 12, 2026 · 4 min read

A website can be online while the server is running out of room to stay online.

Disk is at 94%. Memory is swapping. One container restarts every hour. Backups are filling the filesystem. The public page still returns 200 — until it does not.

Server monitoring gives an agency time to act before resource pressure becomes a client-visible outage.

Start with the customer symptom

Internal metrics are useful because they explain or predict external impact.

The correct hierarchy is:

1. Is the website or critical path affected?
2. Which server resource explains the symptom?
3. Is human action required now?

Do not page a developer because CPU briefly reached 90% while the site remained fast. Alert when a sustained condition threatens availability, latency, data, or recovery.

CPU

Watch:

• sustained utilization;
• load relative to available cores;
• steal time on virtual machines;
• per-container consumption;
• correlation with response latency.

Short spikes are normal. A persistent queue with rising latency is actionable.

Questions:

• Did traffic increase?
• Is a scheduled job running?
• Did a deployment change application behavior?
• Is one process or container responsible?
• Is the host undersized or the application inefficient?

Memory

Watch:

• used memory;
• available memory;
• swap activity;
• out-of-memory kills;
• container limits;
• application restart patterns.

"95% memory used" can be misleading on systems that use free memory for cache. Focus on available memory, swapping, OOM events, and application behavior.

Disk

Disk exhaustion is one of the most preventable outages.

Watch:

• filesystem free space;
• growth rate;
• inode exhaustion;
• I/O latency;
• backup and log directories;
• container volumes.

Alert on time to exhaustion, not only a static percentage. A disk growing 5 GB per hour at 80% is more urgent than a stable archive volume at 90%.

Network

Watch:

• throughput;
• packet loss;
• connection errors;
• DNS behavior;
• regional reachability;
• traffic changes;
• interface saturation.

An internal network graph cannot prove the public website is reachable. Pair it with external checks from more than one region.

Containers

Docker exposes CPU, memory, network I/O, block I/O, and process counts through runtime metrics. Useful signals include:

• restart count;
• exited containers;
• health-check state;
• CPU and memory against limits;
• volume usage;
• network errors;
• dependency availability.

Container metrics need service context. "Container exited" is critical for a single-instance web application and harmless for a completed one-off job.

Thresholds without noise

Use three levels:

Information

Visible in the dashboard and report; no action.

Warning

Capacity or reliability trend needs planned work:

• disk forecast to fill in 14 days;
• memory pressure increasing;
• repeated container restarts;
• sustained latency above baseline.

Critical

Current or imminent user impact:

• filesystem nearly full with rapid growth;
• OOM kills affecting the application;
• critical container unavailable;
• resource pressure correlated with failed external checks.

Set thresholds per server role. A database, web node, backup host, and development VM should not share one template blindly.

Agent security

A monitoring agent should use outbound requests only. That avoids opening a public metrics port on every client server.

Also require:

• authenticated transport;
• scoped organization and host identity;
• revocable credentials;
• minimal data collection;
• no secrets or process arguments in logs;
• clear update mechanism;
• freshness monitoring.

If the agent stops reporting, the dashboard should say data is stale. Last week's green value is not today's health.

Connect internal metrics to the client report

The client does not need a CPU chart unless it explains a decision.

Good:

Server disk usage reached the warning threshold because backup retention was misconfigured. Old archives were removed, retention was corrected, and free space returned to 61%.

Weak:

Average disk usage: 72.4%.

The report should communicate impact, action, and remaining risk.

A minimum agency dashboard

For each host:

• availability and last agent heartbeat;
• CPU and load;
• available memory and swap;
• disk free space, inodes, and forecast;
• network errors and throughput;
• container state and restarts;
• linked client websites;
• active incidents;
• owner and escalation route.

The linked websites matter. When one host fails, the agency should see the affected client services immediately.

Frequently asked questions

Do agencies need Prometheus to monitor servers?

Not necessarily. Prometheus is powerful, but smaller agencies may prefer a managed agent and portfolio dashboard. The principles of actionable metrics and external verification remain the same.

How often should server metrics be collected?

Frequent enough to catch meaningful changes without excessive cost. One-minute collection is common for operational signals; capacity planning can use longer aggregation.

Is server monitoring a replacement for website monitoring?

No. Internal metrics may look healthy while DNS, TLS, CDN, routing, or the application path fails for visitors.

Sources

• Prometheus Node Exporter guide
• Docker runtime metrics
• Docker container stats reference
• Prometheus alerting practices

Read next: WordPress health from the inside and monitor 50 client websites without alert fatigue.