There's a particular kind of crisis that doesn't show up in your error budget. No pager fires. No SLO breaches. Just a Slack message from someone in finance, forwarded through two layers of management, arriving on a Tuesday afternoon with the subject line: "Re: Fwd: Cloud spend — urgent." The number in the body is wrong. It has to be. Except it isn't.
I've been in that room more than once. And what strikes me, looking back, isn't the overage itself — it's how long the conditions that produced it had been hiding in plain sight, legible to anyone watching the right instruments, invisible to everyone watching the wrong ones.
The organizational separation that created this problem made a certain kind of sense for a while. FinOps teams grew out of finance functions — their job was reservation utilization, committed use discounts, savings plan coverage ratios, the actuarial work of cloud spend. SRE teams grew out of operations — their job was error budgets, latency SLOs, on-call rotations, blast radius containment. Different cadences, different vocabularies, different stakeholders. The seam between them felt manageable.
What nobody adequately modeled was the coupling. Cost is not a financial abstraction sitting beside your technical system — it is your technical system, denominated in dollars. Every architectural decision you make has a cost coefficient. Retry policies. Cache TTLs. Replication factors. Autoscaling thresholds. The provisioned concurrency you set on a Lambda function because cold starts were unacceptable. All of it. And when you manage cost separately from reliability, you introduce lag — sometimes weeks of lag — between a decision and its financial consequence, which is exactly the kind of feedback loop that lets problems compound quietly until they're no longer quiet.
Let me walk through how autoscaling actually behaves, because the simplified mental model is where a lot of this goes wrong.
The standard framing — scale out when CPU crosses some threshold, scale in when it drops — obscures a deliberate asymmetry built into every major cloud provider's autoscaling implementation. Scale-out is fast, because the provider's incentive is aligned with yours: you're both losing if your service falls over. Scale-in is conservative, padded with cooldown windows and stabilization periods, because thrashing — rapidly oscillating between instance counts — is worse than mild overprovisioning. This asymmetry is correct engineering. It's also a cash register that runs in one direction faster than the other.
A traffic spike hits. You scale from twenty instances to sixty in eight minutes. Traffic subsides. Over the next four hours, your fleet draws back down — not immediately to twenty, but through a series of gradual steps, each gated by a cooldown period, each step requiring the prior stabilization window to expire. During those four hours, you're running forty-five, then thirty-eight, then twenty-nine instances, each billing at the per-second rate. Nobody's SLO is in danger. Nobody gets paged. The bill accumulates.
Multiply this by a fleet of microservices, each with its own autoscaling configuration, each with its own traffic pattern, and the aggregate overhang can be substantial — tens of thousands of instance-hours per month that represent not capacity in use but capacity waiting to be released. This isn't a bug. It's the expected behavior of a system tuned to prioritize availability. The question is whether you know it's happening and have made a conscious decision about the acceptable cost, or whether you've just never looked.
Scale-in aggressiveness is tunable, and most teams leave it at defaults. Defaults are conservative. Tightening scale-in parameters reduces the overhang but increases thrashing risk, so you need to understand your traffic variance before you touch it. That said: understanding your traffic variance is table stakes. If you don't have a clear picture of your p5-to-p95 request rate ratio by time of day and day of week, you're not really operating your system — you're supervising it loosely and hoping.
The failure mode that keeps me up more than runaway scaling is the budget-driven right-sizing panic, because it introduces fragility that's structurally invisible until it fails under pressure.
Here's the sequence. The overage appears. Leadership mandates cost reduction. Someone — maybe an SRE, maybe a cloud architect, maybe a well-meaning platform team — runs a utilization analysis showing that average CPU across the fleet is 22%, which is, frankly, low. Instances get downsized. Node counts get reduced. Memory limits get tightened. Everything looks fine in staging. Everything looks fine in the first week of production. Then a traffic event hits — a product launch, a viral moment, an upstream partner pushing an unexpected batch — and the headroom that used to absorb the burst isn't there. Autoscaling kicks in, but provisioning a new node takes ninety seconds, and your p99 latency has been above SLO for forty-five of those seconds already. You're in a partial brownout. The postmortem will attribute it to "insufficient headroom during traffic surge." It will not attribute it to the budget meeting six weeks prior, because nobody drew that line. But the line is there.
This is why reliability and cost need to be managed in the same room, by people who understand both. Not because the answer is always "spend more" — it isn't — but because the trade-offs are genuinely coupled and you cannot reason correctly about one without modeling the other.
There's a diagnostic failure mode on the overprovisioning side that's subtler and, in my experience, more insidious.
Heavy spare capacity doesn't just cost money. It hides pathology. A database query with a missing index that, on a correctly sized system, would cause visible queuing — requests stacking behind the slow operation, p99 climbing, engineers noticing and investigating — produces no observable signal on a system with three times the necessary compute. The buffer absorbs it. The bug persists. Traffic grows into the buffer over the following months, and then one day the query that was always slow starts causing timeouts at a scale you haven't seen before, and the postmortem team is baffled because nothing changed recently. Except that nothing changed recently is precisely the problem. The fix was overdue by a year.
Overprovisioning, held long enough, creates systems that are only apparently healthy. They perform adequately under current load because of margin, not because of correctness. That distinction matters enormously when load grows or margin gets cut.
What makes cost a genuine observability problem — and not just a financial reporting problem — is that spend anomalies often surface before reliability anomalies do, if you're watching the right signal.
Consider a retry storm. A dependent service begins degrading — maybe a database replica is lagging, maybe a third-party API is rate-limiting more aggressively than usual. Upstream callers begin retrying failed requests. The retry traffic amplifies load on the already-struggling dependency. The dependency slows further. More retries. The cascade is building. At this point, if you're watching error rates on the upstream service, you might see elevated failures — or you might not, if the service is retrying internally and presenting a success to the caller after the third attempt. What you will see, if you're watching per-service spend, is a spike in compute and network egress that's disproportionate to the throughput you're actually delivering. Requests are being processed expensively and largely unsuccessfully. The cost-to-throughput ratio is the signal. It diverges from baseline before the user-facing failure manifests.
Memory leaks work similarly. A service with a slow heap inflation — the kind that takes days to become critical — will, over that time window, be scheduled progressively more memory by the orchestrator. On Kubernetes, this means the pod's resource requests may be underestimating actual consumption, which causes the scheduler to pack more pods onto nodes than the nodes can actually support, which surfaces as evictions and restarts that look transient and benign. But the per-pod compute cost is climbing. If you're tracking cost-per-replica by service over a trailing seventy-two hours and you see a monotonic increase that isn't explained by increased traffic, something is consuming resources it shouldn't. The leak might not produce an outage for another week. The cost signal is early.
This is what I mean when I say cost telemetry belongs in your observability stack, not in a separate FinOps dashboard that someone reviews in a monthly sync. The value is in the correlation, and correlation requires co-location.
The tagging problem is unglamorous and unavoidable.
Without granular resource tagging — by service, by environment tier, by owning team, enforced at provisioning time — your cost data is a single undifferentiated number. You know money is leaving; you don't know where it's going. This is exactly as useful as knowing your application has errors without knowing which service is throwing them. You can't alert on it meaningfully. You can't attribute it to a team. You can't correlate it with a deployment.
Most mature organizations have tagging policies. Fewer enforce them. Enforcement requires that your provisioning pipeline — Terraform, Pulumi, CloudFormation, whatever you're using — validates tag presence as a pipeline gate, not as a convention that relies on human memory under deadline pressure. The implementation is not complicated. A handful of lines in your CI configuration, a policy-as-code rule in OPA or Sentinel, whatever fits your toolchain. The friction is retrofitting it onto existing resources, which requires a tagging sprint that someone has to prioritize and nobody wants to, because it produces no visible user-facing value and takes meaningful engineering time. Schedule it anyway. The operational leverage is significant.
The structural move that I think is most underutilized is treating cost as a formal SLO dimension — not metaphorically, but with the same apparatus you apply to availability or latency.
Error budgets, in their classical formulation, are a mechanism for making reliability trade-offs explicit and time-bounded. You have a certain amount of unreliability you're allowed to burn in a given window; when you've burned it, the policy kicks in and constrains what changes you can make. The mechanism works because it converts a fuzzy organizational negotiation — how reliable is reliable enough? — into a concrete number with teeth.
The same mechanism extends to cost. A service has a cost budget, expressed as cost-per-request at steady state, with a defined tolerance for burst. When actual spend diverges from that budget by more than the tolerance — say, over a rolling seven-day window — it's a budget burn event. It goes in the same tracking system as your error budget burns. It informs sprint planning. It creates organizational memory about which services run over budget and why.
This requires, upfront, that someone actually defines the numbers — not "keep costs reasonable" but a concrete target with a concrete tolerance. That conversation is uncomfortable the first time you have it, because it exposes that most teams have no idea what their infrastructure should cost at a given load level. The discomfort is diagnostic. Having the conversation is more valuable than the number you arrive at.
What changes Monday morning, concretely.
Enforce tagging in the provisioning pipeline — validation, not convention, starting with new resources immediately. Existing infrastructure gets a scheduled remediation sprint; book it now even if it's six weeks out, because the alternative is it never happening.
Pull billing API data into your existing metrics platform — not a separate tool, the same Grafana or Datadog instance where you're already looking at latency and error rates. Per-service cost dashboards, colocated with performance data. The co-location changes behavior in a way that separate tooling doesn't; engineers notice cost when they're already debugging something else.
Write anomaly-based cost alerts, not threshold alerts. A static monthly ceiling is too coarse and triggers too late. You want: when a service's hourly spend rate deviates significantly from its trailing seven-day baseline, page the team that owns the service. Not finance. The service owner.
Identify your top three right-sizing candidates by pulling thirty-day average utilization data. If anything is running below 20% average CPU, understand the burst profile before touching it — low average with high variance is a different situation than low average with low variance — but understand it. Don't let inertia make the decision.
Finally, next time you're writing a retry policy, price it explicitly. Under partial failure conditions, with your actual error rate and your actual request volume, what does this backoff configuration cost? Exponential backoff with jitter is correct as a general principle; it is not a substitute for thinking through the cost implications of your specific failure modes at your specific load.
The teams that handle this well have usually just made one shift that sounds small and isn't: they stopped treating the billing console as someone else's responsibility. Everything follows from that.