iQmetrix Gains Full Visibility With Predictable Costs and No Tradeoffs

iQmetrix software sits at the center of how telcos, retailers, and OEMs sell, activate devices, and process payments. With 27 years of product history, the company operates hundreds of services across complex environments of legacy systems and modern infrastructure, all running on Microsoft Azure and .NET. At that scale, visibility into production is the foundation everything else depends on.

The team's existing tooling was not delivering the visibility the team needed. Incident analysis took days—sometimes weeks—and 36% of incidents could not be resolved to a root cause.

Clients were also detecting problems first. Around 64% of incidents were reported by customers before engineering caught them. For a team committed to delivering great client experiences, the detection gap was a clear signal that something had to change.

With unpredictable costs and alerting too noisy to trust, iQmetrix needed observability they could rely on. Observability that could:

• Pinpoint root cause quickly across hundreds of services, without deep prior knowledge of each one
• Produce reliable, actionable alerts that the on-call team could trust
• Support OpenTelemetry to avoid vendor lock-in as the environment evolved
• Scale data richness with predictable costs so teams could ask better questions without worrying about the bill

The team evaluated several alternatives and chose Honeycomb, attracted not only to the product’s capabilities, but also to the depth and passion of the Honeycomb team.

"When Honeycomb came to the table, they were actually interested in solving our problems. It felt collaborative in a way that made a real difference," said Brenden Petracek, Observability Team Lead.

The switch to Honeycomb aligned with a broader move to OpenTelemetry, an open standard that gave development teams confidence they would not be locked into a single vendor as the environment evolved.

To track progress, iQmetrix introduced a metric to track the percentage of incidents identified internally versus reported by customers. Before adopting Honeycomb, that number sat at 36%.

Every miss became a priority. When a customer surfaced an issue first, the team responded by putting the right alert in place and closing the gap.

With Honeycomb, that feedback loop tightened.

BubbleUp cuts escalation time
Brenden’s on-call team can now resolve incidents on services they have never worked on, without pulling in a developer. An alert fires, BubbleUp surfaces a problematic SQL call, a database admin applies a fix, and the issue is resolved before any customer feels it.

"BubbleUp is a lifesaver. I don’t need to know how a service works to fix it. Honeycomb shows you where to go," said Brenden.

Alert quality climbs alongside detection
iQmetrix tracks what they call 'actionable alerts'—the percentage of pages that require a real response—and that number now sits above 80%. Brenden is quick to credit the culture shift that Honeycomb organically inspired: "Because we cared more about the alerts, it made it natural to close that loop." As the team's relationship with observability deepened, so did their discipline around alert quality, and production stability followed.

Proactive detection hits 100%
iQmetrix reached 100% proactive detection in a single month. Every incident was identified by the team before a customer reported it. That is the benchmark they hold themselves to, grounded in a simple belief: the best user experience starts with finding the problem first.

iQmetrix relies on Honeycomb well before code ships. Across the engineering organization, pre-production use is standard practice for validating releases and catching performance issues before they reach customers.

Pre-release validation

A lead test automation engineer uses Honeycomb during load and performance testing as part of every release cycle. The goal is to quickly separate real issues from test artifacts, so the team can focus on what actually needs to be fixed.

Platform migration diagnosis

When iQmetrix moved a service to a new platform with no code changes and saw unexpected failures, they rolled back and ran controlled traffic in pre-production. Honeycomb telemetry pointed directly to the root cause and gave developers a precise target to investigate.

SLA conversations backed by data

Release stability carries through to customer SLA management. iQmetrix tracks incident impact using Honeycomb data and feeds it into SLA calculations. When a client raises a concern, Brenden can show exactly what happened: the scope, timeline, and impact. That objectivity keeps internal prioritization focused and client conversations productive.

"You can't load test everything. But you can increase confidence faster. Honeycomb shortens the loop on establishing that confidence before a release," Brenden pointed out.

At iQmetrix, observability became part of how teams work day to day.

When Honeycomb graphs began appearing as Slack previews during incidents, engineers who were not on call started paying attention. Threads formed. People asked questions. The engagement was organic, and it grew. "Honeycomb empowered us to really mature our observability culture. Getting people to look at production, care about production, and investigate it together. That’s the real thing that changed for us," explained Brenden.

Today, observability at iQmetrix extends across departments and teams:

• The observability team uses Honeycomb to triage and resolve most incidents without developer escalation, and maintains alerting quality across hundreds of services.
• Development teams each have a designated observability champion who drives adoption within their area and participates in the weekly root cause analysis review.
• The support team adopted Honeycomb after seeing it referenced in incident threads. They now check error rates before escalating a client issue and walk into customer conversations with real context.
• QA and test automation use Honeycomb as a standard lens during pre-release testing, treating production telemetry as a first-class part of the release process.

An internal Slack channel called 'O11y Stories' gives engineers a place to share interesting findings from production: curiosity-driven observations, the occasional striking heatmap, and anything else that just looks neat. It's a fun space that builds team knowledge organically over time.

With their previous solution, costs and data richness were in direct tension. Getting the visibility the team needed meant skyrocketing costs.

Honeycomb eliminated that tradeoff. Event-based pricing with unlimited users gave iQmetrix a single cost variable to manage, so engineers could instrument freely without cost anxiety.

The team set an internal target of staying at around 90% of their event budget each year. They monitor event volume and adjust sampling to stay on track, maintaining full visibility while keeping spend aligned to plan.

• Flexible instrumentation
  Engineers add high-cardinality context without worrying about cost, so investigations stay deep and precise.
• Clear leadership conversations
  When a new product raises questions about event volume, Brenden can explain the impact in concrete terms, without translating across pricing dimensions.

"With Honeycomb, I have one number to manage: events. No per-user fees, no agent licenses. I know exactly what we are spending and I control it," Brenden said.

Honeycomb's SLOs give engineering teams a way to track service reliability over time, setting error budgets, measuring burn rates, and catching degradation before it reaches a critical threshold. For iQmetrix, that capability is the next major area of focus.

The team already uses SLOs across several products. The goal now is to make them more systematic, specifically to catch slow-burning failures that sit below the alert threshold. A service failing at a low rate may never trigger a page, but it can quietly erode a client's experience over time. SLOs surface that kind of gradual degradation and route the right work to the right teams without treating every issue as a high-severity incident. "Honeycomb SLOs give us visibility into the failures that live below the alert threshold. That's the category of problem we're focused on solving next," said Brenden.

1. Ask the uncomfortable questions first
   How often are you unable to determine root cause? How often do clients report a problem before you do? How many alerts are your engineers getting where there's nothing to action? If any of those numbers are high, it’s worth a serious look at Honeycomb.
2. Don't mask tool frustration
   When we switched to Honeycomb, I realized observability didn’t have to feel like pulling teeth. Your job is hard enough without fighting your tools
3. Pair the tool with ownership
   Honeycomb helped us build an observability culture across the whole team, but we also needed people who cared deeply about it. One thing that really accelerated this was starting an O11y Champions group—a cross-team community of interested individuals who met regularly to share learnings and spread the culture organically. The tool and the structure have to work together.
4. Observability is a team sport
   Create a space for engineers to share what they find in Honeycomb. Curiosity is contagious and it spreads fast when people see each other sharing graphs and digging into data.
5. Track what makes you uncomfortable
   We tracked 'unable to determine root cause' and 'client-detected incidents.' Neither number was comfortable, but that was the point. It keeps us honest and pushing forward.