Operate an evaluation
This guide is for the person running a guided evaluation. Keep the commands, configuration and recovery procedure for your installation together so you can repeat routine tasks and diagnose problems.
Keep an installation record
Section titled “Keep an installation record”Record the candidate version, image digests, Windows package checksums, configured origins, data-volume locations and the operator responsible for identity and signing. Keep credentials separately. This distinguishes an actual installation from a collection of similarly tagged images.
Starting and stopping
Section titled “Starting and stopping”Use the lifecycle commands supplied with your installation. A Windows draft runner is a separate process; starting Docker containers alone does not start it. Save draft edits before closing a session or restarting services.
After a restart, check Console access, the selected workspace and draft-runner availability. Temporary test results can expire across API restarts even when the saved draft remains intact. Do not replay an operation with an unknown outcome simply because its temporary result is no longer visible.
Stopping a container is different from deleting its data. Avoid volume-removal commands during routine troubleshooting.
Health and useful diagnostics
Section titled “Health and useful diagnostics”| Observation | What it tells you |
|---|---|
Console /health/live | The Console process responds. |
Console /health/ready | The Console reports its configured readiness posture. |
API /api/enterprise/health | The API reports non-sensitive health posture. |
| A real sign-in and workspace read | Identity and scope authorization work for that account. |
| Successful synthetic draft test | The API can use the configured runner for that source. |
Collect a small log window around the failure, its time and the build identity. Redact credentials, cookies, raw headers and private source data before sharing. For an unavailable draft runner, its window and startup diagnostics may be more useful than the API’s connection error alone.
Campaigns and fleet
Section titled “Campaigns and fleet”Use the Console’s operations views to inspect the exact campaign and enrolled host. Distinguish queued work, active execution and terminal outcomes. A connected host can still lack the policy or capability needed by a particular job.
Review the impact before pause, drain, cancellation or recovery. Pause stops new dispatch while active work can continue; draining a Node also permits active work to finish. A requested stop is not evidence that a remote process has already terminated. Follow the operation’s current confirmation and reported outcome.
Data and recovery
Section titled “Data and recovery”Database state, retained artifacts, identity-provider state, Git repositories, signing material and Console session-protection keys have different storage needs. A database dump alone is not a complete installation backup.
The recovery image includes PostgreSQL tooling and catalog consistency checks. Recovery procedures are installation-specific in this alpha. Agree on what to back up and how to restore it with the operator, then test that procedure before relying on the installation to preserve valuable work.
Upgrades
Section titled “Upgrades”There is no documented general rollback guarantee for this alpha. Review the matching release notes, migration plan and package inventory with the operator before an upgrade. Preserve data and configuration, and keep API, Console, execution hosts and signing tools on a reviewed compatible set.
Use troubleshooting for symptoms and alpha availability for packages and access.