Skip to main content

Optimize Infrastructure Costs

Scenario​

Your cloud bill keeps growing but you are not sure which workloads are over-provisioned. You want resource changes that are based on real usage, not guesswork, and you want to review them before anything ships.

How OpsWorker Helps​

Resource Optimizer​

The Resource Optimizer is OpsWorker's cost-focused chat agent. You trigger it manually from the AI SRE Chat (for example, by asking it to right-size a deployment). It is available only when the cluster has both the cluster and metrics capabilities connected.

Here is what it actually does:

  • Pulls live metrics via Grafana MCP so recommendations are based on actual CPU and memory utilization, not static config alone.
  • Right-sizes the CPU request, memory request, memory limit, and HPA settings.
  • Never recommends a CPU limit. If a workload already has a CPU limit, the optimizer may recommend removing it, because a CPU limit can throttle workloads unnecessarily. It will not set one.
  • No-op when already close. If a value is within roughly 15% of the current setting, the optimizer leaves it alone rather than churning manifests for marginal gains.
  • Opens a PR or MR only after you confirm. Once you approve, it opens a GitHub pull request or GitLab merge request with the right-sized manifest. If confidence is not high, it opens the change as a draft. OpsWorker never merges on its own; a human reviews and merges.

Example​

You: Right-size the payment-api deployment in production.

OpsWorker (Resource Optimizer): Based on the last 7 days of Prometheus
metrics:
- CPU request: 500m -> 250m (p95 usage ~180m)
- Memory request: 512Mi -> 384Mi
- Memory limit: 512Mi -> 512Mi (within ~15%, unchanged)
- Existing CPU limit (500m): recommend removing to avoid throttling
Open a pull request with these changes?

After you confirm, the optimizer opens a PR or MR (draft if confidence is low) with the updated manifest and returns the live URL in the chat turn.

Investigation-Driven Insights​

Alert investigations can also surface inefficiencies as a side effect. A pod that keeps OOMKilling or crash-looping wastes compute every restart, and the investigation will call that out. Fixing the root cause removes recurring waste, separate from any right-sizing work.

Outcome​

  • Usage-based right-sizing of CPU request, memory request, memory limit, and HPA, driven by live Grafana metrics.
  • Safe by design: no CPU limits are ever set, changes ship as a reviewable PR or MR, and near-current values are left untouched.
  • Human in the loop: nothing changes in your cluster until you merge the proposed manifest.
  • Less recurring waste: fixing investigated crash loops removes compute burned on restarts.