Terraform · troubleshooting

Error: Invalid count argument

Terraform must know how many instances count makes before it plans, but your count comes from a value that only exists after apply, such as an ID. Derive count from values in your configuration instead, or apply the dependency first with -target as a one-off.

Reproduced on Terraform 1.14.0, 21 Oct 2026. Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published 21 Oct 2026

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

The error output, which names the file, line and the count expression.
terraform plan, and permission to apply if you use the -target workaround.

Run this first

step 1 of 2

terraform plan 2>&1 | grep -B2 -A8 'Invalid count argument'

Look for Which attribute in the count expression is (known after apply)

Shows the file, line and the expression.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Does the count expression read an attribute of another resource or module output?

Cause space

2 of 2 still possible

count is derived from an attribute known only after applyCommon
The dependency simply does not exist yetOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

Step 1
```
terraform plan 2>&1 | grep -B2 -A8 'Invalid count argument'
```
Shows the file, line and the expression.
Look for Which attribute in the count expression is (known after apply)
Step 2
```
terraform console <<< 'length(var.names)'
```
Checks that a replacement expression evaluates at plan time.
Look for A number, not (known after apply)

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

count is derived from an attribute known only after apply

Common

An ID, ARN, IP address or a value computed from one, often through a module output, feeds count. On a fresh environment it is unknown at plan time.

Confirm

terraform plan 2>&1 | grep -A4 'Invalid count argument'

The count expression, and which resource attribute it reads

Fix

Base count on values you control: a variable, a local list, or the input you passed to the other resource (for example length(var.subnet_cidrs) rather than length(aws_subnet.this[*].id)).
Use a boolean variable for create-or-not: count = var.enable_x ? 1 : 0.
Where the set of things is keyed by known names, switch to for_each over a map of those names; for_each has the same rule, so the keys must also be known.

count = length(var.names)

A value from configuration is known at plan time; an attribute the provider computes may not be.

The dependency simply does not exist yet

Occasional

The configuration is right in steady state, but on the very first apply of a new environment the resource count depends on has not been created.

Confirm

terraform state list | grep NAME

The resource count reads is not in state yet

Fix

As a one-off, apply the dependency first: terraform apply -target=RESOURCE_ADDRESS, then run a normal terraform apply.
Better, split the dependency into its own configuration or stage, so each apply plans with values that are known.

terraform apply -target=RESOURCE_ADDRESS

Then a normal plan and apply. Reproduced on Terraform 1.14.0.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Terraform works out the whole plan before it changes anything. count tells it how many copies of a resource to make, so it needs that number up front. If you calculate it from something that only exists once another resource is created, like an ID or an address the cloud assigns, the number is unknown at planning time and Terraform refuses to guess.

Words used on this page

count: A meta-argument that creates that many instances of a resource or module, addressed as NAME[0], NAME[1] and so on.
Known after apply: An attribute the provider sets only when the resource is created, such as an ID; at plan time its value is unknown.
-target: A plan or apply option that limits Terraform to the named resources and what they depend on. Meant for exceptional cases, not routine use.

What is actually happeningadvanced

Reproduced on Terraform 1.14.0 with count = length(split("-", terraform_data.list.id)): the id is only known after apply, so the plan stopped with Error: Invalid count argument and The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created.

The same configuration planned once count came from a value written in the configuration, length(terraform_data.list.input). The lesson is general: count may use variables, locals and attributes you set yourself, not attributes the provider computes.

Terraform 1.14.0 did know the length of a list whose contents were unknown, so not every unknown attribute fails; an ID, a computed string or a value derived from them does.

The error's own suggestion, -target, works: applying the dependency first made its id known, and the next full plan succeeded. It is a one-off workaround, not a design.

How to tell this is your problemsignals

Where	What you see
terraform plan	Error: Invalid count argument … The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.
Timing	Fails on a fresh environment, works where the dependency already exists in state

How to know it is actually fixed

terraform plan lists the instances NAME[0], NAME[1] … instead of the error.
A plan on a fresh environment (or a new workspace) also succeeds.

Stopping it happening again

Drive count and for_each from input variables and locals, not from provider-computed attributes.
Test configurations on an empty state, where unknown values show up, not only on an environment that already exists.

Security considerations

-target skips everything else in the configuration for that run; review the full plan afterwards so nothing is left half-applied.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it