Operations | Monitoring | ITSM | DevOps | Cloud

Cloud costs often grow quietly until they suddenly command everyone’s attention. Gartner estimates that companies overspend on cloud services by up to 70 percent, mostly because they lack clear visibility into where the money is actually being spent. Cloud invoices speak the language of infrastructure: nodes, instance types, regions, volumes, and egress. Engineering teams speak the language of services, deployments, and code.

When we set a memory limit for a container, the expectation is simple: if the app leaks memory, the OOM killer steps in, the container dies, Kubernetes restarts it, done. But reality is messier. As a container gets close to its memory limit, allocations don’t just fail instantly. They get slower. The kernel tries to reclaim memory inside the cgroup, and that takes time. Instead of being killed right away, your app just crawls.

Recently, I was testing Coroot’s AI Root Cause Analysis on failure scenarios from the OpenTelemetry demo. One of them, loadgeneratorFloodHomepage, simulates a flood of excessive requests. As expected, it caused a latency degradation across the stack. Coroot’s RCA highlighted how the latency cascaded through all dependent services. At the same time, we noticed a moderate increase in CPU usage for the frontend service and the node itself.