How to monitor VPS performance: Metrics, tools, and tips

To monitor VPS performance, regularly check CPU usage, RAM consumption, disk space, disk inodes, network traffic, running processes, and uptime.

If you’re using Hostinger VPS, the Server Usage dashboard in hPanel gives you a quick visual overview of your server resource usage in one place.

Focus on these eight VPS performance monitoring areas:

1. Check VPS resource usage through the Hostinger hPanel dashboard.
2. Understand which metrics to track and what their warning signs look like.
3. Run Linux terminal commands for real-time, process-level diagnostics.
4. Set up monitoring agents that track resources around the clock.
5. Configure alerts with the right thresholds for each metric.
6. Follow a step-by-step workflow to troubleshoot a slow VPS.
7. Benchmark raw VPS capacity and know when to run tests.
8. Apply targeted fixes for the most common performance bottlenecks.

How can you monitor VPS performance in Hostinger hPanel?

Hostinger users can check VPS performance directly from hPanel by going to VPS → Manage → Backup & Monitoring → Server Usage.

The dashboard tracks CPU and RAM usage, disk space, and both incoming and outgoing traffic. It also shows historical data for the last 24 hours, week, month, and year.

If you’re just setting up a VPS, the Server Usage dashboard won’t show data right away. Give it about 30-60 minutes to populate. After that, it’s the quickest way to check resource trends without logging in via SSH.

Check CPU usage

CPU usage shows how much processing power your VPS is using at any given time. Short spikes during updates, backups, app installs, or data processing are normal and usually resolve on their own.

Focus on the pattern, not individual spikes. Repeated spikes at the same time each day usually point to a cron job or backup. CPU usage near 100% for hours means something is consistently overloading the server.

Common causes of sustained high CPU usage include resource-intensive background processes, poorly optimized scripts, traffic spikes, or insufficient CPU for the workload.

Check RAM usage

RAM usage shows how much memory active services and applications use on the VPS. When there isn’t enough RAM, the system starts using swap, which stores data on disk rather than in memory. This makes everything noticeably slower.

RAM usage and PHP memory limit are often confused, but they measure different things. The PHP memory limit caps the amount of memory a single PHP script can use, while RAM usage reflects the total memory used across all running services.

If RAM usage stays consistently high, check application workers, database memory allocation, caching services, and potential memory leaks.

Check disk space

Disk space shows the storage used by files, databases, backups, logs, and uploads. hPanel’s Server Usage dashboard tracks this metric directly so that you can spot storage trends over time.

Disk usage tends to grow gradually, then break things all at once when it’s full. A server at 95% might run fine for weeks, but one log flood or database dump can push it over the edge. Then databases crash, uploads fail, and the web server can’t write access logs.

Cache files, session files, log files, temporary files, and email queues are the most common causes of high disk usage. Schedule automatic log cleanup and regular cache clearing to keep this metric under control.

Check incoming and outgoing traffic

Incoming traffic is data sent to the server from visitors, APIs, crawlers, and external services. Outgoing traffic is data sent from the server to users, third-party APIs, backup destinations, or other external systems.

Traffic spikes from normal activity, like real visitors, API requests, and search engine crawlers, are expected. Spikes from aggressive bots, scrapers, or DDoS floods aren’t, since they consume server resources without serving real users.

Compare traffic graphs with CPU and RAM data at the same timestamp to see whether high traffic is causing a slowdown or occurring alongside another issue, such as a locked database query or a cron job using all available memory.

Which VPS performance metrics should you monitor?

There are eight VPS performance metrics worth tracking: CPU usage, RAM usage, disk space, disk inodes, disk I/O, network traffic, running processes, and uptime or response time.

Keep in mind that these thresholds aren’t universal rules. The 80-85% CPU warning range matters because, above that, the server has very little headroom to handle sudden spikes without queuing tasks.

The 85-90% disk threshold matters for a similar reason. Logs, temporary files, and database writes can consume the remaining space quickly during an incident, leaving no room for recovery.

Monitor your normal usage patterns for a week or two, then adjust these numbers accordingly.

For example, if your CPU usage normally peaks at 50% during busy hours, set an alert at 75-80%. This gives you enough room to catch real problems without false alarms from normal activity.

How can you check VPS performance from the Linux terminal?

Monitoring VPS performance via hPanel shows resource trends over time, but Linux commands give you the real-time, process-level details needed to pinpoint what’s causing a spike.

Use these commands when you spot a spike in hPanel and need to identify the exact process or service causing it.

The top and htop commands show a live view of running processes along with their CPU and memory usage. They’re the fastest way to find which service is using the most resources on the VPS.

One value worth watching in top is st (steal time) in the CPU row. It shows the percentage of CPU time the physical server allocated to other VPS instances rather than yours.

If steal time stays consistently above 5-10%, your VPS is competing for CPU with its neighbors, and that’s not something you can fix from your end.

