Short answer: keep RunningTaskCount for health alarms, and use the new LiveTaskCount when the question is how much capacity is still serving traffic. AWS announced LiveTaskCount for Amazon ECS on October 13, 2026. It counts tasks that are starting up, running and draining connections, while RunningTaskCount only counts tasks that are steady and meant to stay. During a scale-in those two numbers drift apart, and an alarm reading the wrong one can either cry wolf or stay quiet when it shouldn't. For a business already running on ECS, this is a monitoring review worth an hour. It isn't a reason to move platforms, and it doesn't call for a new paid monitoring subscription.
What AWS changed, and when
The announcement page is marked "Posted on: Oct 13, 2026", and the AWS What's New feed timestamps it Tue, 13 Oct 2026 22:00:00 GMT. AWS describes LiveTaskCount as a new ECS service metric "available to all customers at no additional charge", delivered as part of ECS service utilization metrics, and it says the metric "does not require opting in to CloudWatch Container Insights."
The same announcement covers a second, separate change: a pricing change for the existing RunningTaskCount metric. AWS says no action is required and that it "takes effect beginning October 1, 2026, and applies automatically." Note the dates. October 1 is when that pricing change applies. It isn't the publication date, and AWS doesn't give it as a launch date for LiveTaskCount.
The two metrics count different things
The ECS developer guide is precise here. RunningTaskCount "counts the tasks whose current state and desired state are both RUNNING." A task that ECS has decided to stop has a desired state of STOPPED, so it drops out of RunningTaskCount the moment that decision is made, even if it's still finishing requests.
LiveTaskCount counts tasks in the ACTIVATING, RUNNING and DEACTIVATING states. That includes tasks that are draining connections. So when a service scales in from 10 tasks to 6, RunningTaskCount can show 6 while LiveTaskCount still shows 10 until the outgoing four finish draining and stop.
Neither number is wrong. They answer different questions.
- RunningTaskCount: how many tasks are settled and expected to keep serving. Good for health and minimum-capacity alarms, because a draining task is on its way out and shouldn't reassure you.
- LiveTaskCount: how many tasks exist and may still be handling traffic right now. Useful for capacity views, cost reasoning and explaining why a dashboard shows more tasks than your desired count during a deployment or scale-in.
One limit worth keeping in mind. LiveTaskCount is a task count. It doesn't tell you whether a task is ready for requests or whether those requests are succeeding. Load balancer target health, error rates and latency still do that job.
Where mismatched alarms cause trouble
The common failure shows up in dashboards and alarms built before this metric existed. Someone compares a task count against the service's desired count and gets confused during every scale-in, because the console, the load balancer and the alarm each seem to disagree. Or a scaling expression assumes tasks vanish the instant they're marked for removal, when in practice they keep holding connections for the length of the deregistration delay. Having both metrics available lets you state which question each alarm is meant to answer.
A safe way to review your existing alarms
Prerequisites: an ECS service you already run, read access to its CloudWatch alarms and dashboards, and a non-production environment or a quiet window where a controlled scale-in is acceptable. Nothing below needs Container Insights or any new paid feature.
- Inventory every alarm, dashboard widget and scaling expression that references a task count for the service. Write down which metric each one reads.
- For each one, write a single sentence naming the question it answers: "are enough healthy tasks staying up?" or "how much capacity is live right now?"
- Map health and minimum-capacity questions to RunningTaskCount. Map live-capacity questions to LiveTaskCount. Leave anything that already matches alone.
- In a test environment, or a low-traffic window, reduce the service's desired count by a small step and watch both metrics side by side until the draining tasks stop.
- Confirm each alarm behaved the way its sentence says it should. Only then change production alarms, and change them one at a time so a mistake is easy to trace.
- Check your CloudWatch bill and settings before enabling anything new. The ECS guide warns that metrics collected by Container Insights beyond the service utilization set "are charged as custom metrics", so don't switch it on just to get task counts.
What this means for cost
LiveTaskCount is free by AWS's own statement, and the RunningTaskCount pricing change applies automatically from October 1, 2026. That's the whole cost story for these two metrics. It doesn't make all CloudWatch monitoring free, so a review is a sensible moment to look at which paid metrics you're collecting and whether anyone actually reads them.
If your ECS alarms were set up quickly and never revisited, this is a cheap prompt to make each one mean something specific. That kind of tidy-up is routine infrastructure work, and it tends to pay off the first night an alarm fires and someone has to decide whether it's real.