Why not just over-provision by 2x and call it done?

You’ll pay a 50–100% tax forever, and you’ll still get paged when contention, GC pauses, or retries explode. Over-provisioning hides problems; it doesn’t eliminate tail latency, queue growth, or error budget burn during deploys.

Is CPU ever a good autoscaling signal?

It’s fine as a backstop and for CPU-bound batch work. For request/streaming services, concurrency, queue lag, and tail latency correlate much more strongly with incident onset.

How do we get sustainable concurrency per pod?

Run a load test that steps RPS until p99 or errors violate your SLO. Record the last good point as sustainable. Repeat on code/infra changes. Store the number in Git so policies can use it.

Do we need service mesh to do this?

No, but Envoy/Istio/Linkerd make it easier to get per-pod inflight and connection metrics and to enforce circuit breakers. Start with app-level metrics; upgrade later if you need L7 controls.

Our dashboards were generated by AI and look impressive. Should we keep them?

If they don’t predict or confirm incidents, they’re vibe art. Keep six panels: error rate, p95/p99, inflight, queue depth/lag, GC pause ratio, and burn rate. Delete the rest. GitPlumbers can help with vibe code cleanup and AI code refactoring in the telemetry path.

Reliability-observability · Nov 15, 2025 · 10 minute read

Stop Staring at CPU: Capacity Models That Predict Incidents Before They Happen

Leading indicators, not vanity graphs. Tie telemetry to triage and rollout automation so you scale before users feel pain.

Back to all posts

Stop Staring at CPU: Capacity Models That Predict Incidents Before They Happen

Key takeaways

Implementation checklist