Interaction Logs
Trace every step your workflows execute
The interaction log captures every internal step a workflow runs to produce an agent reply, from model calls to HTTP requests. Which steps run for any given reply depends on the workflow itself. The log is the raw record of what actually happened, and the starting point for any serious debugging or performance work.
You meet the interaction log in two places:
Observatory > Interaction Logs: every interaction across every session, in one filterable table
Observatory > Sessions > Chat Sessions: open any session and select a user message to see the trace behind it, scoped to that single conversation event
What Is an Interaction
An interaction is a single atomic step your workflow runs while producing a reply. Each type of step corresponds to a node in Designer that can fire during a workflow execution. Which types appear in any given trace depends on the workflow's design.
Regardless of type, every interaction in the log carries the same surrounding metadata:
Timestamp
When the step ran, to the millisecond
Duration
How long the step took, in milliseconds
Errors
Whether the step succeeded or failed
Source node
The friendly name of the Designer node that triggered the step
Agent
The agent that owns the workflow
Deployment
The deployment that served the session
Session ID
A unique identifier of the parent conversation
Event ID
A unique identifier shared by all steps of a single user turn
JSON Payload
The raw request and response data, shaped to fit the step's type
Sessions, Events, and Interactions
Interactions sit at the bottom of a three-tier nesting: a session is one conversation, an event is one workflow execution within that session (typically one user turn), and an interaction is one step within an event.
Exploring the Interaction Logs
The Interaction Logs page at Observatory > Interaction Logs brings every interaction your agents have produced into one filterable table. Each row is one step a workflow ran, and selecting it opens the details in the side panel.

Filtering and Search
Interaction Logs scopes to the typical Observatory filters. Check them first if an interaction you expect is missing.
Filters live in the URL, so sharing or bookmarking the page reproduces the same view. Your selection also persists as you navigate across the Observatory.
Use the search bar to find an interaction by the reference you have on hand:
Session ID
You already have a session reference from a link, screenshot, or bug report
Name
You know the node or variable label (for example, csatSurveys) and want every step that touched it
Event ID
You have an event ID for a single workflow execution (typically one user turn) and want every step that ran in it
Inspecting a Single Interaction
Select any interaction to open its details. This is where everything you have seen so far comes together: the interaction type, the event hierarchy, the raw payload, and more.

From any opened interaction you can:
View in Session
View in Session is the link from a single step back to the conversation that produced it. An interaction tells you what the workflow did, but not why it had to. The session view gives you that context: the user message that triggered the step, what came before, and what came after.

Use it whenever you have found a problematic step and need the conversation around it to judge whether the behavior makes sense. See Inside a Session for what you land on.
Logs in a Chat Session
When you want to debug one specific conversation, start in Observatory > Sessions > Chat Sessions. Select the session, then select a user message in the transcript to see the workflow steps that ran in response to it.
All the same interaction concepts apply here, just at a narrower scope: one user message at a time.

A few things to know about this view:
Each user message is the trigger that starts a workflow execution. Selecting a user message shows the steps that produced just that one reply.
The first agent message is the exception. Select it directly, because it runs before any user input and is not tied to one.
Expand any step in the trace to drill into its full details, including the raw payload
The Variable Values tab shows a snapshot of session-scoped variables at this point in the conversation, including the writes that happened up through this turn
To see every step of an entire session at once, use the Interaction Logs page with a Session ID filter instead.
Working with the Logs
A handful of patterns cover most real debugging work. Each one starts from a different reference point and lands you on the relevant interaction in a few clicks.
Investigate One Session in a Single Table
When you already know the session you want to debug, the Interaction Logs page is often faster than the per-session view. Filtering by Session ID turns the table into the full chronological trace for that conversation. Every step visible at once, instead of one-message-at-a-time.
Copy the session ID from the per-session URL or from the Session Details sidebar tab inside the conversation
Open Observatory > Interaction Logs and switch the search mode to Search by Session ID
Paste the ID and run the search
Sort by Timestamp, scan for errors or long durations, and select any row to inspect its payload
Find Slow Steps for a Specific Deployment
Performance investigations often start as "responses feel slow on Webchat lately" and end at a single LLM call or external request that crosses your latency budget. Combining the Agents filter with the Long duration preset narrows the table to the steps that matter.
Set the Agents filter to the agent and deployment under investigation
Open the Duration column filter and pick Long (>2s)
Sort by Duration descending
Open the slowest rows to see exactly what each one was doing
Triage Errors Across Agents
An error count spikes on a dashboard, or a teammate flags an issue without naming a session. The Errors filter surfaces every failing step in your time window. Pattern-spotting across that subset is usually how you find the root cause.
Set the date range to cover the period of interest
Open the Errors column filter and pick Yes
Scan the table for patterns: a single agent, a single deployment, a single Type, or a single source node showing up repeatedly
Open a matching row to read the error in the payload, then use View in Session to see the conversation around each failure
Find Every Step a Specific Node Produced
The Name column shows the friendly name of the Designer node that produced each step. Setting clear, descriptive names in Designer is what makes this search useful later: the Name search is only as good as the names you assign.
In Designer, give each node that shows up in the interaction log a meaningful name (for example, Knowledge Search: Pricing)
In Interaction Logs, switch the search mode to Search by Name
Enter the node name to filter the table to every step that node has produced across all sessions and agents
Name your nodes early: Renaming a node later does not relabel the interactions it has already emitted.
Best Practices
Start from the failing step, not the response text: The trace tells you what the workflow actually did. The response is only the consequence.
Triage globally with Errors > Yes: When you do not yet know which session is affected, filter the view by errors and scan across agents and deployments
Paste an Event ID to pull a whole turn: When a bug report or log line gives you an event ID, the search returns every step that ran in that one workflow execution
Pivot back with View in Session: Once you have identified the problematic step, drop back into the conversation to see what the user saw and what came next
You can now trace every step your workflows execute, both inside a single session and across all of them, and use the filters, search, and JSON payloads to debug agent behavior end to end.
Last updated
Was this helpful?




