My machine is slow: reading CPU, burst capacity and network to know whether to upgrade

"The website is slow" is the most common complaint and the one that gives the least information. It may be that the machine has become too small, that something or someone is sending it far more traffic than usual, or that a process has gone haywire and is eating the processor. The three things are fixed in different ways, and upgrading the plan blindly is the most expensive of the three.

Lightsail keeps a few graphs for each machine that are enough to tell one case from another: CPU utilization, burst capacity, inbound and outbound network and status checks. You do not need to install anything. You do need to know what each one measures and, above all, understand burst capacity, which is what makes a small machine run fine for a while and then "run out".

Step by step

1. Open the machine's metrics

   Go to the Lightsail console, click the machine's name and go to the Metrics tab. At the top there is a drop-down to choose the graph: CPU utilization, CPU burst capacity (percentage), CPU burst capacity (minutes), Network in, Network out, Status check failed (instance) and Status check failed (system).

   On the right you choose the period. For "it is slow today" start with the last 6 hours; for "it has been like this for days" look at the whole week. Lightsail keeps two weeks of data; there is nothing further back.

2. Read the CPU together with the sustainable zone line

   On the CPU utilization graph there is a horizontal line, usually low, separating the sustainable zone (below) from the burstable zone (above). It is the figure most people misread: a small Lightsail machine is not entitled to 100 % of its processor all the time, but to a small percentage continuously; above that it is consuming credit. A CPU at 40 % may look calm and not be if the line is at 10 %. What matters is not the number but how much time it spends above the line.

   • Short spikes above the line and then back down: normal. That is what the credit is for.
   • Almost always above the line: the machine is too small for what it does, or something is overloading it. Carry on with the next step.
   • A flat line at 100 % that started at a specific moment: almost certainly a runaway process. Jump to step 5.

3. Look at the burst capacity: it is the tank

   Switch to CPU burst capacity (percentage). It is the level of the credit tank, from 0 to 100. When the machine is below the sustainable line, it rises slowly; when it is above, it falls. This graph tells the whole story:

   • It stays high (above 50 %) and recovers after spikes: the machine has plenty to spare. The slowness is not CPU.
   • It falls little by little over days and never fully recovers: you are using more CPU than the plan gives on a sustained basis. It is the classic symptom of "need a bigger machine".
   • It is at zero or nearly: the machine is exhausted. Lightsail limits it to the sustainable percentage and everything becomes painfully slow even though the CPU graph looks like it is "only" at 10 %. It is not that it does not need more: it is that it is not allowed to use it.

   The minutes variant says the same thing in time: how many minutes at full power are left if a spike in visits arrived right now.

4. Check the network: is there too much traffic?

   Open Network in and Network out. Do not look for a number; look for the shape, comparing today with a normal day last week.

   • Network and CPU have gone up together: the machine is working because traffic is arriving. It may be good (a campaign) or bad (bots). Check in the website's statistics (Analytics, Matomo) whether real visits have gone up too. If the network has shot up and visits have not, it is bots.
   • Inbound network has regular spikes at fixed times, with outbound flat: someone is crawling the website automatically. Typically it is attempts to log in to /wp-login.php or /xmlrpc.php hundreds of times a minute.
   • Outbound is huge and inbound is not: you are serving large files (videos, unoptimised images). Transfer has a monthly allowance included in the plan; if you exceed it, it is charged separately.
   • CPU is high and the network has not changed: the problem is inside the machine. Go to the next step.

5. Look for the runaway process

   If the CPU rose suddenly without the network changing, you need to look inside. Click Connect using SSH on the Connect tab and, in the terminal, type:

   top -o %CPU

   The first line is the process using the most processor. Normally you will see apache2, httpd, php-fpm or mysqld sharing the work. Be suspicious when:

   • A single process takes 100 % for minutes. For example mysqld on its own: a slow query or a table without an index, very common in WordPress with plugins that store statistics.
   • There is a process with a name you do not recognise using a lot: a backup in mid-morning, a plugin rebuilding thumbnails, or something that should not be there.
   • Dozens of php or apache2 processes at once: the machine is trying to serve more requests than it can. That is traffic; go back to the previous step.

   Press q to exit. If the culprit is clear, restarting the service is usually enough for today: on a Bitnami machine, sudo /opt/bitnami/ctlscript.sh restart; on Ubuntu, sudo systemctl restart apache2 (or mysql). Then you need to fix the cause.

6. Review the status checks

   The last two graphs should always be at zero. If Status check failed (system) has risen, the problem is in AWS's physical server, not in your machine: stop and start the instance again, and AWS moves it to another healthy server. If the one rising is the instance one, the machine is not responding: out of memory, disk full or hung. Restart it and, when it comes back, check the space with df -h. A disk at 100 % makes everything fail in strange ways.

7. Decide what to do with what you have seen

   The diagnosis boils down to three cases:

   • Need a bigger machine (CPU almost always above the line, burst capacity that does not recover, normal network, nothing odd in top). The cheap way out: a cache plugin if it is WordPress and cleaning up the database (remove plugins you do not use, delete revisions). Many websites halve their CPU with just that. The direct way: upgrade the plan. In Lightsail you do not resize in place: you take a snapshot, create a new machine with a bigger plan, move the static IP to it and delete the old one. There is a guide in this section.
   • Too much traffic (CPU and network rise together, real visits do not). Block the bots before paying for a bigger machine. The Lightsail firewall closes ports, but does not filter by type of request; for that use a security plugin in WordPress (limit login attempts, block xmlrpc.php) or put the website behind a service like Cloudflare. If the traffic is real, congratulations: now yes, cache and a bigger plan.
   • Runaway process (CPU at 100 % all of a sudden, network unchanged, one specific process in top). Restart the service and look for the cause: the slow query, the plugin, the scheduled task at a bad time. Upgrading the machine here only postpones the problem.

   Rule of thumb: if after caching and cleaning up the machine is still above the sustainable line most of the day, you genuinely need a bigger machine. The next plan costs a few euros more a month; less than an afternoon with the website down.

What can go wrong