# See which machines each deployment step ran on

Source: https://www.jawsdeploy.net/changelog/deployment-targets-api

Which machines are on the new version? Until now, answering that from a script meant reading the deployment log. Now it is one API call.

## What's new

**Deployment targets API.** [Get deployment targets](https://www.jawsdeploy.net/rest-api/deployments-targets) - `GET /api/deployment/targets` - lists every step of a deployment with the machines and cloud targets it matched, and what happened on each one: `executed`, `failed`, `timedOut`, `cancelled`, `skipped`, `notRun` or `error`. Add `targets=executed` to list only the targets a step was actually started on.

This is most useful after a rolling deployment that stopped part-way: machines the rollout never reached are reported as `notRun`, so you can see exactly which ones are still on the old version. A script that failed is reported as `failed` even when the agent finished the step normally, and a machine skipped by the step's execute condition is reported as `skipped`.

Integrations that read the deployment log to work this out can switch to this endpoint. Outcomes are recorded for deployments that run from this release on; older deployments still return their matched targets, with `outcomesAvailable: false`.

## Fixed

**No more false "Remote script idle" warnings.** An agent runs one script at a time, so when several steps target the same agent at once, the later scripts wait in its queue. Jaws Deploy used to report that wait as idle time - logging a warning every 30 seconds, and applying the step idle timeout to a script that had not even started. Those warnings raised the deployment's warning count, which could stop a lifecycle from moving on to its next phase. Waiting in the queue is now logged as information, and the idle warning and timeout apply only once the script is actually running. The deployment's maximum duration still limits the total wait.