ECS LiveTaskCount Metric: What It Counts and Why

On October 13, 2026, AWS shipped the ECS LiveTaskCount metric, a free service-level metric that counts every task still doing work, including the ones on their way out. In the same announcement, AWS dropped the charge for RunningTaskCount in Container Insights, effective October 1. Small change, real consequences for how you alarm, scale, and read your CloudWatch bill. Let’s go through it like adults.

What the ECS LiveTaskCount metric counts

According to the AWS announcement, LiveTaskCount reports tasks in three lifecycle states: ACTIVATING, RUNNING, and DEACTIVATING. That last one is the point. A task that has been told to stop but is still draining connections during a scale-in event is still serving traffic, still burning CPU, and still billing you. Now it is also still counted.

The ECS metrics reference gives you the details you need to wire it up:

• Namespace: AWS/ECS
• Dimensions: ClusterName and ServiceName
• Statistics: Average, Minimum, Maximum
• Unit: Count

Two things stand out. First, it lives in the plain AWS/ECS namespace, so it does not require Container Insights. The announcement is explicit that it is part of ECS service utilization metrics and available to all customers at no additional charge. Second, it is available in every Region where ECS is. There is no opt-in, no cluster setting, no rollout flag.

RunningTaskCount vs LiveTaskCount

RunningTaskCount has been around in Container Insights for years. Per the Container Insights metrics reference, it lives in the ECS/ContainerInsights namespace with the same two dimensions, and it counts tasks currently in the RUNNING state. AWS describes the refined semantics as tasks whose current and desired state are both RUNNING. It is a health signal: is my service where I asked it to be?

That is a fine question, but a terrible capacity question. Walk through a scale-in:

1. Desired count drops from 10 to 6.
2. Four tasks flip their desired state to STOPPED and move into DEACTIVATING while the load balancer drains them.
3. RunningTaskCount drops to 6 immediately. LiveTaskCount stays at 10 until the draining tasks are gone.

If you size alarms, dashboards, or per-task math on RunningTaskCount, you are dividing traffic by a task count that is smaller than the number of tasks actually absorbing it. During a slow drain your requests-per-task number looks inflated, and you page someone for a problem that is mostly arithmetic.

The reverse is true too. ACTIVATING counts as live, so during a deployment or scale-out LiveTaskCount runs ahead of RunningTaskCount while new tasks pull images and pass health checks. Treat the gap between the two as a signal in itself: a persistent gap means tasks are stuck starting or stuck draining.

Pull the numbers

Before you rewrite anything, look at what your services actually do. This query works for a service today:

aws cloudwatch get-metric-statistics \
  --namespace AWS/ECS \
  --metric-name LiveTaskCount \
  --dimensions Name=ClusterName,Value=prod-cluster Name=ServiceName,Value=api \
  --start-time 2026-10-27T00:00:00Z \
  --end-time 2026-10-27T06:00:00Z \
  --period 60 \
  --statistics Average Maximum

Run the same call against RunningTaskCount in the ECS/ContainerInsights namespace and diff the two series around your last deployment. If the lines are identical, your drain times are short and your services are healthy. If they diverge for minutes, you have found a deregistration delay or a stop timeout that deserves a conversation.

Build a per-task load alarm that tells the truth

The practical win is a requests-per-task alarm using the live count as the denominator. Here is metric math for an ALB-fronted service, saved as metrics.json:

[
  {
    "Id": "req",
    "MetricStat": {
      "Metric": {
        "Namespace": "AWS/ApplicationELB",
        "MetricName": "RequestCount",
        "Dimensions": [
          { "Name": "LoadBalancer", "Value": "app/prod-alb/0123456789abcdef" }
        ]
      },
      "Period": 60,
      "Stat": "Sum"
    },
    "ReturnData": false
  },
  {
    "Id": "live",
    "MetricStat": {
      "Metric": {
        "Namespace": "AWS/ECS",
        "MetricName": "LiveTaskCount",
        "Dimensions": [
          { "Name": "ClusterName", "Value": "prod-cluster" },
          { "Name": "ServiceName", "Value": "api" }
        ]
      },
      "Period": 60,
      "Stat": "Average"
    },
    "ReturnData": false
  },
  {
    "Id": "perTask",
    "Expression": "req / live",
    "Label": "Requests per live task",
    "ReturnData": true
  }
]

Then create the alarm:

aws cloudwatch put-metric-alarm \
  --alarm-name api-requests-per-live-task \
  --metrics file://metrics.json \
  --comparison-operator GreaterThanThreshold \
  --threshold 3000 \
  --evaluation-periods 3 \
  --treat-missing-data notBreaching

The threshold of 3000 per minute is a placeholder. Pull a week of data and set it from your own p95, not from a blog post.

Do not mix it up with autoscaling inputs

LiveTaskCount is a capacity and monitoring signal. It is not a replacement for the metrics your target tracking policies use. If you want faster reaction, that is a separate feature: ECS supports 20-second CPU and memory resolution through the service monitoring configuration, with predefined high-resolution metric types for Application Auto Scaling, as laid out in the faster auto scaling guide. Those policies are not supported with the CODE_DEPLOY or EXTERNAL deployment controllers, so check how you deploy before you get excited.

Use LiveTaskCount where the question is “how many tasks are actually consuming resources right now”: per-task math, capacity floors, cost attribution, and dashboards your finance people will eventually screenshot.

The billing side: audit before you celebrate

Container Insights metrics are billed as custom metrics, per the ECS Container Insights docs, and performance log events landing in CloudWatch Logs are billed separately. The October 1 change removes the charge for RunningTaskCount specifically. The announcement does not publish the old per-metric dollar figure, and it points to the CloudWatch pricing page for examples. So do not promise anyone a number.

What you can do is measure. Compare your CloudWatch line items in Cost Explorer for September against the first full weeks of October, filtered to your accounts running ECS with Container Insights. Savings scale with how many services and clusters emit the metric, so the answer will be tiny for a handful of services and noticeable for a platform team running hundreds. Everything else Container Insights emits is still metered, so this is a rounding trim, not a reason to flip enhanced observability on everywhere.

Gotchas worth writing down

• ECS only sends metrics for resources with tasks in the RUNNING state. A service scaled to zero emits nothing, so a floor alarm on LiveTaskCount needs treat-missing-data set to breaching if zero tasks is an outage for you.
• Service metrics arrive at one-minute intervals by default. Do not build a sub-minute reaction on top of them.
• Statistics matter. Average smooths a flapping service; Minimum is what you want for a “never fewer than N” alarm, and Maximum for spotting deployment overlap.
• Existing dashboards built on RunningTaskCount keep working. Migrate the ones that make capacity decisions and leave the health widgets alone.

The headline is not the dollars. It is that AWS finally gave you a free, always-on number that matches what the service is actually running. Swap it into the places where “tasks” really means “capacity”, keep RunningTaskCount for health, and stop dividing your traffic by tasks that are still very much alive.

ENKOMPASS IS HERE TO HELP

At Enkompass (enkompass.net), this is our home turf. Our engineers tune ECS and Fargate scaling policies, alarms, and CloudWatch bills for a living, so we can tell you in an afternoon which metrics are earning their keep. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.