Terraform: provider crashes and "plugin did not respond"

TL;DR: Provider plugin panics show as crashes or timeouts, not config errors. Teaches distinguishing a provider bug from bad config and the version-bisection triage. Read the stack trace: it names the provider and usually the resource and operation. Check the provider version and its issue tracker.

The error

panic: runtime error: invalid memory address or nil pointer dereference
...

What you are seeing

panic: runtime error: invalid memory address or nil pointer dereference
...

or

Error: plugin did not respond

The provider process crashed or hung. Your config may be fine; the provider binary hit a bug, ran out of memory, or lost network access to its API mid-operation.

First response

1. Read the stack trace: it names the provider and usually the resource and operation. A nil-pointer in the provider's Read function is a provider bug, full stop.
2. Check the provider version and its issue tracker. Crashes are the most-reported provider issue category; there is often a fixed release already.
3. Bisect by version: pin to the previous release and retry. If the crash disappears, you have your answer and your workaround (pin) until the fix lands.
4. Rule out the environment: OOM kills look like hangs ("did not respond"). Check runner memory, especially with large plans on small CI runners.

Rules for agents

1. Do not rewrite config to dodge a provider crash until you have tried another provider version. Config churn around a provider bug wastes the most time.
2. Enable provider debug logging (TF_LOG=DEBUG) for one reproduction and attach it to the bug report. "It crashed" without logs gets closed.
3. If the crash happens during apply, check the real infrastructure before retrying. A crash after the API call succeeded leaves a real object with no state entry; retrying creates a duplicate.
4. Set a provider version pin as part of the fix so the next init does not reinstall the crashing version.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Terraform.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Also seen as

• Error: plugin did not respond

Provider crashes surface as panics or plugin timeouts; TF_LOG controls Terraform logging verbosity for diagnosis. Verified against live docs 2026-09-26. Verified against live docs 2026-09-26.