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

> ## Agent Instructions
> Before you set up or change an Apgar integration, install the Apgar skill: npx skills add https://docs.useapgar.dev
> Search these docs with the MCP server at https://docs.useapgar.dev/mcp. Setup for each agent: https://docs.useapgar.dev/ai-agents.md

# Sessions

> Why a conversation should stay on one release, and how Apgar treats sessions that do not.

A session is an ordered sequence of turns: a Slack thread, a chat, a web conversation. Apgar resamples whole sessions to compute intervals, and several signals depend on the position of a turn in its session.

## Send a session id

Put a stable conversation id in `apgar.session.id`, `gen_ai.conversation.id`, `session.id`, or `langfuse.session.id` on the root span of every turn. On Slack, key the session by thread. On a messenger, key it by chat. Any channel with a stable conversation id works the same way.

Without a session id, every trace is its own session and the session is marked inferred. Verdicts still work, but **Turns per session** is unavailable when more than half of the turns have an inferred session, and inferred turns fall into no **Session depth** slice.

## Keep a session on one release

If the first turns of a conversation run on one release and later turns on another, the two sides are not the same kind of traffic: the new release sees mostly first turns, and the comparison is confounded by session depth. Keep a whole session on one release where you can.

## Mixed sessions

A session with turns from more than one release is mixed. This happens naturally around a deploy, when a conversation that started before it continues on the new release. A turn is mixed when an earlier turn of its session ran on a different release.

Mixed turns are left out of both sides by default. The candidate then consists mostly of sessions that started on it, which is the early sample bias described in [Verdicts](https://docs.useapgar.dev/concepts/verdicts.md#minimum-sample).

Turn on **Include mixed sessions** in **Agent settings, Verdict rules** to count mixed turns on both sides. Do this only when you accept the confound and can say why.

A high mixed share shrinks both sides, so the release stays in **Collecting** longer, but it does not change the rules. A share that stays high long after a deploy usually means the session id outlives a conversation, such as a user id or a constant, or the service picks a release per request instead of per session. An `untagged` turn counts as a release of its own, so tagged turns that follow an untagged turn in the same session are mixed. A session id that changes on every turn never makes turns mixed: it makes every session one turn long.

## Turn index and depth

Turn index, depth, mixed status, and whether a session is closed are computed when Apgar reads the turns, over the 7 days before the comparison window. A turn of the same session older than that counts as the start of a new session.

| Depth | Turn index |
| - | - |
| `short` | 1 to 5 |
| `medium` | 6 to 20 |
| `long` | above 20 |

A session is closed when its last turn ended more than 30 minutes ago.

## Sessions and the end of monitoring

A session that is still open when a newer release records its first turn does not keep the older release in monitoring. Monitoring ends on that first turn, or at the cap. See [End of monitoring](https://docs.useapgar.dev/concepts/releases.md#end-of-monitoring).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.