Reservations with context
Compare current and proposed requests alongside observed behavior. Review request-coupled HPA interactions before drawing conclusions.
The product
A sizing decision you can explain.
Understand the recommendation, the protection behind it, and the limits of what RATIVERA knows.
RATIVERA / Workload evidenceIllustrative example
Deployment · demo workload
checkout-api
CPU
1000mCurrent request
↓ DOWNSIZE600mProposed request · per replica
MEMORY
512MiBCurrent request
↑ UPSIZE768MiBProposed request · per replica
Reliability comes first.
This illustrative proposal shows different directions for CPU and memory. Actual recommendations require sufficient evidence and applicable constraints.
Human decision PENDINGInfrastructure changes NONE
One workload. Two resource stories.
CPU and memory stay distinct.
Protect the workload
Interpret memory demand alongside relevant pressure evidence. Missing OOM history is not evidence that no OOM occurred.
A recommendation has to earn its place
No recommendation yet is a useful answer.
WITHHELD OUTCOME
Explain what is missing.
An incomplete assessment must not dress a candidate number up as a recommendation. The explanation should identify the gap and what can resolve it.
PUBLISHED RECOMMENDATION
Stand behind the proposed action.
A published recommendation reflects the available evidence and applicable checks at assessment time. It is not a guarantee of a future workload outcome. It remains distinct from your human decision and from any infrastructure change.
History without hidden feedback
Your judgment stays in the record.
Accept, reject or defer a recommendation. Rejection rationale preserves customer knowledge as human-stated provenance. It does not automatically change Operating Context or the recommendation mathematics.
Understand the decision statesWorkloads & Coverage
Use workload inventory and assessment readiness to understand the scope being observed. A workload count alone does not establish recommendation readiness or prove that a workload is being optimized.
Detailed screen guidance follows signed-in verification of the current Workloads and Optimization Coverage interface.
One Problem at a Time · Episode 3 · 1:14
Do you know which AKS workloads are consuming your capacity?
Read workload inventory and organization-wide coverage without confusing selection with optimization.
Recorded test-environment figures dated November 4, 2026. The place-count explanation applies to fixed-place subscriptions. Unlimited plans do not count places, and Trials do not have a purchased-place pool. The illustrated 50-place allowance and workload counts are examples, not a plan offer or Trial limit. A Microsoft-managed SYSTEM workload uses a place only when explicitly selected under a fixed-place subscription; RATIVERA offers no changes for it. This is not a workload-protection guarantee.
English captions are burned into the video. An optional English caption track and transcript are also available. Use fullscreen for small screen details.
One Problem at a Time · Episode 1 · 1:15
Are your Kubernetes workloads requesting more resources than they need?
Why requests and usage differ, and why a low average alone cannot justify a reduction.
Illustrative numbers, not a customer result or savings claim. Requests affect scheduler placement; existing containers can still use otherwise idle CPU. In the CPU example, observed peaks are based on sampled five-minute averages. Seven days is the reduction-history gate described here; protective memory increases can follow a different path.
English captions are burned into the video. An optional English caption track and transcript are also available. Use fullscreen for small screen details.
Git workflow, when available
Repository reading, source mapping, and change execution are separate capabilities. Pull-request creation depends on the enabled environment and your authorized access. We do not describe it as generally available here.
Selection expresses your intent.
Review the inventory and choose the workloads you want assessed. Check scope and readiness separately: a selected workload can still lack usable evidence. Your team controls decisions and the resulting change process.
See capability boundaries · Read about the trial and paid requests
Understand the outcome.
| Outcome | What it means |
|---|---|
| Recommend Change | A supported CPU or Memory adjustment is available for human review. |
| Maintain | The assessment supports keeping the current request. |
| Withheld | Missing or insufficient evidence prevents a supported recommendation. A completed assessment can have no proposed change. |
| Pending | An assessment or a human decision is awaiting completion. Check which step is pending. |
| History | An earlier assessment or decision. Read its time and context; it is not automatically the current workload state. |
Connect Azure. Work with Git. Keep control.
Azure connections provide the reviewed resource and monitoring access. Supported Git connections link the right repository and source files. Change Requests help organize supported proposed edits for review.
Permissions, source mapping, plan eligibility, and execution availability must be confirmed for the environment. Your team reviews, merges, and deploys changes. A merge alone does not prove deployment; application verification compares observed Kubernetes configuration at the time checked.
Make room for better decisions
Start with the evidence.
Understand the reasoning before you change the request.
See how RATIVERA works
Evaluation participation and access are agreed individually.