Reading the logs

The Logs screen is where you watch your project actually serving. Every turn it handles leaves a record here, replied or failed, so when something looks wrong you have somewhere to look. It is scoped to one project, and you reach it from the project’s sidebar under Operate.

What it is

A turn is one exchange with your GenUI experience. The Logs screen opens on a list of your project’s conversations, newest first, one row each, with a few project-wide totals across the top: how many users and conversations you have served, the tokens in and out, and how many turns ended in an error. A conversation is the thread your frontend keeps alive by sending the same conversationId.

Each row shows the conversation’s id, the subject it was served to, how many turns it holds, the tokens it consumed, its total errors, and when it last saw a turn. Open a conversation to read its turns.

A turn’s record is content-free: the user’s message and the interface the model returned are not stored, for privacy. What a turn shows instead is its shape:

• Outcome — whether the turn replied, which is the success case, or which coarse error it ended on.
• Version and model — the project version the turn served and the model that answered it.
• Tokens — the input and output tokens the model used, when it ran. The dollar cost those tokens convert to lands on a later screen.
• Action — when a person’s tap started the turn instead of a typed message, the turn is marked as an action and shows the action’s name, for example show_similar. Only the name is kept, never the values that came with it.
• Data model — when the turn carried back what a person set on screen, such as where they left a slider, and reached the check that screens it, the turn wears a Data model badge. A turn blocked on its typed message stops before that check, so it shows no badge even if it carried one. The values never reach the logs. A turn that replied keeps them in its conversation, and a blocked turn keeps them nowhere. See Generated UI that follows its data.
• Trace ID — the same handle the x-trace-id response header carried, so you can copy it and find the turn in your tracing tools.

Open a turn and you get its step breakdown: the ordered steps the turn ran through, from the auth check to the guardrails, including the Data model guardrail on a turn that reached it with a data model, the history load, the model call, and the output validation, each with the time it took. A turn that felt slow shows you which step spent the time.

When the model calls your tools, each call shows as a sub-row under the step it ran in. The tools the model asked for during the turn sit under the model call, and a session-start tool sits under the history load. Each sub-row shows the tool’s name, how long the call took, and whether it came back OK or failed.

Two things are worth knowing when you read these times. They are part of the step they sit under, not added on top of it, so a call’s time is already counted inside that step’s total, whether that is the model call or the history load. And calls the model made together run in parallel, so their durations overlap rather than add up.

How to use it

1. Open your project and choose Logs in the sidebar under Operate.
2. Read the conversations, newest first. Each row is one conversation. The Total Errors column tells you at a glance how many of a conversation’s turns did not reply.
3. Narrow the list with the Outcome filter at the top: pick Succeeded or a specific error code, or Any error for everything that did not reply.
4. Click a conversation to open it and read its turns.
5. Open a turn to see its step waterfall and where the time went.

When a turn was blocked

A blocked turn is one a guardrail stopped, either on what came in or on the model’s reply going out. What came in is the message a person typed, or for a turn a tap started, a value the person entered into the pressed action. It can also be something a person set on screen, which rides along with the turn as its data model. The Logs screen tells you which of these it was: the incoming message, a value in the pressed action, a value set on screen, or the model’s reply. That is the cause, and it stays here.

A value set on screen stays on screen until the person changes it, so it rides on every later turn too. A conversation blocked on one keeps being blocked until that value changes.

Your caller never sees it. The turn endpoint returns only the coarse blocked code to your frontend, with no reason attached, so the detail you read here is yours as the operator and does not leak to the user. If you need to know why a guardrail fired on a specific turn, the logs are the place, and the trace ID ties it to the rest of the picture.

When an action was refused

A turn that ends on invalid_action came from a tap the platform could not match to anything it served on that conversation. The surface or component was never served, the name was different, or the values that came with it had been changed or added to. A run of them usually points to a stale screen, such as buttons kept on screen across a version change that dropped their action, or to requests built by hand. As with a blocked turn, which part did not match is kept on the platform and never returned to your frontend.

Failure modes

• The screen is empty. No turns have been served for this project yet. Send one from your frontend and refresh.
• The screen could not load. Something went wrong fetching the turns. Reload the page; if it keeps failing, the trace ID on any response and your API logs are the next place to look.