Skip to main content

Troubleshooting

The subsections of this page address some of the well-known cases of errors that might occur in Fleet Control during patching or other operations. They mainly refer to the content of action logs, more information on which can be found in the Action logs section.

Generic event action output log for resource​

While viewing action logs, you may encounter generic messages instead of detailed output:

  • The action failed on the resource.
  • The action has been successfully executed.

These messages describe execution status at a high level. If they appear without a detailed log, see Fleet Control can't save action output log for resource.

Empty event action report view for resource​

If the event report view shows no resource data and the action log only displays a generic message, the output log likely wasn’t saved. See Fleet Control can't save action output log for resource.

Fleet Control can't save action output log for resource​

For resource-scoped actions, an action can complete successfully while the output log fails to save. In such cases the resource status can still show Success, even if the resource’s log is unavailable.

note

Fleet Control shows log output issues in several places across the UI, including Events, Event details, Report View, and Resource Details. See Action Status, Action logs, and Report view for a quick explanation of the indicators.

Symptoms:

Refer to the causes and remedies below to resolve the issue.

Possible causes and remedies​

Target instance having insufficient permissions​

info

Applies only to AWS EC2 instances.

SSM Agent utilizes native AWS functionality to perform its tasks on EC2 instances. For this reason, EC2 instances must have necessary permissions configured.

EC2 instance either doesn't have an Instance Profile attached, or the Instance Profile doesn't have the necessary permissions to write to the S3 bucket that stores the logs. The missing permissions might include KMS key access or PutObject S3 action. A section on cloud account adding describes which policies are required for the Instance Profile.

Firewall rules blocking the connection to the logs storing S3 bucket​

The instance is unable to connect to the S3 bucket due to firewall rules. Please check firewall configuration for a list of endpoints that need to be accessible for Fleet Control to function properly.

Debugging using SSM Agent logs

The SSM Agent logs can be very helpful in troubleshooting log-save failures. The agent records every attempt to upload logs to the Fleet Control bucket and saves it locally on the instance.

  1. Locate the logs on the target instance:

    • Windows: %PROGRAMDATA%\Amazon\SSM\Logs\
    • Linux: /var/log/amazon/ssm/

  2. Search for S3 upload errors: In the errors.log (or amazon-ssm-agent.log) file, search for lines containing S3Upload and AccessDenied. For example:

    2026-02-04 15:58:34.6637 ERROR [S3Upload @ s3util.go.135] ... [DataBackend] ... Failed to upload ... to s3://nordcloud-autopatcher-outputs-... err:AccessDenied: Access Denied

  3. Identify the bucket and verify permissions: The log entry will specify the bucket name the agent was trying to upload to. If you see AccessDenied, double-check that your EC2 Instance Profile has the required permissions for that specific bucket.

If you cannot find such errors but logs are still missing, you can zip the entire Logs directory and attach it to a support ticket for further investigation.

See the AWS documentation for more details on SSM Agent logs.

Cloud account error statuses​

  • Access Missing:

  • Access Error:

    • In AWS case: The role used by FleetControl (default name: NordcloudFleetControlServiceRole) has been removed or External ID has been changed. Please refer to the AWS documentation for External ID explanation.
    • In Azure case: Service Principal might have been removed or credentials could have expired. This article in Azure documentation describes credentials expiry.
    • In Google Cloud case: Service Account might have been removed or credentials could have expired. Please refer to the Google Cloud documentation for details.
    • In IBM Cloud case: Service ID might have been removed or credentials could have expired. Please refer to the IBM Cloud documentation for details.

  • Regions Unavailable:

    • This error indicates that one or more regions could not be accessed. Please check the error details in the account details view and hover on the region name to see the error message.
tip

You can hover on a region colored red to see the error message, as returned by the cloud provider.

"Lost Connection" resource status​

If a resource is running, but has "Lost Connection" status in the Fleet Control, this most likely means that the SSM Agent on the instance has connectivity issues. Possible causes include:

  • SSM Agent is not running on the instance.
  • Instance is behind a firewall that prevents the SSM Agent from connecting to the AWS SSM service. Please make sure the endpoints listed in the firewall configuration page are reachable from the instance.
  • AWS instances only: the instance might not have a role attached, or the role attached does not include the AmazonSSMManagedInstanceCore policy. Please refer to the IAM mode section in the SSM Agent user guide for details.
info

Please keep in mind that resources states are updated periodically, so it might take a while for the status to be updated.

Actions fail right after Start Virtual Machine​

If an SSM-based action that runs after Start Virtual Machine ends with Error status on an AWS EC2 instance, and the action log shows a message such as:

sending command: InvalidInstanceId: Instances [[i-12345]] not in a valid state for account 123456789012

the instance was not in a valid state for the SSM command when the action started. Right after a start, this may mean the SSM Agent had not connected yet because the instance was still booting. The same error can also have other causes, such as the instance not being managed by SSM in that account or region. If the error persists after the instance has had time to boot, see "Lost Connection" resource status for other possible causes.

The Start Virtual Machine action waits only for the cloud provider's response. It does not wait for the operating system to boot or for the SSM Agent to connect. On Azure, the action can succeed even if the virtual machine has not reached PowerState/running. For details, see What happens when a virtual machine starts.

The resource may also show Lost Connection for a while after it starts, because resource states are updated periodically.

What to do​

  • If the next action starts too soon, add a Delay action after the Start Virtual Machine action, or set its Skip Window to Never, so the virtual machines have time to boot before the next action.

  • Inside an Action Batch, actions run one after another on each resource without a wait. Run the Start Virtual Machine action as a separate plan step before the batch, followed by a Delay action or with its Skip Window set to Never.

  • If the error persists after an existing delay, increasing the delay is unlikely to help. Collect the SSM Agent logs from an affected virtual machine and check for startup, authentication, or connectivity errors:

    • Windows: %PROGRAMDATA%\Amazon\SSM\Logs\
    • Linux: /var/log/amazon/ssm/

    See the AWS documentation about SSM Agent logs and the "Lost Connection" resource status troubleshooting steps.

  • If the Start Virtual Machine action log for the resource contains current_status, check it. It shows the last state the action observed.

  • Rerun the failed action once the resource shows as online.

Resource X is missing access​

Possible cause​

The SSM Agent is not installed or running on the target VM, preventing FleetControl from managing patching or access.

Remediation steps​

  • Verify SSM Agent status on the VM using system logs or AWS Systems Manager console.

  • Install SSM Agent following FleetControl documentation: Installing SSM Agent. For AWS EC2 instances, it's often pre-installed, ensure IAM policies allow access. For hybrid/non-AWS VMs, download and run the provided installer binary (e.g., ./installer.exe install).​

  • After installation, confirm registration in FleetControl and retry patching.