Your First 30 Days with Attune

This guide walks you through what to expect after installing Attune, from the initial data collection to full automation. Each phase builds confidence before moving to the next.

Day 0: Install and create your first policy

After installing the operator, create a AttunePolicy targeting a non-critical workload:

apiVersion: attune.io/v1alpha1
kind: AttunePolicy
metadata:
  name: my-first-policy
  namespace: my-app
spec:
  targetRef:
    kind: Deployment
    name: my-api
  metricsSource:
    prometheus:
      address: http://prometheus-server.monitoring:80

Verify the operator is running and picked up your policy:

kubectl attune status -n my-app
# Without the plugin:
# kubectl get attunepolicy -n my-app

You should see your policy with Ready showing InsufficientData or a progress message like Collecting data: 0/48 data points (0%). This is normal.

Verify operator config

Check the operator logs to confirm it started with the right settings:

# Helm release name "attune" → Deployment "attune".
# Raw manifests use "attune-controller-manager" instead.
kubectl logs -n attune-system deploy/attune | head -5

The first line shows all configured parameters (Prometheus QPS, watch namespaces, webhooks, etc.).

Hours 0-4: Data collection

The operator queries Prometheus every 5 minutes (default queryStep) and needs 48 data points (default minimumDataPoints) before generating recommendations. This takes roughly 4 hours.

Watch progress live:

kubectl attune status -w -n my-app

What to check during this phase:

• Ready shows NoWorkloadsFound? Your targetRef.name or kind doesn't match any workload. Check spelling and namespace.
• Ready shows PrometheusUnavailable? The operator can't reach your Prometheus instance. Verify the address and network policy.
• Progress percentage is climbing? Everything is working. Wait for it to reach 100%.

Quick evaluation

For a faster first look (~1 hour), set minimumDataPoints: 12 in your policy. See the quickstart for details. Remove it before going to production.

Day 1: First recommendations

Once data collection completes, the policy transitions to Ready=Monitoring and recommendations appear:

kubectl attune recommendations -n my-app

This shows current vs recommended resource values with a confidence score. Low confidence (< 70%) means the operator hasn't seen enough variance yet; it will improve over the coming days.

To understand why a specific recommendation was made:

kubectl attune explain my-first-policy -n my-app

This traces the full recommendation pipeline: raw percentile, safety margin, confidence adjustment, bounds clamping, and change filter.

Days 1-7: Build trust in Recommend mode

During the first week, check recommendations daily:

kubectl attune recommendations -n my-app
kubectl attune savings -n my-app

Look for:

• Confidence scores increasing as more data is collected
• Recommendations stabilizing (not swinging wildly between checks)
• Savings estimates that make sense for your workload

If recommendations look unreasonable, adjust the policy:

• Recommendations too aggressive? Increase overhead (e.g., "30")
• Recommendations too conservative? Decrease overhead (e.g., "10")
• Don't want memory to decrease? Set memory.allowDecrease: false

Week 2: Promote to Canary mode

Once you trust the recommendations, switch to Canary mode to test on a small subset of pods. This is the blast-radius control step before Auto:

kubectl patch ap my-first-policy -n my-app --type=merge \
  -p '{"spec":{"updateStrategy":{"type":"Canary","canary":{"percentage":10,"observationPeriod":"30m"}}}}'

This resizes only 10% of matching pods, then observes them for 30 minutes. With autoPromote: true on the canary config, the operator promotes the rest after a clean observation window; otherwise promote to Auto yourself. See the canary rollout guide.

Monitor:

kubectl attune status -w -n my-app
kubectl attune history -n my-app

The history command shows each resize with its result and reason. If a resize is reverted, the REASON column tells you why (oomkill, restart, notready, throttle, or slo:<name> for SLO guardrail breaches).

Optional production hardening before Auto

• SLO guardrails: add PromQL checks so a bad resize reverts on latency or error-rate breach, not only infra signals. See the SLO guardrails guide and updateStrategy.sloGuardrails in the configuration reference.
• Startup boost: for JVM or other cold-start heavy apps, enable cpu.startupBoost so pods get temporary CPU headroom at start, then scale back. See the startup boost guide.

Warning

If you see repeated reverts, increase the overhead or adjust bounds before proceeding. See troubleshooting.

Weeks 3-4: Full automation

After successful canary resizes with no reverts, promote to Auto:

kubectl patch ap my-first-policy -n my-app --type=merge \
  -p '{"spec":{"updateStrategy":{"type":"Auto"}}}'

Now the operator manages resources continuously. Check savings:

kubectl attune savings -A

The TOTAL row at the bottom shows aggregate cluster-wide savings.

The production loop is: measure → recommend → canary apply → verify (safety + optional SLO) → revert if needed → continuous Auto. That is what distinguishes Attune from "apply via /resize only."

Expanding to more workloads

Once the first policy has been running in Auto mode for a week, expand by creating policies for more workloads. Use AttuneDefaults to set org-wide defaults (overheads, bounds) so individual policies stay minimal.

Quick reference: what to run when

When	Command	What you're checking
Just installed	kubectl attune doctor	Cluster is 1.32+ and lists pods/resize
Policy created	kubectl attune status -w	Operator picked up your policy
Waiting for data	kubectl attune status -w	Progress percentage climbing
First recommendations	kubectl attune recommendations	Values look reasonable
Understanding a recommendation	kubectl attune explain <policy>	Full pipeline trace
After enabling Canary/Auto	kubectl attune history	Resizes succeeding, no reverts
Monthly review	kubectl attune savings -A	Cluster-wide savings total