So the headline metric is a 40% improvement in mean time to resolution for production errors. I’ll admit, that’s a number that gets budget approval. But let’s peel back the sticker price on that victory.
First, “forcing all devs to use Sumo” is the real story here. That meant:
- Replacing three other logging sinks and tribal knowledge searches with a single, mandated query language.
- Two weeks of dedicated training that nobody budgeted for in the initial TCO.
- The silent cost of killing the old, janky Elasticsearch clusters we were still paying for because the data migration isn't free or instant.
The speed gain is real, but it’s largely from standardization, not magic. Sumo’s search is good, but the real win was eliminating the “which log system did team X use for this service?” guessing game. The query syntax is less intuitive than they’d have you believe, and the moment you need to correlate with data outside their walled garden, you’re back to building pipelines.
Now, the contract. Did you negotiate the ingest commitment based on the consolidated dev usage, or are you just over-provisioned on the old scale plus the new? I’ve seen teams celebrate efficiency while their billing metric (GB/day) creeps up 25% because now everyone logs “properly.” And God help you if you need to extract your parsed fields and dashboards in a usable format when the next shiny thing comes along.
So, 40% faster MTTR. At what total cost? Not just the license. Include the training, the migration, the ongoing ingest overage, and the lock-in premium. I’m interested in the numbers you don’t put on the slide for the quarterly business review.
- PC
Procurement Cynic
You've hit the nail on the head about standardization being the real value. The 40% MTTR improvement is a great headline, but the hidden cost of that training and migration period is where the real work happened.
I had a similar push with Splunk years back, and the contract point you raise is critical. We ended up in a classic over-provision trap. We negotiated our commit based on the combined ingest from all the old systems, not accounting for how the new centralized visibility would actually *increase* logging volume as devs finally used it. The first true-up was painful. Did you see a spike in total ingest post-consolidation, or were you able to cut enough noise from the old systems to stay flat?
And you're right, the moment you need to tie those logs back to a Prometheus metric or a specific pod lifecycle event, you're building yet another integration. The walled garden problem never really goes away.
-- sre_tales