The htop command shows the same data as top, but in a more readable, interactive layout. Press P to sort by CPU usage or M to sort by memory, so the process using the most resources appears at the top.

To check disk usage, use df -h to view storage usage by partition and df -i to show inode usage. Inodes represent the number of files and folders on the VPS. Hitting the inode limit prevents new files from being created, even when storage space is available.

After identifying the heavy process, check system logs for errors that line up with the spike. The journalctl command filters logs by time range, service name, or priority level, making it simple to match errors to the exact timestamps when resources spiked.

How do monitoring agents help track VPS performance continuously?

Running terminal commands works well when you’re actively troubleshooting, but you can’t sit in an SSH session all day watching metrics.

Monitoring agents fill that gap by running on the VPS, collecting metrics at regular intervals, and displaying them in dashboards. They can also send alerts when something crosses a set threshold.

The main advantage is historical data. Agents track trends over days and weeks, helping you spot gradual memory creep or slow disk fill-up long before it becomes a crisis. Most agents also send notifications through email, Slack, Telegram, or webhooks.

Five tools are commonly used for continuous VPS monitoring:

• hPanel Server Usage dashboard. It requires no installation and tracks CPU, RAM, disk space, and traffic with historical views up to one year. For Hostinger VPS customers using hPanel for server management, it covers the basics without extra setup.
• Netdata. It provides a real-time, browser-based dashboard that automatically detects running services, with per-second granularity and built-in anomaly detection. Netdata is a good fit when you want detailed visibility without assembling multiple tools. Install it with the following command:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

• Prometheus + Node Exporter + Grafana. This self-hosted stack is commonly used for VPS performance monitoring. Node Exporter collects system metrics, Prometheus stores and queries time-series data, and Grafana visualizes everything in customizable dashboards. It’s best for teams that need long-term metric storage and custom alerting rules.
• Uptime monitoring tools. Use tools like Uptime Kuma to check whether your website or application is reachable from outside the server. They test HTTP endpoints, TCP ports, DNS records, and SSL certificate expiration. Uptime Kuma is self-hosted, open source, and supports 90+ notification channels.
• Application performance monitoring (APM) tools. These tools measure events at the application layer, including response times, database query durations, error rates, and request traces. System-level metrics can tell you the server is busy, while APM tools can tell you which code path or query is causing it.

The right choice depends on how much visibility you need.

hPanel handles quick checks with zero setup, Netdata and the Prometheus stack provide self-hosted observability at different levels of complexity, and Uptime Kuma monitors availability from the outside.

Add APM tools when you need to diagnose application-level response times beyond what system metrics can show.

What alerts should you set for VPS performance monitoring?

Set alerts for sustained high CPU usage, low available RAM, disk space thresholds, unusual traffic spikes, and HTTP errors.

Focus on sustained conditions rather than brief spikes, since a backup or deployment can temporarily push metrics up without indicating a real problem.

Configure alerts for the following conditions:

• Sustained high CPU usage above 80-85% for more than five minutes.
• Low available RAM or increasing swap usage.
• Disk usage above 85-90% of total capacity.
• Inode usage approaching the file system limit.
• High disk I/O latency causing slow reads and writes.
• Unusual incoming or outgoing network traffic spikes.
• 5xx HTTP errors from the web server.

The real value of alerting isn’t the thresholds themselves, but having a planned response for each one. Map every alert type to a specific first action so you’re not starting from scratch when a notification fires at 2 a.m.

For example, a CPU alert means finding which process spiked and deciding whether to restart it, optimize it, or move it to off-peak hours.

When a disk alert fires, identify what caused the growth and clear it before the server runs out of space completely.

For traffic alerts, check whether the spike comes from legitimate visitors or something you need to block.

Separating warnings from critical alerts also prevents alert fatigue. A warning at 75% CPU suggests checking it when you have time, while a critical alert at 95% means you need to act immediately.

How do you troubleshoot a slow VPS with monitoring data?

Troubleshoot a slow VPS with monitoring data by checking resources one at a time. Start from external availability, then work inward to specific processes and logs.

These nine steps isolate the bottleneck in order of likelihood:

