The recent enhancement to AWS Systems Manager Automation introduces a new WarningMessage field that surfaces non‑critical issues directly in automation execution results. This addition marks a subtle but important shift in how AWS communicates potential problems that do not halt a workflow but nevertheless merit attention. By surfacing these warnings through the API, engineers gain early visibility into conditions such as deprecated runtime usage, configuration mismatches, or resource throttling that could evolve into failures if left unchecked. The feature is especially valuable for teams that rely on large fleets of automated tasks, where a silent degradation can accumulate over dozens of executions and affect overall reliability. In this post we unpack the motivation behind the field, illustrate its behavior with a concrete example, and discuss how organizations can integrate the signal into their operational practices to maintain healthier automation pipelines.
AWS Systems Manager Automation is a cornerstone of many cloud‑native operational strategies, enabling the orchestration of tasks ranging from patch management to complex multi‑step workflows without the need for custom scripting frameworks. Historically, the service reported only binary outcomes—success or failure—leaving operators to infer subtle problems from logs or step outputs after the fact. This model works well for catastrophic errors but falls short when the automation completes successfully while relying on outdated components, misconfigured parameters, or transient throttling events. The new WarningMessage field closes that gap by providing a structured, machine‑readable note that appears alongside the standard status fields. Because the warning is attached to either the overall execution or an individual step, it offers granular context that helps teams pinpoint exactly where a deviation occurred, facilitating faster remediation and reducing the mean time to detect operational drift.
The field was first noted in the changelog for AWS CLI version 2.36.5, where AWS documented its inclusion in the response payloads of several Automation‑related API calls. Specifically, WarningMessage now appears in the results of GetAutomationExecution, DescribeAutomationExecutions, and related actions that return execution metadata. At the execution level, the message captures any non‑critical condition that affected the workflow as a whole, while at the step level it is present only when the step’s status includes a warning flag. This dual‑granularity design ensures that the signal is both broad enough to catch systemic issues and precise enough to highlight problematic actions within a runbook. By embedding the warning directly in the API response, AWS enables automation tooling, CI/CD pipelines, and custom monitoring scripts to consume the information without needing to parse console banners or log streams.
Understanding the distinction between execution‑level and step‑level warnings is essential for interpreting the new field correctly. An execution‑level WarningMessage indicates that something noteworthy happened during the run, such as the use of a deprecated runtime across one or more steps, but the overall workflow still reached a terminal success state. In contrast, a step‑level warning is attached to a specific step whose status is marked as Warning (as opposed to Success or Failure), and the message explains why that step did not achieve a clean success. Because the step‑level variant only appears when the step status itself includes a warning, it provides a clear cause‑effect relationship: the step encountered a condition that AWS deemed worthy of notice, yet not severe enough to halt the step’s execution. This layered approach lets operators prioritize investigations: execution‑level warnings prompt a review of the runbook’s overall health, while step‑level warnings guide targeted fixes to individual actions.
One of the first practical uses of the WarningMessage field is to alert users when an automation references a runtime version that AWS has marked as deprecated. In the example highlighted in the original article, a runbook that explicitly requested the python3.6 interpreter for an aws:executeScript step triggered a warning even though the step completed successfully. The service automatically upgraded the underlying container to python3.11 during execution, preserving functionality while informing the user that the originally requested runtime is no longer supported. The warning message reads: “Runbook HelloWorld-DeprecatedRuntime has one or more steps using aws:executeScript action with deprecated runtime. They were automatically upgraded to python3.11 runtime during the execution of the steps. Please update the runbook to use a supported runtime.” This proactive notice helps teams avoid reliance on runtimes that may eventually be removed, reducing the risk of sudden breakage when AWS phases out the underlying support.
To reproduce the warning, the author created a minimal Automation document—essentially a Hello World runbook—that contained a single aws:executeScript step with the runtime property set to python3.6. Notably, the creation of the document itself did not generate any error; AWS Systems Manager allowed the runbook to be registered despite the outdated runtime specifier. This behavior reflects the service’s design philosophy of being permissive at registration time, deferring validation and potential mitigation to execution time. By postponing the check, AWS avoids blocking legitimate workflows that might rely on runtime auto‑upgrade mechanisms, while still providing an opportunity to inform users about the substitution at runtime. The approach balances flexibility with safety, ensuring that users are not prevented from deploying runbooks that could still function correctly thanks to built‑in compatibility layers.
The fact that document creation succeeded even with a deprecated runtime specifier underscores an important operational nuance: warnings are intended to be informational rather than prohibitive at the point of authoring. This design choice acknowledges that many organizations maintain large libraries of runbooks that may have been authored before runtime deprecations were announced. Blocking creation would impose unnecessary friction and could hinder legitimate automation efforts that depend on internal versioning schemes or custom AMI‑based scripts. Instead, AWS opts to surface the issue when the runbook is actually invoked, giving teams a chance to notice the warning in execution logs or console banners and plan a migration path without disrupting ongoing operations. For teams practicing continuous delivery, this model aligns well with shift‑left principles, as the warning can be caught early in testing pipelines before promotion to production.
After executing the test runbook, the GetAutomationExecution API returned a top‑level status of Success, indicating that the workflow completed without encountering any fatal errors. However, digging into the step‑level output revealed two telling fields: IsRuntimeAutoUpgraded set to true and ExecutedRuntime showing python3.11. These details confirm that the service detected the requested python3.6 runtime, recognized it as deprecated, and silently substituted the newer, supported version during step execution. The automation therefore achieved its intended output while simultaneously emitting a WarningMessage that documented the substitution. This dual outcome—successful execution paired with a warning—illustrates how the new field enriches the traditional success/failure dichotomy with nuanced operational insight, enabling teams to distinguish between a clean run and one that relied on compatibility shims.
When the same execution was inspected via the AWS Management Console, a prominent yellow banner appeared at the top of the Automation execution details page, displaying the full warning message verbatim. The banner’s visual prominence ensures that even operators who primarily rely on the console for troubleshooting will notice the alert without needing to dive into raw API responses or log files. The message clearly articulates what occurred: the runbook used a deprecated runtime, the service automatically upgraded it to python3.11, and it advises the user to update the runbook to a supported runtime. By presenting the warning in a consistent UI element, AWS reduces the cognitive load on engineers and helps standardize the response to such notifications across teams, fostering a culture where warnings are acted upon rather than ignored.
The presence of a WarningMessage despite an overall Success status carries significant implications for automation hygiene and long‑term maintainability. It signals that while the immediate task succeeded, the underlying assumptions—such as reliance on a specific interpreter version—may no longer be valid in future releases of the service or the underlying platform. Ignoring such warnings can lead to technical debt accumulation, where a fleet of runbooks continues to function only because of backward‑compatibility layers that may eventually be withdrawn. By treating warnings as actionable items, organizations can prioritize refactoring efforts, update runtime specifications, and validate that their automation remains resilient against platform evolutions. Moreover, the warning can be integrated into automated governance checks, ensuring that any runbook that triggers a deprecation notice fails a compliance gate until the issue is addressed.
From a market perspective, the introduction of structured warning fields reflects a broader industry trend toward enriched observability and proactive incident prevention. As cloud platforms mature, providers are shifting from purely reactive alerting—based on metrics that breach thresholds—to delivering contextual hints that help users anticipate problems before they impact service levels. This approach aligns with the growing adoption of Site Reliability Engineering (SLO‑driven) practices, where error budgets are consumed not only by outages but also by subtle degradations that increase operational risk. By furnishing automation users with machine‑readable warnings, AWS enables tighter integration with policy‑as‑code tools, continuous validation frameworks, and automated remediation workflows, thereby supporting the shift from manual ticket‑driven processes to self‑healing, policy‑governed operations.
To harness the WarningMessage field effectively, teams should adopt several concrete practices. First, incorporate the field into any automation‑monitoring pipeline: retrieve GetAutomationExecution results and flag executions where WarningMessage is non‑empty, treating them as warnings in your alerting system. Second, enforce runbook linting rules that prohibit the use of deprecated runtimes or other known anti‑patterns, causing the CI/CD pipeline to fail early if such patterns are detected. Third, periodically review existing runbooks for warnings generated in production executions, creating a backlog of items to refactor. Fourth, leverage the IsRuntimeAutoUpgraded and ExecutedRuntime fields to automatically generate upgrade pull requests that replace deprecated runtime specifications with the version actually used. Finally, educate operators and developers on the meaning of these warnings, encouraging a mindset where a successful run with a warning is still an invitation to improve, rather than a false sense of security. By operationalizing the WarningMessage signal, organizations can maintain automation that is not only functionally correct today but also adaptable to the evolving AWS landscape.