How I Helped Fix a New Relic Library Bug and Cut Mobile Observability Costs

When your company migrates to a new framework like Flutter, it’s not just the UI that changes — your tooling, observability, and even your costs shift too.

In this article, I’ll walk you through how I:

• Identified a cost inefficiency in our mobile observability strategy,
• Helped guide a shift from custom events to custom metrics using New Relic,
• And eventually collaborated with New Relic to uncover and fix a bug in their Flutter agent — improving stability for all users of the SDK.

This was a deeply satisfying project that combined cost optimization, cross-team collaboration, and a bit of open-source spirit — all without compromising data quality.

1. The Problem: When Observability Becomes Too Costly

After migrating parts of our mobile app to Flutter, we began increasing observability coverage to maintain quality and detect issues faster. But we soon noticed something concerning: our observability costs were ballooning, especially due to high-frequency custom events tracked through New Relic.

Custom events were being used to track interactions and states that didn’t always require such high cardinality. And in New Relic, more events = more dollars.

2. The Solution: Use Metrics When Events Are Overkill

I proposed a shift in strategy — use custom metrics instead of custom events in places where we just needed lightweight tracking (e.g., counts, durations, statuses).

This change alone led to a significant drop in cost without sacrificing visibility. We created a simple wrapper around the New Relic mobile SDK, making it easier for teams to send metrics instead of events.

3. The Unexpected Bug in the SDK

But while implementing this on Android, we hit a wall:
Some metrics were simply not showing up, while others seemed inconsistent.

After ruling out common implementation issues, I suspected something deeper. I reached out to New Relic support, described our use case, and provided reproducible scenarios.

Turns out, there was a bug in the New Relic Flutter Agent, affecting how custom metrics were being handled on Android in specific flows.

4. Collaborating with New Relic to Fix the Bug

I worked with New Relic engineers to debug the issue. I followed their guidance to create a minimal proof of concept that isolated the problem. This helped their team identify the root cause and confirm it was a bug in their SDK.

A few weeks later, they released an updated version of the agent that fixed the issue. I helped test the new release and validated that everything worked as expected.

https://pub.dev/packages/newrelic_mobile/changelog#113

5. The Results: Lower Costs, Better Visibility, Stronger SDK

🔧 Helped fix a production bug in a widely used SDK.

💸 Significantly reduced observability costs by replacing events with metrics.

🧩 Unblocked multiple mobile teams migrating to Flutter.

📈 Improved confidence in our observability stack, even post-migration.

6. Takeaways

• Sometimes, using the right tool (metrics vs. events) is not just a matter of engineering best practices — it’s a business decision.
• Vendor tools are not always perfect. Don’t be afraid to engage with their support and dig deeper.
• Collaboration with external teams can be surprisingly rewarding and impactful.