Docs

Resource Optimization

What this screen is for

Resource Optimization turns cost data into specific recommendations: which workloads are over-provisioned, which are under-used, and where requests and limits do not match reality.

Cost Analysis tells you the bill is too high. This page tells you what to change.

Before you start

To do this You need
Open the page access to at least one environment tier (env-by-branch.<env>.access)

A registered, valid cluster is required. Recommendations are computed per cluster from observed usage, so a recently registered cluster has little to say.

Opening it

  1. Cost › Resource Optimization in the sidebar.

Direct URL: /ebb/resource-optimization

The interface

📸 Screenshot Placeholder: The Resource Optimization page. Mark: (1) the cluster selector, (2) the recommendations list, (3) an empty state.

# Control What it does When you’d use it
1 Cluster selector Chooses the cluster Always
2 Recommendations Workloads whose resourcing does not match usage The substance
3 Empty state Shown when there is nothing to recommend Reassurance, or a sign of thin data

An empty list means one of two very different things: everything is sized well, or there is not enough observed usage yet. A recently registered cluster is the second.

Walkthroughs

Act on a recommendation

  1. Cost › Resource Optimization, select the cluster.
  2. Read the recommendation and the workload it refers to.
  3. Change requests and limits at their source — in the chart or the deployment configuration — not by editing the live resource in Cluster Console. A live edit is overwritten at the next reconcile.
  4. Let the change deploy, then re-check after enough time has passed for usage to be observed again.

Decide what to ignore

Not every recommendation is worth acting on. A workload that is over-provisioned by a small margin and sits on the critical path is correctly over-provisioned. Optimise the large, boring items first.

Scenario

Reducing cost without causing an incident.

The failure mode here is trimming a workload until it falls over under a load that has not happened yet.

  1. Cost › Cost Analysis first — find which cluster and which workloads dominate. Optimising something that is not costing you anything is wasted effort.
  2. Cost › Resource Optimization on that cluster.
  3. Sort your attention by size of saving, not by number of recommendations.
  4. For each candidate, check its criticality before trimming. A batch job can absorb tight limits; a user-facing service on the critical path should keep headroom.
  5. Apply the change at source, so it survives the next reconcile.
  6. Deploy to staging first and watch Environment Detail › Metrics. Memory limits trimmed too far show up as OOM kills, which look like unrelated crashes.
  7. Only then apply to production, and re-check the numbers a week later.

Step 6 is the one that separates a saving from an incident. A recommendation is computed from past usage, and past usage does not include your next traffic peak.

When it doesn’t work

Symptom Cause How to check Fix
Cost is not in the sidebar No environment tier access Access Explorer Ask for access to a tier
No recommendations at all Everything is well sized, or usage data is thin How long the cluster has been registered Wait; a new cluster has little history
A change had no effect It was made on the live resource and reconciled away Cluster Console Change it at source
Workload started crashing after trimming Limits cut below real peak usage Environment Detail › Metrics Raise the limits; OOM kills look like unrelated crashes
Recommendations disagree with what you see They are computed from observed usage over time The metrics Treat as directional, not authoritative

Next