SNMP Monitoring for Web Hosting: A Practical Case Study

By the SNMP Monitoring team · Reviewed July 2026

To make the abstract concrete, picture an illustrative hosting provider — call it a dozen Linux web and database servers behind a couple of switches, serving customer sites. The figures throughout this case study are examples to show the shape of the problem, not real customer data. What sinks a hosting operation isn't usually the dramatic failure; it's the mundane one that nobody was watching. A disk quietly fills until the web server can't write a session file and every site 500s. A load spike from one runaway account drags response times across a shared box. A server reboots at 3 a.m. and nobody notices the four minutes of downtime. SNMP catches all three cheaply, from one protocol, across the whole fleet — and this walkthrough shows exactly which metrics, thresholds, and follow-through turn "SNMP is on" into "we caught it before the customer did."

Parent: guides. Related: disk-space monitoring, system load, Linux SNMP.

The monitoring goals

For a hosting fleet, three failure modes cause most of the pain, and each maps to a metric:

• Prevent disk-full outages — a full disk is the single most common cause of a "site down" ticket; catch it while there's still time to clear space.
• Catch load spikes early — sustained high load means slow sites for every customer on a shared server, often before anything actually errors.
• Confirm uptime and catch silent reboots — a server that rebooted and came back looks "up" now, but the reboot itself may have dropped connections or signalled a deeper problem.

Get those three watched reliably and you've covered the incidents that generate the most support load. Everything else — interfaces, memory — is useful, but these three are where the tickets come from.

What to monitor and why

Here's the core metric set, the OID behind each, an illustrative threshold, and what it catches:

The thresholds are starting points, not gospel — a database box's load ceiling differs from a static-content server's. Disk usage is computed from used ÷ size × 100 (disk-space monitoring); load comes from the UCD laLoad objects (system load); the uptime value dropping between polls is your reboot signal (uptime monitoring). All of it reads the same way across every Linux server in the fleet, which is the whole appeal.

Setting it up

Standing this up on the illustrative fleet is the standard flow:

1. Install and secure an agent on each server — Net-SNMP with a random read-only community or SNMPv3, an OID allowlist, and no internet exposure (see setup and Linux SNMP).
2. Scope the firewall so only the monitoring host can reach UDP 161 on each server.
3. Verify each agent answers a basic snmpwalk system before wiring it in.
4. Point a poller at the fleet, collecting the metric set above on a short interval.
5. Set thresholds and alerts on disk, load, CPU, and the uptime-drop signal.

Because every server exposes the same standard OIDs, one polling template and one alert template cover the whole fleet — add a server and it inherits the same monitoring.

An incident walkthrough

Here's how it plays out. One shared web server starts accumulating log and session files faster than logrotate clears them. The poller reads disk usage each cycle and, one afternoon, it crosses the line:

snmpget -v2c -c S3cr3tR0str1ng 10.0.0.20 \
  1.3.6.1.2.1.25.2.3.1.6.31 1.3.6.1.2.1.25.2.3.1.5.31

HOST-RESOURCES-MIB::hrStorageUsed.31 = INTEGER: 5910000
HOST-RESOURCES-MIB::hrStorageSize.31 = INTEGER: 6200000

That's 5,910,000 ÷ 6,200,000 × 100 = 95.3% — past the 95% critical line. The alert fires, an engineer clears the runaway logs and fixes the rotation, and disk usage falls back under the clear threshold. No 500s, no customer ticket, because the warning came while there was still headroom to act. Contrast the alternative: without the alert, the disk hits 100% overnight, the web server can't write, and the first anyone hears is an angry customer. Same data, entirely different outcome — the only difference is that someone was watching the right OID with a sensible threshold. Alerting mechanics are on alerting.

Adding external durability

There's one incident this internal setup can't catch: a failure of the monitoring server itself, its network, or the whole site. If the poller lives in the same rack as the fleet and the site loses connectivity, your monitoring goes dark at exactly the moment you need it — a silent outage that reports nothing because the thing that would report it is also down. The fix is independent, off-box checks that poll the fleet from outside your network. An external service such as ostr.io watches from a separate vantage point, giving you double durability: your internal monitoring for depth, and an outside path that survives a local failure. Add it alongside the internal setup so a problem with your own infrastructure can't blind you to it.

Lessons learned

What this illustrative deployment teaches:

• The boring metrics matter most — disk, load, and uptime cause more real outages than anything exotic.
• Thresholds need headroom — warn early enough to act, not at the moment of failure.
• Uniformity scales — standard OIDs mean one template covers the whole fleet.
• Internal monitoring has a blind spot — it can't report its own failure; external checks close that gap.

Frequently asked questions

What should a web host monitor with SNMP?

Prioritise the metrics behind the most common outages: disk usage (to prevent full-disk failures), system load and CPU (to catch overload and slow sites), uptime (to detect silent reboots), and interface traffic (to spot saturated links). These come from standard OIDs that read identically across a Linux fleet, so one polling and alert template covers every server. Add memory and per-service checks as second-tier metrics.

Which OID catches a full disk?

The HOST-RESOURCES storage table: hrStorageUsed (…25.2.3.1.6) against hrStorageSize (…25.2.3.1.5) at the same storage index. Compute used ÷ size × 100 for a percentage and alert with headroom — for example warn at 90% and treat 95% as critical — so you have time to clear space before the disk fills and the web server starts failing writes.

How do I avoid silent outages?

Add external, off-box monitoring alongside your internal SNMP polling. Internal monitoring can't report its own failure — if the monitoring server or the whole site goes down, so does the thing that would alert you. An independent external check polls from outside your network and survives a local outage, giving you double durability so an infrastructure failure doesn't also silence your monitoring.

What thresholds should I use for hosting servers?

Treat published thresholds as starting points and tune to each server's role. A common baseline is disk warn 90% / critical 95%, sustained load above the core count, CPU sustained above roughly 85%, and any drop in the uptime counter as a reboot signal. A database server tolerates different load than a static-content box, so adjust per workload and refine as you learn each server's normal range.

Key takeaways

• The costly hosting failures are mundane: disk-full, load spikes, silent reboots — all cheap to catch with SNMP.
• Watch disk used % (…25.2.3.1.6 ÷ .5), load (…2021.10.1.3), CPU (…25.3.3.1.2), uptime (…25.1.1.0), interfaces (…31.1.1.1.6).
• Standard OIDs = one template across the whole fleet; alert with headroom, not at the failure point.
• A worked disk incident: the alert at 95.3% turned a would-be outage into a routine cleanup.
• Internal monitoring can't report its own failure — external checks close that blind spot.
• For that independent off-box path, add external monitoring with ostr.io.