> For the complete documentation index, see [llms.txt](https://docs.autopilotmonitor.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autopilotmonitor.com/concepts/sessions-and-statuses.md).
# Sessions & Statuses
What an enrollment session is, the statuses it can have, how attempts group into a device journey, and how completion is decided.
## What is a session?
A **session** represents one Windows Autopilot enrollment attempt on one device. It starts when the agent registers with the backend during OOBE and collects everything that happens on the device until the enrollment finishes: ESP phase transitions, app installations, script executions, policies, performance snapshots, security posture, and any rule findings.
Each session is identified by the device (serial number, hardware info) and holds a chronological **timeline** of events. If the same device is reset and enrolled again later, that is a new session — and the two sessions are linked as attempts of the same [device journey](#device-journeys--attempts).
## Session statuses
```mermaid
stateDiagram-v2
direction LR
[*] --> InProgress: Agent registers session
InProgress --> Pending: Pre-provisioning (White Glove)
device phase done, awaiting user
Pending --> InProgress: User signs in,
user phase continues
InProgress --> Succeeded: Enrollment complete
InProgress --> Failed: Explicit failure detected
InProgress --> AwaitingUser: Silent after Device Setup
(session timeout)
InProgress --> Incomplete: Silent, no completion
or failure signal
AwaitingUser --> Succeeded: Late completion reconciled
AwaitingUser --> Incomplete: Grace window expires
Incomplete --> Succeeded: Late completion reconciled
Failed --> Succeeded: Late completion reconciled
```
| Status | Meaning |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **In Progress** | Enrollment events are actively being received. The agent is monitoring the enrollment on the device. |
| **Pending** | The session is registered but waiting for the user enrollment phase. Typical after a **pre-provisioning (White Glove)** enrollment: the device phase is complete and the device waits for a user to sign in and continue. |
| **Awaiting User** | Non-terminal. Device Setup finished, but the user / Account Setup phase hasn't completed and the agent has gone silent — most often the user simply hasn't signed in yet (the device is provisioned and legitimately waiting at the login screen). The session parks here and **heals to *****Succeeded*** if the enrollment completes later; once the grace window expires it settles to **Succeeded** ("completed (assumed)") when the user provably reached the desktop and no app failed, otherwise to *Incomplete*. |
| **Succeeded** | The enrollment finished successfully — the device passed through all expected phases (or an admin manually marked it succeeded via Admin Mode). A session that went silent and later produces a genuine completion signal is **reconciled** to Succeeded, even from Failed, Incomplete, or Awaiting User. |
| **Failed** | The enrollment ended in an **explicit** failure — a failure event from the agent/backend, a firing analyze rule with "mark session as failed" enabled, or a manual Admin Mode mark. A silent session that never sent a failure signal is **no longer** counted here (see [Timeouts](#timeouts-what-happens-to-stuck-sessions) below). |
| **Incomplete** | Terminal, but **not a failure**. The session went silent without ever producing either a completion or an explicit failure signal, and the grace window expired. It is excluded from the failure rate — it means "we lost the evidence trail", not "the enrollment broke". |
## Device journeys & attempts
A session is one enrollment. A **journey** is what it took to get *one device* enrolled: the chain of finished enrollment attempts on that device, up to and including the first success.
The rules are deliberately narrow, because everything built on top of them — the *"Attempt 3 for this device"* banner on [session detail](/portal-guide/session-details-and-diagnosis.md#device-history) and the [first-time-right rate](/portal-guide/fleet-health.md#first-time-right) on Fleet Health — is only useful if it counts what an administrator would count:
* **Devices are matched by serial number.** Placeholder or unusable serials (a device that reports no serial, or a generic firmware default) are excluded entirely and disclosed as excluded rather than merged into one phantom device.
* **Only finished sessions are attempts** — *Succeeded*, *Failed*, or *Incomplete*. A session that is still *In Progress*, or a pre-provisioned device sitting at *Pending* waiting for its user, is not an attempt.
* **A pre-provisioning enrollment is one attempt**, not two. The technician phase and the later user phase are the same session, and so the same attempt.
* **The journey ends at the first success.** A journey with a success is *completed* and can be counted; a device that has only failed so far has an *open* journey, which never enters the first-time-right rate in either direction.
* **More than 30 days** between the end of one attempt and the start of the next starts a **new journey**. A device redeployed half a year later is a fresh deployment, not a retry of the old one — its attempt counter starts at 1 again.
**First-time-right** is then simply the share of completed journeys that needed exactly one attempt. It is the metric that makes wipe-and-retry visible: the success rate counts enrollments, first-time-right counts devices.
## How completion is detected
There is no single "enrollment done" signal in Windows, so the agent combines several independent evidence paths — for example the IME's own completion reporting, the ESP process exiting together with the Windows Hello enrollment prompt, and the user reaching the desktop. Whichever path completes first ends the session; this redundancy keeps completion detection reliable across user-driven, pre-provisioning, and kiosk/self-deploying scenarios.
## Timeouts: what happens to stuck sessions
Three separate mechanisms make sure a session never stays *In Progress* forever — and that no agent is ever left behind on a device:
* **Agent maximum lifetime (on the device):** the agent stops after **6 hours of active time**. Time the device spends in standby or hibernation does not count, and the 6 hours start again after a reboot. If enrollment hasn't completed by then, the agent reports that it is stopping, performs a final upload, and cleans itself up. The session is then classified from its evidence (see below).
* **Session timeout (in the backend):** sessions that stop receiving events are reclassified out of *In Progress* after the configured **Session Timeout** (default **5 hours**, configurable 1–12 hours under **Configuration → Maintenance → Data Management**). Crucially, a silent session is **no longer blanket-marked *****Failed*** — the backend classifies it from the evidence it already has (see below).
* **48-hour emergency brake (on the device):** every time the agent starts — which is at every boot — it checks the age of its enrollment phase. If that phase began more than **48 hours** ago, the agent removes itself instead of starting, regardless of session status, connectivity, or error state. A device that is powered off, asleep, or not rebooted is cleaned up at its next start. With pre-provisioning, the technician phase and the user phase each have their own 48 hours; the agent stays installed while the sealed device waits for its user.
### Timeout ≠ failure
For a long time the 5-hour sweep marked *every* silent session **Failed**. That conflated "the agent stopped sending telemetry" with "the enrollment failed" and badly inflated failure rates — in practice the overwhelming majority of these "timeouts" were devices that had **finished Device Setup and were simply sitting at the login screen** waiting for a user, then completed the user phase hours (or a day) later.
The backend now decides the outcome from the last evidence in the timeline instead of hard-coding *Failed*:
| What the evidence shows | Result |
| ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| An explicit failure event (`enrollment_failed`, ESP failure) | **Failed** |
| Self-deploying profile (kiosk / shared device) and Device Setup finished | **Succeeded** (reconciled) — this profile has no user phase, so nothing is awaited |
| Account Setup fully succeeded, or a completion signal arrived | **Succeeded** (reconciled) |
| Device Setup finished, user phase not yet done, still within the grace window | **Awaiting User** |
| Grace window expired — but a real user desktop was observed and no app install failed | **Succeeded** (reconciled, "completed (assumed)") — nothing but the final report is missing, and these devices measurably stay in service like successful ones |
| Grace window expired with no completion and no failure | **Incomplete** |
| Silence before Device Setup even finished, with no failure event | **Incomplete** |
The agent's own max-lifetime shutdown is not a failure verdict either — the session is classified from the same evidence table. Because that shutdown proves the agent is gone for good, such a session skips the *Awaiting User* wait entirely and is decided immediately; a late completion signal (e.g. from Intune logs after the next boot) still corrects the verdict.
**The grace window** is anchored to the agent, not a magic number: the backend waits out the agent's 48-hour emergency brake plus a small buffer (\~**51 hours** by default) before settling *Awaiting User* → *Incomplete* — long enough that a legitimately late user completion still lands and **reconciles to *****Succeeded***. This costs nothing on the device: a waiting session is just a table row compared against a timestamp — no process, no heartbeat, no extra agent load.
{% hint style="info" %}
An **Incomplete** session means the **evidence stopped** without a verdict — a user may simply have shut the laptop mid-ESP, or the device went permanently offline. It is deliberately kept out of the failure rate. The session timeline still contains everything up to the last received event, and if a real completion or failure signal ever arrives, the status is corrected accordingly.
{% endhint %}
## Manual overrides (Admin Mode)
Admins can manually mark an *In Progress* or *Pending* session as **Succeeded** or **Failed** from the session detail page — useful when a session will clearly never complete on its own. Marking a session succeeded also signals the agent (if still running) to finish up and clean the device. These actions are gated behind the [Admin Mode](/concepts/roles-and-permissions.md#admin-mode) safety toggle.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.autopilotmonitor.com/concepts/sessions-and-statuses.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.