Your orders API runs on a small VPS. Health checks are green, logs show 200 OK, and yet users say it feels sluggish. By the time you SSH in and run top, everything looks normal.
Uptime checks tell you the API is available. Application logs show its requests, but rarely show what else ran on the machine. top shows the machine now, not ten minutes ago. To investigate a short slowdown, you need application and host metrics on the same timeline with some history.
StatLite runs next to the app, reads Spring Boot Actuator metrics, and keeps the history in a local SQLite file. It can also show host metrics. Here's how those views help explore a slowdown.
The scenario
- A small VPS with one CPU
- A Spring Boot orders API backed by a database, receiving steady traffic
- StatLite running on the same machine
- A CPU-heavy maintenance job that starts partway through, runs for about 90 seconds, then exits
The scenario and dashboard screenshots are illustrative, not measurements from a production incident. The API's code, configuration, and request pace stay the same throughout the example.
Step 1: When did it get slow?
Open the dashboard and look at Average latency, which shows how long requests take on average between polls.
After startup settles, requests normally take 3 to 5 ms. At 3:18 PM, average latency starts rising, reaches about 25 ms, and drops back at 3:20 PM. That gives you a time window to compare with the other charts.
Step 2: Is it more traffic, or errors?
On the same screen, Requests stay flat, HTTP errors stay at zero, and App status stays UP. An uptime monitor would report the service as healthy through this period.
Step 3: Is the app doing more work?
Process runtime on the dashboard shows the API's own JVM. Its CPU stays around 3% or below, while JVM memory usage follows the same rise-and-fall pattern before, during, and after the slowdown.
The app does not appear to be using more CPU. That makes an application CPU regression less likely, though the chart alone cannot rule out database, disk, or network waits.
Step 4: Is something else busy on the server?
Actuator exposes JVM and some system metrics, but doesn't store their history. Since StatLite runs on the same VPS, switch to its self-monitoring target, statlite-self, and open Host resources to examine the server's CPU history.
Host CPU rises from roughly 10% to about 90% at 3:18 PM, then falls just before 3:20 PM. RAM and disk stay roughly flat.
The app's CPU stays low while the host's CPU is busy. On a single CPU, another process can make the API wait for CPU time. This pattern points toward CPU contention.
The CPU chart tells you when the host was busy, but not which process was responsible. In this scenario, a scheduled maintenance job overlaps with the slowdown. On a real server, check scheduled jobs and system logs for that time window.
Other patterns to notice
| What you see | Where to look next |
|---|---|
| Requests up, app CPU up | Traffic volume and application capacity |
| Requests flat, app CPU up | Application work, including a recent deploy |
| Requests flat, app CPU flat, host CPU up | Other processes on the host |
| App memory keeps climbing | Memory pressure, application allocation, and possible memory leaks |
| Everything flat except latency | Dependencies, database, disk, and network waits |
These are clues for investigation, not diagnoses by themselves. StatLite keeps the application and host history together so you can inspect the relevant minutes after the slowdown is over.
This example uses Spring Boot. StatLite also supports Micronaut, Quarkus, and applications that expose the StatLite Metrics v1 endpoint; see the integrations.
Explore application and host metrics on one timeline. Try the interactive dashboard with sample data. No installation required.