One Problem at a Time

Know when the evidence is insufficient

How gaps and short observation windows can prevent a supported recommendation.

← All four episodes

One Problem at a Time · Episode 2 · 1:13

What happens when your monitoring data isn't good enough?

How gaps and short observation windows can prevent a supported recommendation.

Includes an earlier AKS test-workload assessment dated October 26, 2026, shown in the November 4 recording. The generic recommendation card is an illustration, not RATIVERA output. The CPU history threshold shown belongs to that assessment policy; memory protective increases can have different requirements.

English captions are burned into the video. An optional English caption track and transcript are also available. Use fullscreen for small screen details.

Collected versus usable evidence · Why a recommendation is withheld

Episode page & transcript · Download MP4

Read the episode 2 transcript

Three quiet days of metrics. A tool sees low memory use, and suggests cutting the request in half.

Then the weekly job runs.

Monitoring data is rarely complete. Scrapes are missed, pipelines restart, and labels stop matching pods.

On a chart, a gap can look exactly like low usage.

Short observation windows miss weekly cycles, month-end peaks, and releases that change how a workload behaves.

A recommendation built on that data looks precise. But nothing supports it, and in production it can cause throttling, or out-of-memory restarts.

RATIVERA checks the evidence before it concludes. When this workload on our own AKS test cluster was assessed, RATIVERA had a tenth of an hour of usable CPU evidence.

It needs a hundred and sixty-eight hours, at ninety percent coverage, before it will size the workload. So no recommendation was made, and the page says exactly what is missing.

A trustworthy optimization platform must know when not to recommend a change.

RATIVERA. Understanding Kubernetes, one problem at a time.

Download transcript · WebVTT captions · Original SRT captions