Deployment states
A reference for the Deployments view: what each status means, what moves a run between them, and what you can see about a run once it has started.
Deployments are reported by the desktop agent on each host as the work happens. The web app records and displays them. Nothing here is something you set by hand.
Statuses
| Status | Meaning |
|---|---|
| Pending | The run exists but has not started executing. |
| Running | Steps are executing. |
| Rebooting | A step restarted the machine. The run is waiting for it to come back. |
| Blocked | A step cannot continue yet and is waiting. |
| Success | Every step finished. |
| Failed | A step failed and the run stopped. |
| Cancelled | The run was stopped before it finished. |
Rebooting and Blocked are not errors. Windows deployment restarts machines as a matter of course, and a run that reboots is doing what it was told to. Both states clear on their own when the device reports that it has moved on.
What moves a run between states
The agent reports events, and certain events change the status:
| The agent reports | The run becomes |
|---|---|
| A reboot has started, with how long it expects to take | Rebooting |
| The run has resumed after a reboot | Running |
| A step is blocked | Blocked |
| The step is no longer blocked | Running |
Any other event the agent sends is recorded against the run without changing its status.
A run whose agent reports nothing for 2 hours is marked Failed with the message "No activity from the desktop agent for 2 hours". This closes runs whose machine lost power or whose agent stopped, so they no longer count toward your plan's simultaneous workflow runs.
A run is also marked Failed, with the message "The desktop agent started a new run on this host before this one finished", when the machine's desktop agent starts another run on its own while the earlier one still shows as running. A desktop agent runs one workflow at a time, so the earlier run was abandoned.
May need attention
An active run that has reported nothing for 60 seconds is flagged in the list as possibly needing attention.
This is a hint, not a verdict. The most common cause is that the machine is waiting on something the web app cannot see, such as a dialog on the console asking a question that nobody has answered. Deployments that legitimately take longer than a minute between progress reports pick up the same marker.
The flag clears as soon as the run reports again, and applies only to Pending, Running, Rebooting, and Blocked runs. A finished run is never flagged.
Reading the Deployments view
The view refreshes on its own while Live is on. Turn it off to hold the list still while you read it.
Three filters narrow the list:
| Filter | Options |
|---|---|
| Host | Free text search against the device name |
| Status | All statuses, Running, Rebooting, Blocked, Success, Failed, Cancelled |
| Recency | Today, 24h, 7d, All |
Each row shows the device, the run's status, and how far it has got through the workflow's steps.
What a single run shows
Selecting a run opens a panel with four sections.
Host. What the agent reported about the machine when the run started. Hostname, host ID, MAC address, IP address, and the technician's name, along with a hardware snapshot you can expand. Only the fields the agent actually sent appear, so a sparse panel means a sparse report, not a problem.
Steps. Each step of the workflow with its outcome. A run that failed before recording anything shows "No step records for this deployment."
Activity. Events and logs from the run, in order.
Artifacts. Files the run produced and uploaded.
Artifacts count against your plan's storage allowance, the same as files you upload yourself. See Plan limits and usage.
The panel header carries when the run started, how long it has taken, and the error message if it failed.
Stopping a run
While a run is active, the panel offers Abort.
Aborting is a request, not a switch. The web app records it and the agent acts on it when it next reports in, so the run does not stop the instant you select it. Until the agent responds, the panel shows "Aborting..." in place of the button, and hovering it tells you when the abort was requested.
Aborting needs the Admin or Owner role.
Who can see deployments
Every role can read deployments, including Viewer. See Roles and permissions.
The Deployments view needs an active subscription, like the rest of the app.
Related
- How Coldsea Deploy works for where runs come from.
- Your first deployment for building and publishing the workflow a run executes.