Embrace partners with Honeycomb to unite frontend performance depth with backend observability precision

That shared foundation, around high-fidelity data and OpenTelemetry, makes this partnership much more than a typical integration, and will help entire engineering organizations better understand highly complex systems and deliver better experiences for every user on every screen.

Scattered tooling and separate workflows

Backend and reliability teams have had strong observability options for a while now. Honeycomb has led the pack with a best-in-class high-cardinality model for services observability, and a genuine commitment to OpenTelemetry. But engineers across teams kept telling us the same thing: they wanted to know what end-users were experiencing on the other side of the API call. 

Mobile and web developers didn’t want shallow RUM tools bolted onto an expensive “all-in-one” platform that wasn’t built for them, so they’d seek out point solutions with zero ties to the reliability teams. Client-side environments like mobile apps are notoriously complex to troubleshoot. The result is predictable: no shared data, duplicate investigations, and a structural disconnect between the teams who need to collaborate the most. 

The pain isn’t subtle. An SRE gets paged at 9am on a Monday, narrows a latency spike to a specific endpoint, and then has to stop and ask: is anyone actually feeling this? They have no way to know without calling someone on the mobile team. Or, a mobile engineer sees an ANR spike on the checkout screen and spends twenty minutes trying to rule out a client bug before they can even ask for backend help. A frontend engineer watches a Core Web Vitals metric deteriorate for three weeks because it never crossed the threshold that would have paged someone (yet the users felt it). 

These aren’t edge cases. They’re the standard experience for engineering teams working on user-facing software. And they all share the same problem: the ability to get answers stops at the API boundary.

What changes when the data is connected and tooling depth matches expertise

Because both platforms are built on OpenTelemetry, user telemetry from Embrace flows into Honeycomb as standard, enriched, composable data with the same format and same dimensions, queryable with the same tools. No proprietary schema, no translation layer. 

In practice, this changes how three kinds of engineers work:

• The SRE on-call starts in Honeycomb and ends in Embrace. When a backend issue fires, Honeycomb narrows the problem to a specific service and traffic slice. From there, one click surfaces the affected real user sessions in Embrace, including who they are, how many, and what they were doing when things went wrong. That’s usually enough to decide whether it’s worth waking up the frontend engineering team. Honeycomb tells them the “where,” Embrace tells them the “who,” “how many,” “what customer activities are affected,” and “how bad.” 

• An app engineer starts in Embrace and ends in Honeycomb. When a checkout flow in the app is freezing (and frustrating users), Embrace quickly shows whether the problem is on the device or somewhere upstream. If it’s upstream, one click opens the matching backend trace in Honeycomb, and the engineer can hand off a specific, evidence-backed ticket instead of a hunch.
• The web performance / frontend engineer loops between both. Honeycomb catches a Core Web Vitals metric drifting in the wrong direction before it crosses an alert threshold. Embrace gives per-page and per-interaction breakdowns along with Synthetic analysis. They identify a recently-shipped vendor SDK as the cause, ship a fix, and can confirm the improvement in Honeycomb within a day.

What this means for composable observability, and for our AI-driven future

The handoff points work because the data is open and the philosophy is shared. The session ID in a Honeycomb span drives into  Embrace where users can explore populations of affected users, and the trace ID in an Embrace network span is a link to Honeycomb where you can explore the dynamics of service behavior. The data doesn’t stop at the API boundary anymore.

Today’s integration is the foundation, not the destination. Where we’re headed is a single observability surface where any question about a service, a user, a revenue line, or a cohort on a specific device build has one place to live. That means BubbleUp running on the joint event set, SLOs that incorporate real user experience scores, and web and mobile apps treated as first-class services. Drift on either side gets cross-checked automatically before any threshold fires, and the impact gets surfaced in language that product and leadership can actually act on, not just the engineering team. Engineering teams worry less about the tooling and more about their end-users.

That also matters for where AI-driven development is heading. When an AI agent can pull backend trace data from Honeycomb and jump directly to the affected user sessions in Embrace, it can traverse the full stack in one step and surface the context that tells a developer whether to page the team or close the ticket. When Honeycomb’s querying capabilities and Embrace’s MCP server are working together inside an agentic workflow, the on-call engineer supervises rather than assembles. The quality of that agent’s answer is only as good as the data it can reach, of course. Connected data means connected reasoning, and we’ll have a lot more to share on that soon.

Engineering teams that have been treating web and mobile performance as separate from their observability practice can now bring it into the same workflow, the same data, and the same tools. That’s the promise, and we’re excited to deliver it with Honeycomb.

To learn more about how Embrace and Honeycomb work together, visit embrace.io/partners/honeycomb.