Activity Log Shows "Command timed out"

Objective

To explain the causes behind a "COMMAND TIMED OUT" entry in the Automox Activity Log and provide actionable steps to resolve and prevent the error.

Overview

The "COMMAND TIMED OUT" error occurs when an executed policy, OS update, or Worklet script takes longer to complete than the Automox Agent's default timeout threshold, or when a script exits with a specific non-zero exit code.

Common Causes

• Policy Execution Delays: Large operating system patches (e.g., cumulative Windows updates or major feature updates) take longer to download and install than the standard execution window allows.

• Worklet Exit Code Mapping: On Windows devices, if a Worklet returns an exit 1 code, the Automox Agent translates this internally to exit 124, which displays in the Activity Log as "COMMAND TIMED OUT."

• Stalled OS Update Engine: The underlying Windows Update or Linux package manager process becomes hung or unresponsive, preventing the agent from receiving a completion signal.

Troubleshooting Steps

1. Check Windows Update & Package Manager Logs

If the timeout occurred during a standard patch policy, review the native OS update logs to determine if the installation was hung or simply taking longer than expected:

• For Windows, follow Microsoft's documentation to generate and review the logs via PowerShell:

  Get-WindowsUpdateLog

• For Linux, review /var/log/dpkg.log (Debian/Ubuntu) or /var/log/dnf.rpm.log (RHEL/Fedora).

2. Verify Actual Installation Status

In many cases, the patch or software installation finishes successfully on the endpoint shortly after the Automox Agent reports a timeout:

• Navigate to Devices > [Device Name] in the Automox console and manually trigger a scan to refresh the installed software inventory.

• Inspect the endpoint locally to confirm if the software or update installed despite the timeout log.

3. Update Worklet Script Exit Codes

If the timeout error occurs on a custom Worklet:

• Avoid returning Exit Code 1 (exit 1) in your script, as Automox maps this specifically to timeout status (124).

• Use alternative non-zero exit codes (such as exit 2 or exit 99) for general failures so that errors are correctly classified in the Activity Log.