---
title: Server Monitoring for Web Agencies — CPU, Memory, Disk, Network, and Containers
description: A practical server-monitoring guide for agencies — CPU, memory, disk, network, containers, actionable thresholds, external verification, and client reporting.
source: https://pingvera.com/blog/server-monitoring-web-agencies.html
---
# Server Monitoring for Web Agencies: CPU, Memory, Disk, Network, and Containers

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](https://prometheus.io/docs/guides/node-exporter/)
- [Docker runtime metrics](https://docs.docker.com/engine/containers/runmetrics/)
- [Docker container stats reference](https://docs.docker.com/reference/cli/docker/container/stats/)
- [Prometheus alerting practices](https://prometheus.io/docs/practices/alerting/)