Approach | Rubric Advisory

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.

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. Three settings that each looked reasonable in isolation, interacting to produce a permanently warm warehouse. The written finding was that no one owned the warehouse and the scheduler as a single object. Documented in the vendor's own guidance; not documented in anyone's runbook.

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 mechanism has been in the AWS pricing page for years. The written finding was that the network path had never been reviewed against the workload's traffic pattern, and the resulting charge sat on the bill as ordinary data-transfer cost. Nobody was looking for it because nobody owned the intersection of workload design and network cost.

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. The pattern is on the first page of every ORM's performance guide. The written finding was that the team had escalated to infrastructure spend before anyone had run EXPLAIN on the controller's actual query plan. The database was the assumed cause. The absent habit of query-level diagnosis was the real one.

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%. The Kubernetes documentation is explicit that requests should track measured usage. The written finding was that the platform team owned the template and the product teams owned the workloads, and no one owned the reconciliation between the two.

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. Every observability vendor documents this exact trap in their pricing model. The written finding was that metric-tag additions were treated as a code change and reviewed accordingly, but the billing consequence of a metric-tag addition was invisible until the invoice arrived. The gap was a cost-review checkpoint at the point of merge, not a vendor conversation at the point of billing.

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. The written finding was that the SaaS portfolio had never been treated as an architectural surface. Each purchase had been rational in isolation; the shape of the whole was accidental.

The cause engineering leaders identify is not usually the cause.

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

Six symptoms. Two very different readings.

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