A cloud infrastructure can appear stable and still be showing signs that something isn’t working as it should.
An increase in latency, more errors than usual, or increasingly saturated resources can go unnoticed if we only check that services are still up.
That’s why monitoring an infrastructure isn’t about reviewing hundreds of metrics—it’s about identifying the ones that truly help you understand its state.
In this article, we’ll go over 7 key indicators to understand the health of your cloud, detect anomalies, and anticipate potential problems before they affect your applications.
Latency measures how long a system takes to respond to a request and is one of the most important indicators for evaluating an application’s performance.
A progressive increase can be related to different issues: a database responding more slowly, an API under heavier load, an external dependency, or a service that is starting to run out of capacity.
That’s why it’s not enough to know that latency has increased. It’s also important to detect when it starts to change and which components may be related to that deterioration.
What can it indicate?
The error rate shows what percentage of requests are not completing successfully.
An increase can be one of the first signs that a service, a dependency, or some component of the infrastructure is having problems.
The key is to relate the increase in errors to when it appears, the services affected, and other changes that may have occurred at the same time.
CPU usage tells you how much of the available processing resources are being used.
High, sustained consumption can indicate that a service is reaching its limit and needs more capacity. But consistently low usage can also be relevant: it may indicate that resources are over-provisioned and, therefore, that there’s room to optimize costs.
That’s why this metric helps with decisions about both performance and capacity as well as efficiency.
What matters is observing its evolution and understanding whether the behavior responds to a one-off situation or a trend.
High consumption can cause worse performance, errors, or even restarts of certain services.
However, rather than focusing solely on a specific percentage, it’s important to observe how consumption evolves over time.
If used memory increases progressively and doesn’t return to its usual levels, there may be an anomaly worth investigating.
Saturation indicates how close a resource is to its maximum capacity.
It can affect different elements of an infrastructure: CPU, memory, storage, database connections, queues, network, and processing capacity.
An infrastructure can continue to function correctly while some of these resources begin to approach their limits. Precisely for that reason, saturation can act as an early warning signal before an incident becomes visible to the user.
Detecting it in time allows you to anticipate capacity issues and act before performance is affected.
Throughput indicates how much work a system is processing during a given period. It can be measured, for example, through requests per second or transactions processed.
This metric is especially useful when analyzed alongside latency and errors.
If the number of requests increases considerably and, at the same time, latency and errors increase, there may be a capacity or scaling problem.
The opposite can also happen. A sudden drop in request volume can be a sign that traffic isn’t reaching the system correctly.
That’s why observing how much traffic an application receives helps put the rest of the metrics into context.
Availability shows whether a service is accessible and operational during a given period.
It’s a metric especially related to user experience: if an application isn’t available, the impact is immediate.
But being available doesn’t necessarily mean functioning well.
An application can respond correctly and, at the same time, show high latency, intermittent errors, or capacity issues.
That’s why availability should be analyzed alongside other metrics such as latency, errors, and saturation to get a more complete picture of the service’s state.
One of the biggest challenges when monitoring a cloud infrastructure isn’t getting data—it’s interpreting it correctly.
Let’s imagine a service reaches 90% CPU usage. On its own, this data point doesn’t necessarily mean there’s an incident.
But if at the same time:
Then we have much more context to understand what might be happening.
A single metric shows a signal. Several related metrics help you understand what’s happening.
And that difference is especially important in distributed infrastructures, where a problem in one component can end up affecting many others.
Metrics let you know what’s changing, but they don’t always explain why.
To get a more complete picture, it’s necessary to relate them to other sources of information, such as logs, traces, and events.
For example, an increase in latency can be the result of a slow database query, an external dependency, or a recent change in a service.
Observability allows you to connect these signals and build a more complete picture of what’s happening in the infrastructure.
Additionally, artificial intelligence allows us to detect anomalies, identify patterns, and relate different signals that might go unnoticed when analyzed manually.
At Lessthan3, metrics, logs, traces, and events are integrated into a single environment and interface to provide a complete view of what’s happening in your infrastructure.
The platform uses AI capabilities to detect patterns, identify anomalies, and provide context, helping DevOps, engineering, and product teams move from an isolated signal to a clearer view of the problem.
This reduces the time spent reviewing scattered information and allows teams to focus sooner on what’s happening, where the root cause may be, and what impact it could have.
Because knowing that a metric has increased is useful.
Understanding why it has increased is what allows you to make decisions.