Devora Cloud · Blog
Is your site slow? How to tell whether you lack CPU, memory or it is the code
Learn to read CPU and memory charts, restarts and logs (out of memory, Killed) to decide between adding replicas, upgrading your plan or fixing the code.
A slow site is one of the most common complaints — and one of the most expensive when the answer is a guess. Plenty of people buy a bigger server and find out a week later that the problem was a query without an index. Others spend days optimizing code when the application simply did not have enough memory.
The good news: the signals are usually clear once you know where to look. This guide shows how to read CPU, memory, restarts and logs to reach a diagnosis — and when the answer is to scale out, upgrade the plan or change the code.
First, understand what the charts measure
In the Devora Cloud dashboard, the CPU and memory charts show the percentage of your application’s quota, not of the whole server. On the Hobby plan, with 0.5 vCPU and 512 MB, 100% CPU means those 0.5 vCPU are fully used; on Pro, that the 2 vCPU are.
Always look at a long window, such as the last 24 hours. A spike of a few seconds during a deploy is normal. What matters is the pattern: high usage for a long time, steady growth, or sudden drops followed by a restart.
The dashboard also warns you when CPU or memory stay above 85% for at least three minutes — a good starting point for an investigation.
Signal 1: not enough CPU
Symptoms: CPU stays above 80% for long periods and pages slow down exactly at peak hours. Memory may be fine.
What to do:
- On Hobby (0.5 vCPU): consider Pro (2 vCPU) or Enterprise (4 vCPU).
- On Pro or Enterprise: turn on autoscaling or add a scaling replica to split traffic across copies.
- Before paying more, check whether heavy work is done on every request, such as generating reports, resizing images or processing large files.
Signal 2: not enough memory
Symptoms: memory goes above 90%, the restart count grows and the logs show messages like these:
- Killed — the system terminated the process because it exceeded the memory limit.
- out of memory or JavaScript heap out of memory — the process (often Node.js) hit its limit.
- The site goes down for a few seconds and comes back on its own, several times a day.
Replicas do not fix a memory shortage: every copy has the same limit as the plan. The way out is usually the next plan (Hobby 512 MB → Pro 1 GB → Enterprise 8 GB). If memory climbs non-stop until the process dies, also look for leaks: unbounded in-memory caches, lists that only grow, whole files loaded at once.
Signal 3: the problem is the code or the database
Symptoms: CPU and memory are low, there are no restarts, and pages are still slow. Here more server will not help — the application is waiting for something.
- Slow queries: missing indexes, queries inside loops (the classic N+1), whole tables loaded to show ten rows.
- Slow external APIs: payments, shipping or e-mail called during the request, without a timeout.
- Large files served by the application itself instead of S3 signed URLs.
- Timeouts and 5xx errors in the logs, which show exactly which route is struggling.
The fix is in the code: add the index, batch the queries, move heavy work to the background, add a Redis cache.
Quick diagnosis table
| What you see | Likely cause | What to do |
|---|---|---|
| CPU high for hours, normal memory | Not enough CPU | Autoscaling or a replica (Pro/Enterprise), or a plan with more vCPU |
| Memory above 90%, restarts, “Killed” | Not enough memory | Next plan; look for leaks |
| Low CPU and memory, slow pages | Code or database | Indexes, fewer queries, caching, API timeouts |
| Uploads failing with QuotaExceeded | S3 full | Delete files, buy a pack or move to a bigger plan |
| Slow only for far-away visitors | Distance to the server | Apps run in the USA; in Brazil, Devora’s CDN cache speeds up delivery |
Let your AI do the analysis
If you use the Devora Cloud AI token, you do not have to do this alone. Ask the AI that deployed your app “why is my site slow?”. It checks CPU and memory metrics for the last 24 hours, the restart count of each replica, the application logs and S3 usage.
The answer comes with numbers instead of hunches — for example, “memory stayed above 90% and there were restarts with Killed in the logs” — plus one clear recommendation. The AI does not change your plan or buy resources for you: that decision stays in the dashboard.
Frequently asked questions
Does adding replicas fix a memory shortage?
No. Each replica has the same memory limit as the plan; if the process runs out of memory, it does so on every copy. The answer is a plan with more RAM or reducing the code’s memory use.
What does “Killed” mean in the logs?
That the process was terminated for using more memory than its limit. It usually appears alongside restarts and memory close to 100% on the chart.
Does 100% CPU in the dashboard mean the server is overloaded?
Not necessarily. The percentage refers to your application’s quota: 100% means it uses all the CPU in your plan, not that the whole machine is full.
Can the AI change my plan?
No. It analyzes metrics and logs and makes a recommendation. You buy plans, paid replicas and storage packs yourself in the dashboard.