The cases below are real. We have anonymized them: no client, no industry, no date.
Case 1: an application delivered without a scoring session
A few weeks after go-live, the application owner discovers the bill. Two findings: the sandbox, development and test environments consume as much as production, and a single SQL database accounts for 80% of the cost.
What was done: the sandbox was deleted, the database downsized or disabled in every non-prod environment. Result: −62% on the application's bill, with simple actions.
Case 2: a new feature, no re-estimation
An application team contacts the FinOps team: they suspect a billing error. Their costs have doubled in six months. There is no error: a new feature drove consumption up, and nobody re-estimated the cost after it was rolled out.
Case 3: a data lake migration, and no alert
The FinOps team urgently calls an application owner: costs have been multiplied by 40. The owner had no idea. The cause: a poorly configured migration to a new data lake generation, and no budget alert on the scope.
Case 4: logs enabled in non-prod
The maintenance team enables verbose logs on the test and pre-production environments. In two weeks, costs are multiplied by 6. The team running the application only notices at the second alert.
What was done: unnecessary logs disabled, a validation rule for configuration changes. About €240k a year avoided.
Case 5: stuck data pipelines
A bug in a processing function leaves Data Factory pipelines stuck in a loop. The daily cost climbs day after day. On another application, far too frequent triggers forced a redesign before go-live.
What these cases have in common
| Cause | Fix |
|---|---|
| No review before go-live | Scoring session at go-live |
| A change that wasn't re-estimated | Re-estimation at every significant change, checked a few days later |
| Nobody is notified | Budget alert per scope, sent to the application owner |
| A monthly alert, too late | Daily monitoring of anomalies and the forecast |
| Non-prod isn't monitored | Same alerts as prod, validation of configuration changes |
One last point, often misunderstood: a budget alert warns but stops nothing. It only helps if someone receives it, knows what to look at and can act the same day. That is why we always pair it with a response loop: detection, alert, analysis, fix, then follow-up at the SteerCo.