Embrace has officially acquired SpeedCurve! Together, we’re redefining the future of user-focused observability.

Learn more

The future of user-focused observability: what we discussed — and why it matters

Systems can look healthy while users are failing. This post breaks down what we discussed in our fireside chat on user-focused observability.

At Embrace, we’ve always believed that reliability should be measured from the user’s perspective — not just system uptime or backend health.

If users can’t log in, check out, book a trip, or complete a critical flow, then something is broken — even if dashboards are green and services are responding.

That belief was at the center of a recent fireside chat we hosted with leaders from Embrace and SpeedCurve — a web performance company that recently joined Embrace and has spent more than a decade focused on understanding how users actually experience performance on the web.

For Embrace customers, this conversation wasn’t just theoretical. It reflects how we’re thinking about the future of the platform — and the kinds of user-impacting problems we want to help you understand more completely.

Rather than talking about features, the discussion focused on a bigger shift we’re seeing in observability: performance and reliability need to start where users begin.

Below are the key ideas we discussed — and why they matter.

Uptime isn’t the hard problem anymore

For many teams, infrastructure uptime has largely been solved. Modern systems are resilient, redundant, and well-instrumented.

But during the fireside, we talked about a growing disconnect:

systems can look healthy while users are failing.

Many of the most expensive issues don’t show up as outages or error spikes. They show up as:

  • abandoned checkouts
  • failed logins
  • slow or broken interactions
  • users quietly leaving

If reliability is measured only at the backend or infrastructure layer, these failures are easy to miss.

This is a gap many Embrace customers already recognize — especially when issues never register as incidents, but still impact real users and real outcomes.

Sampled data creates false confidence

Another recurring theme in the discussion was the risk of relying too heavily on sampled data.

Sampling is useful for trends, but it breaks down when teams need to answer a more fundamental question:

Did this specific user succeed?

Edge cases are often dismissed as noise — but in reality, they’re frequently where high-value transactions fail. A checkout that breaks only on a specific device, browser, or network condition still represents a real customer and real revenue.

Without full visibility into user sessions, teams are often left guessing — or learning about problems too late through support tickets or churn.

Performance isn’t just page load time

From the SpeedCurve perspective, we spent time unpacking how traditional performance metrics can be misleading.

A page can technically “load” quickly and still deliver a poor experience.

What users actually experience depends on things like:

  • visual completion
  • interactivity
  • asynchronous work after initial load
  • third-party scripts and dependencies

This is especially true for modern, JavaScript-heavy applications, where meaningful user interaction often happens well after the first server response.

Understanding performance means seeing what the user sees — not just when a request finishes.

The frontend has been a reliability blind spot

One of the strongest points of alignment between Embrace and SpeedCurve is the recognition that the frontend has historically been a blind spot for reliability teams.

Many user-impacting issues never reach the backend at all. They happen in:

  • the browser
  • the device
  • third-party scripts
  • client-side logic

That creates a gap between what infrastructure teams can observe and what users actually experience.

Bridging that gap is essential if reliability is going to reflect reality.

Start with user success, then trace backward

A central idea that emerged during the fireside was a simple mental model:

  • Did the user succeed?
  • What happened during their experience?
  • Why did it fail?

When teams start with user success — instead of isolated metrics — they can trace issues across the frontend, backend, and dependencies to understand true root cause.

This reframes observability around outcomes, not just signals.

Why SpeedCurve fits naturally into the Embrace vision

For Embrace customers, SpeedCurve should feel less like a new direction and more like a natural extension of a philosophy you already know.

Embrace has long focused on capturing complete user sessions and connecting technical signals to real user impact — particularly in mobile and complex application environments.

SpeedCurve brings deep, specialized expertise in web performance and synthetic testing, with a long history of:

  • understanding browser behavior
  • contributing to performance standards
  • helping teams see performance through the user’s eyes

For customers, this means deeper visibility into web performance issues that often sit upstream of user sessions — and more confidence when correlating frontend behavior with real user outcomes.

What this means today — and what comes next

Today, Embrace and SpeedCurve remain distinct products, each fully supported and actively developed.

Over time, our goal is to thoughtfully bring these worlds closer together — uniting:

  • real user monitoring
  • synthetic testing
  • OpenTelemetry-based instrumentation

without disrupting the workflows and visibility you rely on today.

What won’t change is our focus on helping you understand whether your users are actually succeeding — and why.

Watch the full fireside

If you’d like to hear the full conversation and context behind these ideas, you can watch the complete fireside chat here.

Embrace Deliver incredible mobile experiences with Embrace.

Get started today with 1 million free user sessions.

Get started free
Related Content

SpeedCurve joins Embrace!

Together, we’re redefining the future of user-focused observability.