How to monitor a Linux web server

Monitoring only needs to answer two questions: “Can users complete the important task?” and “Is the system approaching a limit or failure?” Everything else is decoration. A wall of unread dashboards doesn’t make a server reliable — it just makes the outage better documented.

Start with user-visible checks

Check the public HTTPS endpoint from outside the server. Validate status, response time, certificate expiry, and a known piece of content. For critical systems, perform a synthetic transaction such as login, search, or checkout using a safe test account.

Monitor DNS resolution separately so a DNS failure is not misclassified as an application failure.

Track capacity and saturation

Establish baselines for:

• CPU utilization, load, and throttling,
• available memory and swap activity,
• disk space, inode use, and I/O latency,
• network errors, connections, and bandwidth,
• database connections, query latency, and storage,
• worker queues and background-job delay.

Useful local commands include:

uptime
free -h
df -h
df -i
ss -s
systemctl --failed
journalctl -p warning --since today

These are diagnostic tools, not a monitoring system. Export metrics and logs to a location that remains accessible if the server fails.

Monitor services and dependencies

Check the web server, application process, database, queue, and scheduled jobs. A running process is not proof that it serves correct responses. Include external dependencies such as payment, email, storage, and DNS when they affect the user journey.

Track scheduled-job completion and last-success timestamps. Silent failures often appear first as stale data or delayed email.

Watch certificates and updates

Alert well before TLS certificate expiry and verify automated renewal by observing the installed certificate, not only a scheduler exit code. Monitor security-update status, reboot requirements, and unsupported operating-system or runtime versions.

Verify backups as an outcome

Alert on missed backups, unusual size changes, retention gaps, and failed integrity checks. A successful backup job is insufficient: schedule restore exercises and record the actual recovery time.

Design actionable alerts

Each alert should include severity, affected service, current evidence, likely first checks, owner, and escalation path. Prefer trends over static thresholds: disk usage sitting calmly at 80% is a Tuesday, while disk usage racing from 40% to 80% in an hour is an incident in progress.

Route urgent alerts through a channel that is not dependent on the failed system. Review recurring alerts and either fix the cause or improve the rule.

Build a small runbook

For every critical alert, document how to confirm impact, check recent changes, inspect logs, reduce harm, roll back, and communicate status. Practice the runbook before an outage and keep provider-console and recovery credentials available to authorized responders.