---
type: Article
title: "Monitor Web Hosting / VPS"
description: "Monitor a VPS on two layers: SNMP for the server's vitals and an HTTP check for what visitors see, so a 502 can't hide behind a healthy CPU graph."
resource: "https://snmp-monitoring.com/guides/web-hosting/"
tags: [guides, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Monitor Web Hosting / VPS

To monitor web hosting properly you need two answers at once: is the machine healthy, and is the site actually serving? A box can sit at 20% CPU with plenty of disk and still be handing visitors a 502. So this guide pairs the two halves — SNMP for the server's vital signs, an HTTP check for what the outside world sees — into one practical setup for a VPS or shared web host. You'll get the real OIDs for CPU, disk, uptime, and network traffic, the commands to read them, and the reason vps monitoring only becomes trustworthy once part of it lives off the server entirely.

## The problem with watching your own web host

A web server fails in more ways than "it's down." The disk fills with logs and MySQL starts refusing writes. A traffic spike pins the CPU and page loads crawl. A memory leak in a PHP worker slowly eats RAM until the OOM killer starts swinging. The nginx process dies but the VPS keeps pinging, so a naive uptime check stays green while every visitor gets an error.

That's the trap. Ping tells you the kernel is alive. It says nothing about whether Apache is serving, whether there's room on the disk, or whether the box is drowning. To genuinely monitor web hosting you have to look at layers — the hardware and OS underneath, and the HTTP service on top — because a fault in either one takes your site offline, and they fail independently. Watch only one and you've got a monitoring dashboard that's confidently, cheerfully wrong at the worst possible moment.

![Diagram: two-layer web hosting monitoring showing SNMP polling server resources and an HTTP check probing the website from outside](https://snmp-monitoring.com/img/guides/web-hosting-two-layer.webp)

## The two-layer approach to vps monitoring

The clean mental model is a stack with two probes.

Underneath sits the **server layer** — CPU, memory, disk, uptime, network throughput. SNMP is made for this. Your VPS almost certainly runs an SNMP daemon already, and it publishes every one of those metrics through standard MIBs with zero extra agents to install. You poll it, you get numbers.

On top sits the **service layer** — the actual HTTP or HTTPS response. Here you don't care about OIDs; you care about the status code, the response time, and whether the TLS certificate is valid. That's a plain web request, checked from a client's point of view.

- **SNMP layer** answers: does the machine have the resources to keep serving?
- **HTTP layer** answers: is the site returning 200s at an acceptable speed right now?

Put both on the same timeline and cause meets effect. Response times climbing while `hrProcessorLoad` and disk usage climb alongside them? That's saturation, and now you know which resource to grow. The [HTTP vs SNMP monitoring](/monitoring/http-vs-snmp-monitoring.md) breakdown digs into where each protocol is the right tool.

## Step-by-step: monitor web hosting end to end

1. **Enable the SNMP agent.** On a Debian or Ubuntu VPS, install and start snmpd — the [install snmpd guide](/setup/install-snmpd-ubuntu-debian.md) covers it — then confirm it answers a walk.
2. **Lock it down.** Configure read-only SNMPv2c with a random community string and an OID allowlist, and move the agent off default port 161. The [snmpd.conf reference](/setup/snmpd-conf.md) and [OID allowlist](/setup/oid-allowlist.md) show the exact lines. Read-only means a leaked community can't change anything.
3. **Read CPU.** Walk `hrProcessorLoad` at `1.3.6.1.2.1.25.3.3.1.2` — one value per core, 0–100 percent. Details in [SNMP CPU monitoring](/sensors/server-resources/cpu-utilization.md).
4. **Read disk.** This is the one that quietly kills web hosts. Walk the storage table — `hrStorageDescr` (`1.3.6.1.2.1.25.2.3.1.3`) to name each mount, `hrStorageSize` (`.5`) and `hrStorageUsed` (`.6`) to compute percent full. See [SNMP storage monitoring](/sensors/storage/disk-space-usage.md).
5. **Read uptime.** `hrSystemUptime` at `1.3.6.1.2.1.25.1.1.0` — a reset here means the box rebooted, planned or not.
6. **Read network traffic.** The IF-MIB interface table `1.3.6.1.2.1.2.2.1` carries per-interface octet counters; subtract consecutive samples for a throughput rate. More in [SNMP interface traffic](/sensors/network/interface-traffic.md).
7. **Add the HTTP check.** Separately, probe the site's URL for status code and response time. This is your service-layer signal, and it belongs [checking availability](/http-monitoring/availability-monitoring.md) from a client's vantage point.
8. **Set thresholds and alert.** Warn on sustained high CPU, disk over ~85%, and slow or non-200 responses. Alert on duration, not a single blip.

The disk step deserves emphasis. Of everything that takes a small web host down, a full root filesystem is the most common and the most preventable — logs, sessions, and package caches creep up while nobody's looking.

## Reading the metrics: a worked example

Here's a quick pass over a live VPS. Swap in your community string, host, and the port you chose.

```bash
# CPU load per core (percent):
snmpwalk -v2c -c s3cr3t 203.0.113.10:161 1.3.6.1.2.1.25.3.3.1.2

# Storage table — names, size, used (in allocation units):
snmpwalk -v2c -c s3cr3t 203.0.113.10 1.3.6.1.2.1.25.2.3.1.3
snmpwalk -v2c -c s3cr3t 203.0.113.10 1.3.6.1.2.1.25.2.3.1.5
snmpwalk -v2c -c s3cr3t 203.0.113.10 1.3.6.1.2.1.25.2.3.1.6

# System uptime:
snmpget  -v2c -c s3cr3t 203.0.113.10 1.3.6.1.2.1.25.1.1.0
```

The storage table hands back sizes in allocation units, not bytes — multiply by `hrStorageAllocationUnits` (`1.3.6.1.2.1.25.2.3.1.4`) if you want raw bytes, but for a percent-full figure you just divide used by size. Here's the shape of what you're collecting:

| Metric | OID | What it tells you |
|---|---|---|
| CPU load (per core) | `1.3.6.1.2.1.25.3.3.1.2` | Is the box compute-bound? |
| Storage name | `1.3.6.1.2.1.25.2.3.1.3` | Which mount is which |
| Storage size | `1.3.6.1.2.1.25.2.3.1.5` | Capacity of each volume |
| Storage used | `1.3.6.1.2.1.25.2.3.1.6` | How full — watch the root FS |
| System uptime | `1.3.6.1.2.1.25.1.1.0` | Reboots and crashes |
| Interface traffic | `1.3.6.1.2.1.2.2.1` | Inbound/outbound throughput |

## Getting alerted when the host goes quiet

Now the part that makes vps monitoring actually reliable. Every metric above is being read *from* the server — and a monitoring agent that lives on your VPS shares its fate. When the disk fills and the process manager seizes, or the CPU pegs so hard nothing else gets scheduled, or the network stack falls over, that on-host agent can't send its warning. It's stuck on the same sinking box. The one moment you need the alert is exactly the moment the local tooling can't produce it.

External checks close that gap. This is [double durability](/monitoring/double-durability.md): an independent watcher outside your network polls the same SNMP health metrics *and* hits your site over HTTP, so a crashed or saturated host still trips an alarm from the outside. [ostr.io Monitoring](https://ostr.io/service/monitoring) does exactly this pairing — HTTP/HTTPS availability (response time, status code, uptime) plus SNMP health monitoring of your CPU, disk, and uptime — and sends real-time email and SMS the moment either layer goes wrong. It's the difference between finding out from a graph and finding out from an angry customer.

![Chart: VPS monitoring dashboard plotting CPU, disk usage, and HTTP response time on one timeline](https://snmp-monitoring.com/img/guides/vps-monitoring-dashboard.webp)


## FAQ

**Can I monitor a shared hosting account with SNMP?**
Usually not — SNMP needs an agent on the server, and shared hosts rarely give you that access. On a VPS, dedicated server, or cloud instance where you control the OS, you can install snmpd freely. For shared hosting, you're limited to the HTTP availability layer, which you can still check externally.

**What's the single most important thing to watch on a web host?**
Disk space, closely followed by whether the site returns a 200. A full root filesystem quietly breaks databases, sessions, and uploads, and it's the failure mode that catches people out most often. Watch `hrStorageUsed` against `hrStorageSize` and alert well before 100%.

**Why check HTTP if SNMP already shows the server is healthy?**
Because the box being healthy doesn't mean your site is served. Nginx or Apache can crash, a config can break, or a certificate can expire while CPU and memory look perfectly fine. The HTTP check is the only signal that reflects what a real visitor experiences.

**Do I need SNMPv3 to monitor a VPS?**
SNMPv2c with a random community string, a read-only allowlist, and a non-default port is adequate for most single-server setups. Choose SNMPv3 when you want authentication and encryption on the wire — for example, polling across the public internet without a VPN.

## Conclusion

To monitor web hosting you watch two layers, not one. SNMP gives you the server's vital signs — CPU at `1.3.6.1.2.1.25.3.3.1.2`, storage at `1.3.6.1.2.1.25.2.3.1.3/.5/.6`, uptime at `1.3.6.1.2.1.25.1.1.0`, and interface traffic from the IF-MIB — while a plain HTTP check confirms the site is really serving. Lock the agent down, poll on a steady cadence, and set duration-based thresholds. Then push part of the job off the box, because dependable vps monitoring means an outside observer that still shouts when your server has gone silent. For related walkthroughs, see the other [SNMP guides](/guides/index.md) or start from the [SNMP monitoring home](/index.md).