A Timed-Out Command Now Reports as a Failure
August 31, 2026 · InfraScout Team
Two changes to how remote commands behave, and the first one matters if you use InfraScout for remediation as well as assessment.
A deadline is now an error
When a command runs past its timeout_seconds, the agent stops it. At the operating-system level that stop is indistinguishable from a script exiting non-zero on its own terms — same shape of result, same kind of exit code. So a command the platform had killed came back looking like a command that had simply returned an error, and a remediation that never finished could be read as one that had completed.
A command stopped by its deadline now reports as an error that names the timeout and the remedy: raise timeout_seconds, or narrow the work. Nothing is removed from the result — the exit code, output and error output all still come back — it simply also carries a flag that cannot be overlooked.
One behavior change to plan for. A script that exits non-zero for its own reasons — a search that finds no match, a probe that returns 1 by design — is now also flagged as an error. Nothing is lost from the result, and it matches what the execution record always showed for the same command, but it is a change in meaning. If a non-zero exit is a legitimate outcome of your script, handle it in the script and exit zero.
Batches run across hosts in parallel
Commands issued in one turn are now serialized per target host and run in parallel across hosts. Two commands aimed at the same machine still queue behind each other, in order. Commands aimed at five different machines all start within milliseconds of each other, and the batch costs the slowest host rather than the sum of all five.
Previously the whole batch was serialized regardless of target. The intent was to stop two mutating scripts colliding on one host, which is a reasonable goal — it was just applied far more widely than it needed to be. The practical consequence was that a host near the end of a batch could reach its own deadline while waiting on machines it had nothing to do with.
Two reporting details follow from it:
- A queued call renders as queued. A call waiting its turn behind a sibling on the same host is shown as queued rather than running, so the transcript reflects what is actually executing on a host.
- A tool group reports wall-clock time. Five hosts working in parallel for a minute is a minute. The group header used to sum its members' durations, which was correct while dispatch was serial and overstates elapsed time once calls genuinely overlap.
How this reaches your fleet
The honest-timeout reporting is part of the agent, so it arrives on each host as your fleet takes its next update. The rest — the flag on the result, the parallel dispatch, and the queued rendering — is server-side and already live.
That split was deliberate. The flag corrects the misleading success indicator for agents already deployed, which cannot yet report their own timeouts.
See Agent Tools.
Questions or feedback? Reach us at info@infrascout.cloud.