Inside the Amazon ECS Managed Daemons Deployment View

On September 16, 2026, AWS announced a new view for Amazon ECS Managed Daemons that lets you check deployment status in one place in the console.

After you update a daemon, you open one console screen after another to find out whether the deployment is moving or stuck. If it fails, you trace through alarms and task logs to work out what went wrong in which capacity provider. Until now, you had to collect that information from several places.

Managed Daemons runs software agents, such as security, observability, and networking agents, by placing one daemon task on each instance and managing them centrally. It launched in April 2026, so it is still new.

This article explains what the view shows and how to check it in the console. It also covers three pitfalls that are easy to hit in production. The deployment stays in progress during bake time even after the progress bar reaches 100%. Settings you leave out of an update revert to their defaults. And alarms that are already in the ALARM state when a deployment begins are not used to decide a rollback. It is aimed at platform and infrastructure engineers who operate ECS, and it should also help anyone evaluating Managed Daemons.

First, here is a Before / After comparison of what this update changes.

The next section looks at each item in more detail.

The consolidated deployment view brings together five kinds of information. The rightmost column shows how each one appears in the console (labels translated from the Japanese console).

The next section, "Verification Steps", shows how these look on a real screen.

You can see the new deployment view just by updating a daemon in Managed Daemons. This section covers two cases: a rolling deployment that succeeds, and a deployment that fails and rolls back. For each, it gives the steps and what appears on screen. The screens described below are based on what I observed by running Managed Daemons myself. I used the Japanese-language console, so the English labels below are translations and may differ slightly from the English console.

Open the cluster in the Amazon ECS console, select the daemon on the Daemons tab, and open the Deployments tab on the daemon's detail page. The view added by this announcement is that tab. Below it, a "Daemon deployments" table lists past deployments.

To see the view, you need a cluster associated with an Amazon ECS Managed Instances capacity provider, and a daemon placed on that capacity provider. One daemon task runs per instance, so it also helps to start one application service to launch an instance. That makes the deployment progress easier to see. With no instances at all, there is nothing to migrate, so the progress bar barely moves.

Managed Instances launches real EC2 instances, so charges apply. When you finish, delete the service, the daemon, the capacity provider, and the cluster, in that order.

First, register a new revision of the daemon task definition with register-daemon-task-definition, then update the daemon with update-daemon. An update resets any settings you omit to their default values, so specify the drain percentage and bake time every time.

After you run the command, open the daemon's Deployments tab. An "In-progress deployment" section appears at the top. It can take a little while to show up, so reload it with the refresh button if you do not see it.

The deployment timeline shows "Deployment started" followed by "In progress", with the message "Instances are being migrated to the target revision." A progress bar appears for each capacity provider. Above the bar, counts such as "0 completed, 1 in progress, 0 remaining" are shown, and as the migration proceeds the completed count and the percentage increase.

In the "Daemon revisions" table at the bottom, the target revision (new) and the source revision (old) appear in separate rows, with counts such as "1 running" and "1 draining". Right after the update, the draining count on the source revision rises, and as the migration proceeds the running count on the target revision rises, so you can follow the swap. The drain percentage and bake time you set appear below the table.

On the right, "Monitoring" shows the circuit breaker as "Monitoring", along with a failed task count such as "0/3". If you have not configured an alarm or a container health check, they show "Off" and "Not configured".

Bake time deserves attention. Even after the progress bar reaches 100%, the timeline stays "In progress" while the bake time is in effect. With a bake time of 5 minutes, monitoring continues for another 5 minutes after the migration finishes. The timeline then changes to "Completed", and the circuit breaker changes to "Monitoring complete". After that, the total deployment duration appears, and the deployment is recorded with a "Successful" status in the "Daemon deployments" table.

You can reproduce a failure by registering a daemon task definition that points to a container image that does not exist, then updating to that revision. The command is the same update-daemon as above. If you omit --deployment-configuration, the update runs with the default drain percentage of 25% and bake time of 0 minutes. The "Daemon revisions" table shows these values.

A few minutes after the update, "Recent daemon task failure" appears under the progress bar on the deployment timeline. When the image cannot be pulled, it shows the error name CannotPullContainerError and an error message that includes the name of the image that failed. Directly below are three links, "View task details", "View logs", and "View troubleshooting guide", so you can start investigating the failed task from the deployment screen.

As failures accumulate, the failed task count under the circuit breaker in "Monitoring" climbs to "1/3", "2/3", and so on. When it reaches "3/3", the status changes to "Triggered". The timeline then adds "Migration interrupted", followed by "Rolling back" with the reason for the rollback. That reason message appears in English even when the console language is Japanese.

When the rollback finishes, the timeline ends with "Rolled back" and the total duration, and the "Daemon revisions" table shows the running count on the source revision (old) back to its original value. The failure details and links remain on the timeline after the rollback, so you can use them in a later review.

After a failure is confirmed, the rollback can take over ten minutes to start once image pull retries are included. That time varies with the type of failure and the settings, so allow some margin in production.

Even in an environment with a single instance, the progress bar can show counts for two instances, including the replacement. The official documentation does not describe how these counts are composed, so read the displayed values as they are.

