> ## Documentation Index
> Fetch the complete documentation index at: https://docs.honeycomb.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Investigate Backend Latency

> Use Honeycomb and Embrace together to move from a backend latency trigger to confirmed user impact in a single investigation.

## Overview

When a Honeycomb trigger fires on a backend service, the immediate question is whether real users are affected and how badly.
This workflow takes you from a Honeycomb trigger to a confirmed user impact assessment in Embrace, without leaving your investigation context.

## Before you begin

Before you begin, make sure you have:

* [Configured the Embrace integration](/integrations/embrace/configure) and are forwarding network spans to Honeycomb.
* A Honeycomb trigger on a backend service that includes mobile or web traffic.

## Investigate the trigger

<Steps titleSize="h3">
  <Step title="Open the triggering query">
    When a Honeycomb trigger fires, the notification includes a direct link back to the triggering query in Honeycomb.
    Select that link to open the query in Query Builder.

    The query shows the condition that fired, along with the current state of the data.
    If the trigger fired on `p95(duration_ms)`, the heatmap shows where the outlier band is concentrated.
  </Step>

  <Step title="Run BubbleUp to identify the affected slice">
    From the heatmap, draw a selection around the outlier band to run BubbleUp.
    BubbleUp compares the selected events against the baseline and surfaces the dimensions that differ most between them.

    Look for `emb.*` attributes in the BubbleUp results.
    If Embrace-forwarded spans are present in the outlier population, you will see dimensions like `emb.app_version` or `emb.device_model` ranking highly.
    This indicates the latency issue is concentrated in a specific mobile or web client slice.
  </Step>

  <Step title="Open the trace detail view">
    From the heatmap or query results, select a point in the outlier region and select **View trace**.
    The trace detail view opens with the waterfall representation of the trace.

    If the trace includes an Embrace-forwarded span, it appears at the top of the waterfall, labeled as forwarded via Embrace, with the backend service spans below it.
    The forwarded span carries the full set of `emb.*` attributes in the trace sidebar, including `emb.app_version`, `emb.device_model`, and `emb.dashboard_session`.
  </Step>

  <Step title="Pivot to the Embrace session">
    In the trace sidebar, select the `emb.dashboard_session` value.
    Selecting it opens the exact user session in Embrace, with the network entry for the request already selected in the session timeline.

    In Embrace, the session timeline shows the full user journey around the slow request: the screens visited, the taps made, and any errors or rage taps that followed.
    The aggregate impact view shows how many users are affected, what their UX score is, and whether checkout conversion or other key flows are degraded.
  </Step>
</Steps>

## Make the call

With the Embrace session data in hand, you have what you need to decide how to respond:

* If the impact view shows a large affected user count, a poor cohort UX score, or a significant conversion drop, escalate the incident and notify the relevant teams.
* If the impact is limited to a handful of users, an isolated carrier issue, or a specific edge-case device, you can close the investigation with confidence rather than paging additional teams.