# Pair Run Command error limits with concurrency before a fleet rollout

> Stopping further dispatch does not stop commands already executing on managed nodes.

- Canonical URL: https://update.dsesecurity.com/updates/aws-ssm-run-command-error-threshold-concurrency/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:14:05+00:00
- Modified: 2026-10-20T18:34:30+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Stopping further dispatch does not stop commands already executing on managed nodes.

## Potentially affected

This describes Run Command fleet dispatch behavior. It is not an application rollback mechanism and does not describe Patch now concurrency defaults or every Automation control.

## DSE recommendation

DSE recommends treating both settings as part of the approved change.

## Article

Stopping further dispatch does not stop commands already executing on managed nodes.

## Source facts

Systems Manager Run Command accepts max-concurrency and max-errors as separate controls. The error limit stops dispatch to additional managed nodes after the allowed error count is exceeded. Commands already running are allowed to complete and may also fail. AWS advises concurrency of one when strict sequential failure control is required. The documented default for max-errors is zero, which stops additional dispatch after the first returned error.

Source: [AWS — Run commands at scale](https://docs.aws.amazon.com/systems-manager/latest/userguide/send-commands-multiple.html).

## Applicability

This describes Run Command fleet dispatch behavior. It is not an application rollback mechanism and does not describe Patch now concurrency defaults or every Automation control.

## DSE recommendation

DSE recommends treating both settings as part of the approved change. Start with a small, explicitly named target set and a harmless command, then decide how many simultaneous failures the service can tolerate. Write down the cancellation and recovery plan for nodes already running. Keep dynamic tag targeting under review so a larger target population cannot silently alter the intended rollout boundary. Separate the dispatch decision from the node-level recovery decision in the rollout record. Ask the change owner to identify the maximum acceptable in-flight population and explain how an operator will find those nodes if further dispatch stops during the pilot.

## Verification

Proposed verification: retain the target list, command ID, chosen limits and per-node results from a controlled pilot. Induce a harmless failure on an approved test node and compare subsequent dispatch with in-flight completions. Verify the rollback procedure separately before using the same pattern for a disruptive command.

## Official reference

[AWS — Run commands at scale](https://docs.aws.amazon.com/systems-manager/latest/userguide/send-commands-multiple.html). Reviewed October 20, 2026.

## Primary reference

- Name: AWS — Run commands at scale
- Authority: docs.aws.amazon.com
- URL: https://docs.aws.amazon.com/systems-manager/latest/userguide/send-commands-multiple.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Pair Run Command error limits with concurrency before a fleet rollout,” DSE Security, https://update.dsesecurity.com/updates/aws-ssm-run-command-error-threshold-concurrency/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.