A useful VPS monitoring checklist answers three questions: can visitors use the website, is performance deteriorating, and will someone know when action is needed? Watching CPU alone leaves gaps. A server can be running while its application fails, its certificate expires, or its backups stop completing.
This guide gives website owners and small hosting teams a practical operations routine. Adapt the checks to your application, traffic pattern, and recovery requirements. The example alert rules below are starting points to test against your own baseline.
Start with the services your visitors depend on
List each production domain, application, database, queue worker, scheduled task, and storage dependency. Assign an owner and record where to find logs, configuration, backups, and recovery instructions. Include external services such as email delivery or payment providers when a failure would break a key workflow.
For each service, write down what successful operation looks like. A blog needs its pages to load; a booking application also needs availability searches and reservations to work. Monitoring should reflect these outcomes.
1. Monitor uptime from outside the VPS
Use an external check against the public HTTPS address. A monitor running only on the same VPS may disappear during the outage it is meant to report. Check the expected response status and a stable piece of content, so a generic error page returning HTTP 200 does not appear healthy.
- Check the main website and a representative application endpoint.
- Keep health endpoints lightweight and avoid exposing secrets or internal diagnostic data.
- Track DNS resolution and certificate expiry for each production hostname.
- Test important workflows with a dedicated test account and harmless test data where appropriate.
- Confirm failures across repeated checks or another location before paging someone for a transient network issue.
An external check detects the customer-facing symptom. Internal metrics help explain it. Google's SRE monitoring guidance describes this combination and highlights latency, traffic, errors, and saturation as four useful signals for service monitoring.
2. Track response time and application errors
Collect response times for important routes and separate successful requests from failed ones. Watch a percentile such as p95 alongside the request count: an average can hide a slow minority of requests, while a percentile based on very few samples can be unstable.
Group errors by status, route, and application version. A sudden increase in HTTP 5xx responses after deployment deserves a different investigation from an increase in 404 responses caused by crawlers. Record deployment times so they can be compared with changes in latency and error rates.
For Nginx upstream failures, keep these troubleshooting guides close to your incident notes: 502 Bad Gateway on Ubuntu and 504 Gateway Timeout on Ubuntu.
3. Watch capacity before it becomes an outage
Build a baseline during normal traffic and a known busy period. Compare resource readings with service behavior instead of treating a single percentage as proof of a problem.
- CPU: look for sustained pressure and identify which processes consume it.
- Memory: track available memory, swap activity, and application memory trends.
- Disk: monitor free space, inode availability, and the growth of uploads, logs, and database files.
- Storage performance: investigate increased I/O waits alongside slower application or database responses.
- Network: compare throughput, connection failures, and provider limits with normal activity.
Capacity alerts should leave enough time to act. If uploads are consuming several gigabytes each day, a trend-based warning can be more useful than waiting until a small amount of space remains. For incident diagnosis, see our Ubuntu VPS disk-space guide.
4. Check databases, workers, and scheduled tasks
A healthy web process does not guarantee a healthy application. Monitor database connection use, query delays, failed connections, and storage growth. Compare these with changes in application traffic. If connections are a recurring constraint, review our PostgreSQL pooling and monitoring guide.
For background jobs, measure queue length and the age of the oldest pending job. A short queue containing a job that has been stuck for an hour can matter more than a larger queue that clears promptly. Track worker failures and repeated retries.
Scheduled tasks need evidence of completion. A process existing or a schedule being configured is insufficient. Record the last successful run, duration, and outcome for each important task. Our Laravel queues and scheduler checklist covers related production concerns.
5. Monitor backup freshness and recovery readiness
Track the last successful backup, its destination, and whether a new usable artifact was produced. Investigate unexpectedly small backups and failed uploads. Keep the backup destination separate from the server whose failure you need to survive, with access controls appropriate to the data.
Choose a freshness target based on how much recent data you can afford to lose. A daily backup may suit one site and be inadequate for another. Also define how long recovery can take before the business is materially affected.
Run restore exercises in an isolated environment and record how long they take. Check that the restored application can use the restored data, and include configuration and required secrets in your recovery plan through a secure process. Read our PostgreSQL backup and restore testing guide for a related checklist.
6. Turn monitoring into actionable alerts
For every alert, define an owner, severity, notification route, and first response. Separate urgent interruptions from issues that can become a maintenance task. An alert should explain what failed and point to the evidence needed to investigate it.
Consider these example rules, then tune them using your workload:
- Availability: alert when a critical HTTPS check fails repeatedly, with confirmation when available.
- Application errors: alert when the 5xx rate rises above your acceptable level over a meaningful window and with enough requests to interpret it.
- Performance: alert when latency exceeds the target for a critical workflow for a sustained period.
- Capacity: create a warning when projected disk exhaustion leaves less time than your team needs to respond.
- Background work: alert when the oldest queued job exceeds its expected processing delay.
- Recovery: alert when no successful backup exists within your agreed freshness target.
Do not copy thresholds from another server without checking whether they fit. Use recovery notifications, maintenance windows, and grouping for related events to reduce repeated notifications. Route alerts through a channel that remains available if the VPS is offline.
A simple VPS operations routine
Daily: review exceptions
Check unresolved alerts, unusual errors, backup freshness, and failed scheduled tasks. Focus on changed or failing conditions. Record the owner and next action for anything that needs follow-up.
Weekly: review trends and recurring problems
Inspect resource growth, slow routes, noisy alerts, and repeated worker failures. Review upcoming certificate deadlines and planned maintenance. Update incident instructions when a recent investigation revealed a missing step.
Monthly: test the operational process
Run an appropriate restore exercise, test notification delivery, and review who can respond to an outage. Revisit thresholds after traffic or infrastructure changes. For resilience planning beyond monitoring, see our VPS high-availability guide.
What every incident note should contain
- The affected service, first failure time, and visible customer impact.
- The alert, logs, and metrics that establish what happened.
- Recent deployments or configuration changes.
- The mitigation taken and how recovery was verified.
- A follow-up owner and a specific improvement to reduce recurrence.
Store operational knowledge where the team can find it during an outage. Avoid copying credentials into dashboards or incident notes. Our guide to a single source of truth for operations explains a related organizational approach.
Frequently asked questions
Is an uptime monitor enough for a VPS?
It is a useful start, but it will not explain slow queries, a growing job backlog, or a stale backup. Combine external availability checks with application and server signals.
What CPU percentage should trigger an alert?
There is no universal threshold. Compare sustained CPU use with latency, errors, workload, and remaining capacity. Use a threshold and duration that give your team enough time to investigate a meaningful problem.
How often should I check website uptime?
Choose an interval based on how quickly you need to detect failure and what load the check creates. A one-minute interval is a possible starting point for a lightweight endpoint, then adjust confirmation rules and frequency to your service requirements.
Can a hosting control panel replace external monitoring?
A panel can provide useful operational visibility, depending on its capabilities, but external checks still show whether the public service is reachable. Evaluate both the information a panel exposes and what happens to notifications when its server is unavailable.
Build the smallest useful monitoring system
Start with public availability, application errors and response times, disk capacity, and backup freshness. Give each alert an owner and a clear response, then add signals when an incident or business requirement reveals a gap. Explore Core Panel and our VPS hosting articles for more guidance on running production websites.
