Rubric Advisory
Approach

The cause engineering leaders identify is not usually the cause.

Two views into what an experienced read tends to find. First, the gap between assumed and actual root causes on the symptoms that repeat across engineering environments. Then, six configuration mistakes drawn from real production systems, each named with the mechanism and the fix.

Why now

The easy savings are gone. What remains needs deeper experience.

The current industry read is unambiguous. Flexera's 2026 State of the Cloud report estimates that 29% of cloud spend is wasted, and, for the first time in five years, the number is rising rather than falling. The reversal is driven by AI workloads and modern services outpacing the governance practices that were built for simpler infrastructure.

The FinOps Foundation's practitioner community reaches the same conclusion from a different direction. The easy waste has already been picked up by rate optimisation and reserved commits. The remaining savings live in architecture, workload design, code and vendor strategy. That work needs someone who has spent a career operating the systems in question, not a dashboard alert.

Sources: Flexera, 2026 State of the Cloud Report (flexera.com). FinOps Foundation, State of FinOps 2026 (data.finops.org).

Root cause vs assumed cause

Six symptoms. Two very different readings.

The middle column is what engineering leaders typically conclude. The right column is what a senior read tends to actually find. The gap is where the money and the year go.

Symptom
What engineering leaders typically conclude
What the senior read usually finds
Cloud bill is up 40% this year.
Cloud pricing has increased. Time to negotiate a bigger commit.
A handful of services (network gateways, cross-zone transfer, an unattended data pipeline) drive most of the growth. Contract terms are rarely the cause.
The dashboard is slow. Database is at fault.
Scale up the database instance. Add read replicas. Buy performance tier.
The application is issuing hundreds of small queries per page-load, or key indexes were never added on high-cardinality columns. The instance was fine.
The AI initiative is stalled.
The model needs more evaluation, or the data-science team needs headcount.
The data plumbing beneath the initiative has three owners and no clear pipeline. The model choice is a distraction; the substrate is the problem.
Container cluster is running hot.
Need more nodes. Provision aggressively for peak.
Pod resource requests were copy-pasted from a template and bear no relation to measured usage. Real CPU sits in the single digits while the scheduler thinks the cluster is full.
Observability tool bill has tripled.
Renegotiate the contract. Or switch vendors.
A single unbounded tag on a high-volume metric created a cardinality explosion inside two weeks. The mechanism, not the vendor, is the story.
Delivery has slowed. Team seems demotivated.
Team needs process. Add a scrum master. Redo the retros.
Structural mismatch between how work arrives, who owns the platform, and how success is measured. Process is downstream of shape.
What we typically find

Six configuration mistakes that hide in plain sight, until the invoice arrives.

Composites drawn from real patterns we have seen in production systems. Each names a specific mechanism, the shape of the mistake, and the fix. Anonymised because the organisations concerned would recognise themselves. Grounded in publicly documented behaviour of the underlying platforms.

01
Data warehouse

An M-sized warehouse, an auto-suspend timer at 60 minutes, and a scheduler firing every 55.

A finance team scheduled a light hourly refresh against a Snowflake warehouse sized Medium (4 credits per hour). The warehouse was created with the default 10-minute auto-suspend, then bumped to 60 minutes "to keep the cache warm". The scheduler ran every 55 minutes. Net effect: the warehouse never suspended. It billed continuously for weeks, for a job that used roughly 90 seconds of actual compute per run. The fix was two settings changes: AUTO_SUSPEND = 60 and downsize to Small. Same query performance, roughly one-tenth the credits.

Grounded in: Snowflake, Warehouse considerations (docs.snowflake.com). Pattern documented at Select, Snowflake Cost Optimization (select.dev).

02
Cloud network

S3 traffic routed through a NAT Gateway that did not need to touch it.

A private-subnet application read from S3 in the same region hundreds of times per minute. Every byte flowed through a NAT Gateway priced at $0.045 per GB of data processing, on top of the hourly NAT charge. S3 access from the same region and same account is free through a Gateway VPC Endpoint, which costs nothing to run. The line of Terraform to add the endpoint took two minutes to write and removed a five-figure annual charge that nobody had noticed because it looked like ordinary data-transfer cost on the bill.

Grounded in: AWS, Amazon VPC Pricing (aws.amazon.com/vpc/pricing) and CloudZero, AWS NAT Gateway Pricing (cloudzero.com).

03
Database

An ORM issuing 400 queries per page-load, and everyone blaming the database.

A dashboard was slow. The internal team spent a quarter tuning Postgres: bigger instance, more RAM, aggressive shared_buffers, an unhappy CFO. The actual cause was a Rails N+1 in the dashboard controller. One page request generated roughly 400 small selects because the association was not eager-loaded. Adding .includes(:organisation, :owner) cut the query count to under ten and page latency by an order of magnitude on the original instance. The database was not the problem; the query count was.

Grounded in the ORM N+1 pattern, well-documented across Rails and Django ecosystems. See PostgreSQL, Using EXPLAIN (postgresql.org) for the mechanism.

04
Container orchestration

Every pod requesting 2 CPU because the template said so, using 0.05.

A production cluster ran hot at scale-out time even though the underlying nodes were nearly idle. The cause was a copy-paste Helm chart that set resources.requests.cpu: 2000m for every service, whether it was a customer-facing API or a small cron worker. Kubernetes scheduled based on requests, not actual usage. Nodes filled up on paper while their real CPU sat around 5%. Right- sizing the requests against measured usage cut the required node count by more than half, without touching a single line of application code. CAST AI's cross-provider measurements show this pattern is the rule, not the exception.

Grounded in: CAST AI, 2026 State of Kubernetes Optimization Report (cast.ai). Kubernetes docs, Managing Resources for Containers (kubernetes.io).

05
Observability

A single request_id tag on a request counter tripled the monthly bill.

An engineering team added request_id as a tag on their HTTP request counter to help debug an issue. Every unique request created a new billable time-series. Custom metrics that had been a few thousand ballooned into the millions inside two weeks. The next invoice was three times the previous month's. The fix was to remove the unbounded tag and use logs and traces for per-request investigation. The underlying platforms are honest about this: any tag with unbounded cardinality (user_id, request_id, session_id) on a metric is a billing incident waiting to happen.

Grounded in: Datadog, Metrics without Limits billing model (docs.datadoghq.com). Real-world writeup: Sysdig, Did Your Datadog Bill Explode? (sysdig.com).

06
Vendor stack

Four project trackers, three analytics tools, two CRMs, and nobody with the map.

A growing team of 40 people had 138 software applications on subscription. Nine were paid seats for departed employees still on annual auto-renew. Two were enterprise-tier plans bought for a feature the team no longer used. Four were overlapping project trackers, one per functional group. A written audit against actual usage, contract renewals and org-chart ownership recovered enough budget to fund a full engineering hire for the year. Nothing about the audit was clever. It was a spreadsheet, a stack of contracts, and someone senior enough to have the difficult conversations about which tools to sunset.

Grounded in: Zylo, 2026 SaaS Management Index (zylo.com). Portfolio size averages 305 apps at typical mid-market scale.

Connect

See yourself in any of the above?

The first conversation is with the advisor directly, at no cost. Bring the call in front of you.

Start a Conversation →