# Troubleshoot failed, stopped, or old-version conversations

Begin with the conversation row, then use Overview, Transcript, and Activity in that order. The row provides status and result; Overview provides the exact end reason and frozen version; Transcript and Activity show the last successful customer-facing and runtime events.

## Failed conversations

For status **Failed**, inspect the end reason and the last error-bearing Activity event. An `error` end reason may follow repeated model failure, invalid frozen runtime resources, a Workflow error, or a fail-closed Guardrail evaluator. A Tool failure by itself normally returns a Tool result to the model and does not automatically fail the conversation, so verify whether a later event closed it.

Use the safe event details rather than guessing from the final transcript. `llm_request` records separate the primary response, router, guardrail, workflow condition, and Analysis purposes. Workflow and Procedure events identify the exact frozen node or step. Secret values and provider response bodies are intentionally unavailable.

## Stopped conversations

For a conversation that **stopped**, read its end reason. `agent_ended` or `user_left` can be expected. `timeout` and `max_duration` mean the configured time boundary was reached. `quota_exceeded` and `workspace_not_activated` point to [Usage and quota](/docs/monitor/usage-and-quota). `guardrail_triggered` means a blocking policy ended the path. `abandoned` identifies an interrupted transport lifecycle.

An open conversation is checked again before its next message. If it reached maximum duration or quota, the next turn closes it instead of silently continuing. Once a conversation is terminal, it cannot accept another turn; start a new conversation after correcting the cause.

## Conversations using an old version

A conversation showing an **old version** is usually behaving correctly. Every conversation uses the frozen branch version or draft snapshot captured at open. Publishing a fix affects new conversations; it does not rewrite an active or historical record. Telegram continuation also creates linked segments rather than changing the prior segment's version.

Confirm the version ID in Overview, open that immutable version in branch history, and compare it with current Live Main. Reproduce with a new [Test chat](/docs/agents/test-chat) after publishing. If the new run still uses an unexpected production branch, check [traffic and deployment history](/docs/deploy/traffic-and-history).

## Recovery checklist

Preserve the original evidence. Record the conversation ID, branch, version, end reason, final transcript sequence, and relevant Activity event types. Correct the draft or dependency, test it, publish deliberately, and create a new conversation. Do not use revert, merge, traffic rollback, or Secret replacement until its documented preview and interruption behavior is understood.

For deeper event interpretation, see [Transcript and Activity](/docs/monitor/transcript-and-activity). For Analysis-only problems, see [Monitor Analysis results](/docs/monitor/analysis-results).