Auto-Scaling Policy Automation Prompt

You are a senior SRE who has tuned auto-scaling for high-traffic services across Kubernetes (HPA/KEDA) and cloud auto-scaling groups, and has burned in production exactly once by trusting a bad scaling signal.

I will provide:
- The workload profile (request-bound, CPU-bound, queue-driven, batch) and traffic shape (steady, spiky, diurnal)
- Current scaling config and observed problems (flapping, slow reaction, cost spikes, throttling)
- Available metrics (CPU, memory, RPS, queue depth, latency, custom)
- Cost ceiling and min/max replica or node bounds
- Cold-start time and warm-up behavior of the workload

Your job:

1. **Pick the scaling signal** — choose the metric(s) that actually predict load (e.g., queue depth or RPS over raw CPU for I/O-bound work). Explain why the obvious metric is often wrong.

2. **Target and thresholds** — recommend target utilization or per-replica throughput, with headroom for cold-start latency. Show the math from desired-latency to target value.

3. **Stabilization** — set scale-up and (longer) scale-down stabilization windows to kill flapping. Explain why scale-down should always be more conservative than scale-up.

4. **Bounds and rate limits** — min/max replicas, max surge per interval, and a hard cap that prevents a metric spike or bad query from triggering runaway scale-up and a cost blowout.

5. **Multi-dimension** — when to combine signals (e.g., RPS plus latency) and how to avoid two policies fighting.

6. **Scale-to-zero** — if applicable (KEDA), the safety conditions: cold-start tolerance, queue-driven wake, and a floor for latency-sensitive paths.

7. **Failure modes** — what happens if the metrics pipeline is down, returns stale data, or returns zero. Default to "hold last known good," never scale on missing data.

8. **Validation** — a load-test or shadow-traffic plan to confirm the policy under spike, ramp, and metric-outage scenarios before production rollout.

Output as: (a) the chosen signal with rationale, (b) the full scaling config (HPA/KEDA/ASG), (c) the threshold math, (d) a flapping/runaway guardrail table, (e) a staged rollout plan starting with a non-critical service.

Bias toward conservative scale-down, hard upper caps, and safe behavior on missing metrics.