When to use session replay, traces, logs, and Vega

Session replay, traces, and logs each answer a different question about your application, and Vega is the agent that investigates them for you. This topic explains when to use each. When examining session replay, trace, and log data, you have two decisions: which signal to open for a given question, and whether to read it yourself or hand the investigation to Vega.

​

At a glance

Each signal answers a different question:

• Logs answer “what happened?” They are discrete, timestamped events with a message, severity, and context.
• Traces answer “why was it slow, and what called what?” They are timed operations (spans) and their parent-child relationships, including across services.
• Session replay answers “what did the user experience?” It is a visual reconstruction of the UI as the user saw it.

Vega is not a fourth signal. It reads logs, traces, sessions, and errors and reasons across them.

​

Use logs for discrete events and state

A log is a discrete record of something that happened: a message, a severity level (INFO, WARN, ERROR), a timestamp, and any custom attributes you attach. Logs are the searchable, text-first record of application-level state and events. Use logs when:

1. You need the specific value or state at a moment, such as the cart total when an error fired.
2. You are reconstructing a discrete sequence of events and want a searchable record.
3. You are capturing application-level context that is not about timing, such as a config that loaded, a branch that was taken, or a third-party response body.

Logs are weakest when the question is about duration or about the chain of causation across services. A log records that something happened, not how it related to surrounding operations.

​

Use traces for performance and causation

A trace is a tree of timed operations called spans. Each span has a start time, a duration, and a parent. A trace shows both how long each step took and what called what. With context propagation, a single trace can follow a request across coroutines, threads, and separate services. Use traces when:

1. Something is slow and you need to identify the bottleneck.
2. You need to follow the path of a request through nested operations or across service boundaries.
3. You are investigating an intermittent timeout or a latency regression, where the question is about timing and structure.

Traces are weakest as a place to read detailed state. A span can carry attributes, but data you want to inspect later usually belongs in a log.

​

Use session replay for user experience problems

Session replay captures snapshots of your application’s UI at regular intervals and stitches them into a scrubbable recording of what the user saw and did. It is the only signal that represents the user’s experience rather than the system’s internal state. Use session replay when:

1. The problem is about user experience, such as a button that looked disabled or a layout that broke on a particular screen.
2. A bug is hard to reproduce from a description and you need to watch it happen.
3. You are investigating user behavior, such as where users get stuck, rage clicks, or abandoned flows.

Session replay is weakest as a source of precise internal values, and it carries the most privacy weight because it records the actual UI. To understand why something happened in a recorded session, jump from the replay to the traces, errors, and logs from the same session.

​

Compare the three signals

The following table summarizes what each signal is best at:

	Logs	Traces	Session replay
Question it answers	What happened?	Why was it slow / what called what?	What did the user experience?
Shape of data	Discrete timestamped events	Timed spans in a parent/child tree	Visual UI recording over time
Best for	State, values, discrete events	Performance, latency, causation	UX bugs, hard-to-reproduce issues, behavior
Weakness	No timing or causal structure	Not a place to read detailed state	Privacy weight; not precise internal values
Where available	Client- and server-side	Client- and server-side	Client-side only (mobile and web)

Vega is not included in the table because it reads the signals rather than capturing data of its own.

​

Use Vega when you want the investigation done for you

Vega is the LaunchDarkly AI agent for observability. It reads logs, traces, errors, and sessions, reasons across them, and pulls in context such as recent flag changes and alerts. Vega appears in a few forms:

• Investigate mode (read-only, the default) summarizes the relevant observability data, highlights anomalies, and identifies likely root causes. It often correlates findings with recent flag or code changes.
• Fix mode analyzes the relevant code paths, generates candidate changes, and can open a pull request with proposed edits. Fix mode requires a connected GitHub account.
• Search assistant converts plain-language questions about your observability data (“which traces increased error rates?”) into structured queries and runs them.
• Auto remediation, paired with alerts, starts a Vega investigation automatically when a threshold is breached.

Use Vega when:

1. You have a symptom and would rather have the first-pass investigation done for you than scrub replay, traces, and logs manually.
2. You want the signals correlated with recent flag and code changes automatically, such as to answer “did the flag I just flipped cause this?”
3. You want issues triaged when an alert fires, not only when a human notices.
4. You want a candidate fix proposed, not only a diagnosis. Fix mode handles this.

Vega is only a starting point. Verify its conclusions and read the underlying signals yourself for deep or novel issues. Vega has its own access requirements, and fix mode requires GitHub.

​

Signal availability by platform

Session replay is client-side only because there is a UI to record. Server-side SDKs do not capture sessions. Traces and logs are available on both client and server.

• On a mobile app or web frontend, all three signals are available. Replay is often the fastest entry point for a user-reported bug, and you can drill from there into traces and logs.
• On a backend service, session replay is not available. Traces and logs carry the entire investigation, and traces are especially valuable because they follow a request across services.

Vega works on whichever signals are present. On a backend, Vega reasons over logs, traces, and errors. On a client, it can also draw on sessions. The decision to use Vega does not depend on platform.

​

How to choose

First, match the signal to the symptom. Open session replay when:

• A user reported something looked or behaved wrong
• A bug is hard to reproduce from a description
• You are studying behavior, such as drop-off, confusion, or rage clicks

Open traces when:

• Something is slow and you need to find the bottleneck
• You need to follow a request across operations or services
• You are chasing intermittent latency or timeouts

Open logs when:

• You need a specific value or state at a moment
• You want a searchable record of a discrete event
• You are reconstructing a sequence of events

Then decide who investigates. Hand it to Vega when:

• You would rather have the first-pass investigation done for you
• You want the issue correlated with recent flag and code changes automatically
• You want triage to start when an alert fires, without a human watching
• You want a candidate fix proposed, not only a diagnosis

Instrument all three signals, then choose which to read based on whether the question is about an event, timing, or experience, and choose whether to read it yourself or let Vega read it for you.

​

Further reading

• Observability: Reviewing logs, traces, and sessions in the LaunchDarkly UI.
• Session replay: How recording, privacy, and the session player work.
• Vega: The AI agent’s investigate and fix modes, search assistant, and auto remediation.
• Observability settings: Ingestion filters and rate limits for each signal.