The consolidated deployment view is for seeing the state of a deployment. Whether a deployment stops or rolls back is decided by the deployment settings. What matters is how you combine the deployment circuit breaker, CloudWatch alarms, bake time, and drain percentage. This section shows how each setting appears in the view.

Managed Daemons has a built-in deployment circuit breaker. The deployment configuration (drainPercent, alarms, and bakeTimeInMinutes) has no field for a threshold, and the circuit breaker is always active during an update. When it detects failures, Amazon ECS automatically rolls back to the previous revision.

What the console shows under "Monitoring" is the number of failed tasks. A problem such as tasks that start normally but degrade application performance is hard to catch with that number. CloudWatch alarms cover that case.

If you specify CloudWatch alarms in alarms in the deployment configuration, the deployment is rolled back automatically as soon as one of them enters the ALARM state. In the console, enable Use CloudWatch alarm(s) and select the alarms to monitor.

When you update a daemon, application tasks that were running on drained instances are also replaced automatically. An update therefore affects not only the daemon but also your applications. Choose alarms on metrics that would show the impact of an update, such as application error rate and latency, in addition to daemon metrics. That makes them a more useful safety net.

One caveat: Amazon ECS ignores alarms that are already in the ALARM state when the deployment begins. For example, if an alarm is firing for an unrelated reason when you update the daemon, that alarm is not used to decide a rollback. Before you update, confirm that the alarm you plan to use is in the OK state with the following command.

If the output is ALARM, resolve the cause before you update. If the alarm you specify is a composite alarm, add --alarm-types CompositeAlarm and change --query to CompositeAlarms[].StateValue.

Bake time (bakeTimeInMinutes in the API) is the time Amazon ECS waits after updating all instances before it completes the deployment. It accepts 0 to 1440 minutes (24 hours), and the default is 0. CloudWatch alarms are still monitored during this period, and the deployment rolls back if any alarm enters the ALARM state.

With the default of 0 minutes, the deployment completes as soon as all instances are updated, so alarms cannot catch a problem that appears after the update. If the impact tends to show up with a delay, set a bake time long enough to detect an anomaly, taking the aggregation period of the alarm's metric into account. A longer bake time delays completion by the same amount, so choose a value that balances the problem you want to detect against how long you can wait.

The drain percentage is the percentage of instances drained at the same time during a deployment. The default is 25%. For example, with 20%, instances are replaced 20% at a time. A higher value finishes the deployment faster but temporarily reduces available capacity. Because application tasks are also replaced during a daemon update, choose a value that leaves the capacity your applications need, and check the number of draining instances in the "Daemon revisions" table during the update.

As noted in "Verification Steps", an update resets any settings you omit to their defaults. The one that is easy to miss is critical. It controls what happens to the instance when a daemon task fails or stops. With true (the default), the instance is drained and replaced. With false (non-critical), the instance stays active and application tasks are unaffected. Omitting it in an update resets it to true. Specify every setting you need on each update. For example, to update with an alarm and a bake time:

For a non-critical daemon, add --no-critical to this command. If you forget it, the daemon reverts to critical behavior, where a daemon failure causes the instance to be drained and replaced.

How to follow a deployment while it runs is covered in "Verification Steps". This view is most useful after the fact, when you review what happened.

For a deployment that was rolled back, the details of the failure that interrupted it remain on the timeline after the rollback. You can trace "when, where, what happened, and how it was restored" in chronological order later. The "Daemon revisions" section also shows the drain percentage and bake time used in that deployment, which helps you judge whether the settings were appropriate.

Past deployments are listed in the "Daemon deployments" table at the bottom of the Deployments tab, with status, start time, end time, and duration. When you write a postmortem, you can open this screen and copy the timestamps and failure details to organize the facts.

The announcement and the documentation do not say how long deployment history remains available. For important incidents, save the timeline contents to your report or operations record early.

Before you start, keep two points in mind.

The consolidated deployment view is available only in the AWS Management Console. You cannot use it from code such as the AWS CLI, SDKs, CloudFormation, or Terraform. You can create and update Managed Daemons themselves from the CLI or CloudFormation, but you cannot use this view's screen from code.

That makes it a poor fit for judging deployment success in a CI/CD pipeline or sending automatic failure notifications. For those uses, you can retrieve deployment status with list-daemon-deployments and describe-daemon-deployments. Daemon task start failures can be detected with Amazon EventBridge events.

Managed Daemons is available for Amazon ECS Managed Instances. For ECS services on the EC2 launch type, a DAEMON scheduling strategy has long existed, but Managed Daemons is a separate, new capability. This view covers deployments of Managed Daemons.

For regular ECS service deployments, a separate deployment observability enhancement was announced in July 2026. It targets services that use rolling updates and is available from the Deployments tab of an ECS service. The names are similar, so be careful not to confuse the two.

Managed Daemons is new, so features and screens may change. Check the latest official documentation when you use it.

With this update, the information you need to follow a Managed Daemons deployment is on the daemon's Deployments tab. You no longer need to move between screens, whether you are watching an update or reviewing it afterward.

The view shows the result of your settings. Rollback conditions and how strict monitoring is are decided by the deployment settings. Because the view is console-only, use existing mechanisms for automation and notification.

If you use Managed Daemons, open the Deployments tab during your next update.