1. Check whether the site is publicly slow or unavailable. Open it on your phone using mobile data or use an external uptime checker. If the site loads fine from elsewhere, the issue is on your local network, not the server.
2. Check the Server Usage dashboard for resource spikes. Look at CPU, RAM, disk space, and traffic graphs for the same period when the slowdown started.
3. Find the heavy process with top, htop, or ps aux. Sort by CPU or memory to see which service is using the most resources. MySQL, Apache, NGINX, PHP-FPM, and Redis are the usual suspects.
4. Check RAM and swap with free -m. If available RAM is near zero and swap usage is climbing, the VPS is running out of memory. Reducing application worker counts is usually the fastest fix.
5. Check disk space and inodes with df -h and df -i. If either is nearly full, run du -sh /* to find the largest directories, then clear old logs, temporary files, or stale backups to free up space.
6. Check disk I/O if CPU and RAM look fine. Run iostat -x 2 or iotop to see whether slow disk reads and writes are the bottleneck. High I/O wait in top, the wa value, confirms the CPU is spending time waiting on disk.
7. Check network connections with ss and your traffic graphs. A flood of connections from a single IP range often points to a bot attack or a misconfigured crawler.
8. Review logs. Check /var/log/syslog, the NGINX or Apache error log, PHP-FPM logs, and MySQL slow query logs for errors that line up with the performance drop.
9. Optimize first, then decide whether to scale. Tune database queries, enable caching, clean up logs, or adjust worker counts. Consider upgrading your VPS plan only if the same bottleneck keeps returning after optimization.

When should you benchmark VPS performance?

Benchmark your VPS performance after purchasing a new plan, upgrading resources, or when performance doesn’t meet your expectations.

Unlike monitoring, which tracks health over time, benchmarking tests raw VPS capacity at a single point in time under controlled conditions.

Run benchmarks in these situations:

• After buying a new VPS, to verify that actual performance matches the plan specifications.
• Before and after upgrading a VPS plan, to measure the real difference in CPU, disk, or network speed.
• Before migrating to a different data center or provider, to compare performance with your current setup.
• When your application feels slow but monitoring shows resources aren’t maxed out, since a benchmark can reveal whether the hardware itself is underperforming.

Seven commonly used VPS benchmarking tools are:

• sysbench. Tests CPU computation speed, memory throughput, and MySQL performance under load.
• UnixBench. Runs a suite of POSIX system-level tests, including file copying, pipe throughput, and process creation.
• Geekbench. Measures single-core and multi-core CPU performance with a standardized score for cross-platform comparison.
• fio (Flexible I/O Tester). Benchmarks disk read and write performance with customizable block sizes, queue depths, and I/O patterns.
• iperf3. Measures network bandwidth between the VPS and a remote server, testing both upload and download throughput.
• speedtest-cli. Tests internet upload and download speeds, along with latency from the VPS to the nearest test server.
• YABS (Yet Another Bench Script). Automates fio, iperf3, and Geekbench into a single command, producing a comprehensive report of CPU, disk, and network performance.

Avoid running benchmarks during peak traffic hours, as these tests consume significant CPU, disk, and network resources that compete directly with live visitors. Running them too often on a production server also places unnecessary strain on the server.

For existing deployments, schedule benchmarks during low-traffic periods. For a new VPS, run them before deploying anything to set a clean performance baseline.

How can you improve VPS performance after finding a bottleneck?

Improve VPS performance by matching each bottleneck to a targeted fix based on your monitoring data. Each bottleneck needs a different fix, and the right one depends on which resource is under pressure.

• High CPU. Enable opcode caching and review application code for inefficient loops or repeated database calls. Move background tasks, such as report generation and email queues, to off-peak hours using cron scheduling.
• High RAM. Tune innodb_buffer_pool_size so MySQL or MariaDB doesn’t claim more memory than the VPS can spare. Check for memory leaks in long-running processes, especially custom scripts that hold data in memory without releasing it.
• Full disk. Set up automatic rotation with logrotate to prevent logs from growing indefinitely. Serve large media files from external storage or a CDN to keep local disk usage low.
• High inode usage. Inode problems are about file count, not file size, so the usual disk cleanup approach won’t always help. Look for directories with thousands of small files, like PHP session folders, cache directories, and mail queues. Then remove stale entries or automate cleanup with a cron job.
• High disk I/O. Put Redis or Memcached in front of the database to reduce repeated reads. Check the MySQL slow query log for queries that scan more rows than necessary, and add indexes where they help.
• High network traffic. A CDN like Cloudflare offloads static asset delivery, so the VPS handles less bandwidth. Firewall rules block abusive IP ranges, and web server rate limiting slows down aggressive bots and crawlers.
• Slow response time. Full-page caching at the web server level makes the biggest difference for repeat visitors. Beyond that, optimize database indexes for frequently queried tables, reduce external API calls that block page rendering, and compress responses with Gzip or Brotli.

If none of these fixes resolve the issue, upgrade to a higher-tier VPS plan with more resources. Use your monitoring data to pick the right tier instead of guessing.

If only one resource is the bottleneck, like RAM at 95% while CPU sits at 30% and storage at 40%, move up one tier and see if the extra memory is enough. Jumping straight to the highest plan wastes money if your setup only needs slightly more of one resource.

Monitor the same metrics for another week or two after upgrading to confirm the new plan fixed the problem.

All of the tutorial content on this website is subject to

Hostinger’s rigorous editorial standards and values.