Five signs your cloud has outgrown your team

I get called when a symptom has become a pattern. Not the first surprise invoice or the first bad night, those are normal, but the third one, when it’s clear the problem isn’t an incident, it’s the system. After doing this across a healthcare startup, GoPro, a CVS/Aetna platform, and a high-scale SMS platform, the symptoms that send people looking for help are remarkably consistent, and each one points at a specific thing that never got built.

Here are the five I see most, roughly in the order they get noticed:

1. The cloud bill is growing faster than traffic.
2. Outages happen, get patched, and never get a real root-cause.
3. The infrastructure can’t scale under pressure, and everyone knows which service will fall over next.
4. Nobody can say what any team or feature actually costs.
5. A security or compliance audit failed, or one is coming and nobody’s ready.

Any single one of these is survivable and often self-inflicted in a way you can fix. Several of them at once, with no clear owner for the underlying system, is the actual signal. What follows is what each symptom usually means underneath, because the symptom and the disease aren’t the same.

The bill and the visibility problem are one problem

The first and fourth symptoms travel together, and they’re worth taking as a pair. A bill growing faster than traffic almost always means waste is compounding somewhere you can’t see, and the reason you can’t see it is the fourth symptom: no attribution. Flexera’s 2025 State of the Cloud report found organizations estimate 27% of their IaaS and PaaS spend is wasted, and 84% called managing cloud cost their top challenge. That’s the industry grading its own slack at better than a quarter.

You can’t cut what you can’t attribute, which is why the first engagement is always visibility before savings. I’ve held ~$4M a year flat at Postscript while traffic grew, and I once took a healthcare startup’s bill from ~$500K to ~$200K, and both started the same way: map every major line item to a team or a workload, then act. A team that has this instrumented rarely needs outside help on cost. A team whose bill is a single undifferentiated number almost always does, because the mystery is the problem.

Outages without root-cause are a process gap, not a luck problem

The second symptom is the one people most often misdiagnose as bad luck. It isn’t. Outages that get patched and never explained mean there’s no incident review with teeth, and without it the same class of failure recurs on a schedule nobody’s tracking. The fix isn’t heroics. It’s the boring machinery of reliability: real post-incident reviews, monitoring that catches the failure before a customer does, and the follow-through to close the gap the last outage exposed.

I took a platform from roughly 95% uptime to over 99.9% while cutting its cost in half, and none of that came from being smarter in the moment. It came from replacing hand-built, fragile infrastructure with things that fail predictably and recover on their own. If your outages are surprising, the surprise is the symptom.

The scaling and audit symptoms are deadlines in disguise

The third and fifth symptoms share a quality: they come with a clock. The service everyone knows will fall over does fall over, usually on your biggest traffic day, and the audit everyone’s been deferring arrives with a customer’s signature attached to it. Both are cheaper to fix before the deadline than during it, and both are the kind of work that’s hard to do while also keeping the lights on, which is exactly when outside help pays for itself.

The named service lines here are unglamorous and well-understood: Kubernetes stabilization for the cluster that pages, infrastructure-as-code for the click-built environment nobody can reproduce, security hardening and a compliance gap analysis for the audit. None of it is exotic. All of it is the work that got deferred while the team shipped features, and deferred work has a way of coming due all at once.

When you don’t need me

The honest version of this article has to include the other half: plenty of teams have these symptoms and shouldn’t hire anyone. If you have an engineer who owns the platform, the time to instrument the bill and run a real incident review, and the discipline to put your infrastructure in code, you can fix all five of these yourself, and you’ll understand your own system better for having done it. Outside help isn’t a substitute for that ownership. It’s what you reach for when the problem recurs, the knowledge is trapped in one person or nobody, and the team is too busy putting out fires to build the thing that would stop them starting.

The symptom that actually predicts needing help isn’t any one of the five. It’s all of them getting worse while everyone’s too busy to fix the cause.