How a Medical Technology Company Reduced Log Volume by 94% While Maintaining Reliability

AI-Powered Diagnostics at Scale

One of our customers, working in the medical technology space, uses AI to create personalized, non-invasive analysis of certain diseases. Their platform processes complex imaging data and delivers actionable clinical insights to doctors and their patients. Like most modern SaaS platforms, their engineering infrastructure runs across multiple services, and with that scale comes the cost of observability.

The medical technology company’s engineering team had standardized on Datadog, giving them the monitoring, logging, and the visibility they needed to operate reliably in a high-stakes healthcare environment. But as the platform grew, so did the volume of telemetry data flowing into Datadog, as did their Datadog bill.

The Problem: Observability Cost Growth Was Unsustainable

The company knew they were spending too much on Datadog. It had become a line item that was hard to ignore. Like most engineering-driven organizations, their first instinct was to self-host: build an internal observability stack on open-source tools running on AWS, using something like Grafana as the front end.

"Our thought process was to self-host as the option," said their Head of Platform. "But we knew that would take another six to nine months for a full rollout."

Self-hosting was interesting as a long-term direction, but it wasn't going to solve the cost problem now. And in the meantime, their observability bill kept climbing. They needed a way to reduce costs without disrupting the engineering workflows they’d already built with Datadog, and without pulling engineers off product work to refactor logging configurations service by service.

Finding Grepr at KubeCon

Their Head of Platform first encountered Grepr while walking the floor at KubeCon. The pitch was straightforward: Grepr sits between your telemetry sources and the observability tools you already use, intelligently reduces what gets forwarded to them, and stores everything else in your own S3 bucket at a fraction of the cost. No impacts to dashboards or alerts, and no migrations.

The ROI math was simple enough that the Head of Platform could evaluate it himself. "I had to convince myself first," he said. "And once I was convinced, it was easy." His internal bar was clear: Grepr needed to pay for itself starting in month one. If the net reduction in his Datadog spend exceeded the cost of Grepr from day one, the decision was a no-brainer: no business case document, no CFO presentation required.

Protecting Hundreds of Dashboards

Complicating any cost-reduction effort was the scale of what the team had built on top of Datadog. Over time, they had developed hundreds of dashboards directly tied to the clinical workflows and operational metrics the business depends on. These were not convenience tools–they were providing business-level insights in a high-stakes environment.

Rebuilding or rewriting those dashboards was not a viable option. It would have consumed engineering resources the team did not have to spare, and introduced risk into workflows that support patient care. Any solution that required touching those dashboards was a non-starter.

Grepr was built with this scenario in mind. Its query translation engine reads existing dashboards and alerts and automatically ensures the data they depend on is routed through. In this case, Grepr added the existing Datadog dashboards and alerts as pipeline exceptions, preserving every single dashboard without the need to rebuild anything. It took 10 minutes to check the boxes for all the dashboards and alerts they cared about.

Deployment: From POC to full rollout in weeks

The deployment followed a phased approach. Most of the implementation work fell to their lead engineer on the project, who worked directly with the Grepr team to configure the pipeline and validate the setup.

The technical lift was lower than expected. "It was fairly straightforward," he noted. "It was just a question of finding the right environment and putting in the right config." Initial approval and procurement processes took roughly two weeks, after which their team moved through a dev environment rollout before pushing to production.

Early results were promising but not yet at their peak. After a few configuration tweaks, primarily adjusting filters to account for how their team had structured Datadog, reduction climbed to 90% and beyond.

"We needed something to be built on your side," said their Head of Platform, "and you had a quick turnaround. That helped reduce the logs to the current levels." That responsiveness gave the team confidence to expand Grepr across the rest of their environments.

Results: 94% Reduction in Prod, Zero Engineering Disruption
‍

‍

The company is now seeing a 94% reduction in log volume in Prod. Critically, none of that reduction required changes to how engineers instrument or write code. One of the common fears we hear is losing visibility or access to data when you need it most. The company’s experience has been the opposite: engineers haven't noticed a change in their day-to-day workflows, alerts still fire correctly, their hundreds of dashboards still work, and when they need to go back to a specific log, it's in S3.

"I don't hear about anything, which means nothing has changed, which is exactly what I wanted," said their Head of Platform. "And now our costs have dropped."

Their longer-term plan is still to explore moving towards a self-hosted observability stack, and Grepr remains part of that picture. Even as they consider migrating away from Datadog, they see Grepr as a tool for keeping signal quality high and storage costs low in whatever stack they land on next.

Want to see what Grepr can do for your observability bill? Get started free and see results in under 30 minutes.

‍