RUM Is Not a Dashboard Problem: Why the Honeycomb-Embrace Partnership Matters for Product Engineers

The short answer

For years, frontend observability has been a separate silo. Teams use one tool for real user monitoring (RUM) — dashboards of LCP, CLS, and error rates — and another for backend traces, logs, and metrics. When a user reports a slow page or a broken interaction, you end up context-switching between tools, guessing at correlations, and wasting time on "works on my machine."

The Honeycomb-Embrace partnership, announced May 14, 2026, directly addresses this. By integrating Embrace's RUM data into Honeycomb's high-cardinality, context-rich observability platform, engineers can now query browser events alongside backend traces in a single environment. This is not just a convenience — it changes how we debug, prioritize, and ship performance improvements.

As a product engineer who has built real-time dashboards and AI-powered systems, I see this as a necessary evolution. The user's experience is not separable from the system's behavior. Treating them as separate domains leads to slower root cause analysis, misprioritized work, and a gap between what we monitor and what users actually feel.

Key takeaways

• RUM data is now queryable alongside backend traces — no more switching between tools to correlate a slow page load with a database query.
• High-cardinality attributes from the browser (viewport size, connection type, interaction timing) enrich debugging context that traditional aggregated dashboards miss.
• Context-switching cost drops — a single engineer can trace a user issue from click to database query without leaving Honeycomb's query interface.
• AI features benefit from end-to-end tracing — streaming responses, client-side processing, and model inference latency can be correlated in one view.
• Product decisions become data-driven — instead of guessing which performance metric matters most, you can query actual user sessions to see the real impact of a slow API or a layout shift.
• This sets a new bar for observability platforms — the future is unified, not siloed. If your stack doesn't offer this, you're flying blind on the frontend.

The real problem: RUM as a separate concern

Most teams approach frontend performance with synthetic tests (Lighthouse, WebPageTest) or aggregated RUM dashboards that show percentiles. These give you a general sense of health but fail when you need to answer: "Which users are affected by this slow API call?" or "Why did this chart render slowly on mobile Safari in Brazil?"

Synthetic tests run in controlled environments. Aggregated dashboards hide the tail. Neither lets you drill into a specific user session and see the full story. You end up with a dashboard that says "LCP is 2.5s p75" but no way to connect that to the backend trace for the same session. So you guess. You add more instrumentation. You ship a fix and hope.

The Honeycomb-Embrace integration solves this by making RUM data high-cardinality and queryable. Instead of pre-aggregated metrics, you get raw events from the browser — each with attributes like user ID, session ID, URL, device type, network type, and interaction metadata. You can then join those events with backend traces using the same session ID. Suddenly, "slow page load" becomes a query: "Show me all sessions where LCP > 3s, grouped by API endpoint, and drill into the slowest trace."

How this looks in a shipped product

Imagine you've built a real-time dashboard for a mortgage origination system. Users complain that the dashboard "feels slow" after 2 PM. Your backend metrics show normal latency. Your RUM tool shows high LCP on the dashboard page, but you can't see which API calls are slow for those sessions.

With unified RUM, you query Honeycomb: filter sessions where the dashboard component rendered, group by the user's region, and look at the backend traces for those sessions. You discover that a third-party credit report API has intermittent latency spikes that only affect users in the Eastern time zone. The frontend is waiting on that API to render a widget. Without the join, you'd be chasing a frontend performance fix that wouldn't solve the real problem.

This is the difference between monitoring and debugging. Monitoring tells you something is wrong. Debugging tells you why. Unified RUM with high-cardinality context turns monitoring into debugging.

Tradeoffs and when the conventional wisdom breaks

Not all RUM integrations are equal. The Honeycomb-Embrace partnership emphasizes high-cardinality and raw events, not just aggregated metrics. Traditional RUM tools (like Google Analytics or basic APM RUM) give you averages and percentiles — useful for dashboards but useless for debugging a specific user session. The tradeoff is data volume and cost. High-cardinality RUM generates more data, which means more storage and query costs. But the payoff is actionable insights.

If your team is small and your product has low traffic, the cost might not justify the complexity. But if you're shipping features that affect user experience — especially AI features with streaming or real-time updates — the ability to trace a single user's journey from browser to backend is invaluable. The conventional wisdom of "just use Lighthouse" or "add a RUM script" is no longer sufficient.

What to evaluate in your observability stack

When choosing or upgrading your observability stack, ask these questions:

• Can I query RUM data with the same language as my backend traces? (Honeycomb's HBQL, for example.)
• Can I join on user session ID or a common identifier?
• Can I set alerts based on frontend-specific metrics (LCP, FID, CLS) and correlate them with backend errors?
• Does the RUM tool capture high-cardinality attributes like interaction type, viewport size, and connection speed?
• Can I drill from a dashboard metric to a specific user session trace?

The Honeycomb-Embrace partnership sets a new bar. If your current stack doesn't answer yes to most of these, you're leaving money on the table in debugging time and product quality.

Closing: A concrete next step

If you're already using Honeycomb, evaluate the Embrace integration. It's not just another RUM tool — it's a way to unify your understanding of user experience and system behavior. If you're not using Honeycomb, consider that the future of observability is unified. The days of separate frontend and backend monitoring are ending. Product engineers who embrace this shift will debug faster, ship with more confidence, and build products that feel better under real networks and real users.