Terraform Plan Summary Analyzer

Introduction

A Terraform plan is the review document between intended infrastructure code and the changes Terraform is preparing to make. It is most useful when the reviewer can see more than the final add, change, and destroy counts. Replacements, output changes, drift, provider concentration, sensitive-field markers, and values that will remain unknown until apply can all change how much confidence a team should have before approving work.

Plan review gets harder as modules grow. A short terminal summary can hide a replacement inside a long scroll, and a large JSON plan can be too detailed for a pull-request comment or a change ticket. The practical job is to separate ordinary creates and updates from destructive changes, then preserve enough resource detail to let a reviewer ask the right follow-up questions.

Destructive changes deserve special treatment because Terraform can delete a resource directly or replace it by destroying and recreating it. Both paths can remove data, rotate identities, break dependencies, or create service interruption if the surrounding lifecycle and backup plan are not clear. A replacement count of one can be more important than a create count of twenty when that replacement touches a stateful or identity-bearing resource.

A plan summary is still a review aid, not an approval engine. It can show what Terraform reported, group resources by action, and draw attention to risky rows, but it cannot prove that a provider's behavior is safe, that a backup exists, or that the proposed timing is acceptable for the environment.

Technical Details

Terraform's machine-readable plan format represents planned resource changes as objects with an address, type, provider name, and a change block. The change block carries an action list rather than one single label. A replacement normally appears as both delete and create, so any summary that only looks for literal delete rows can understate destructive work.

The plan format also separates planned resource changes from output changes and drift information. Output changes matter because downstream automation may consume them. Drift entries matter because they point to differences between real infrastructure and recorded state. They should not be mixed blindly into the same headline count, but they should not disappear from review material either.

Some plan values are not known until apply. Terraform records those unknown leaves separately from known values, and it marks sensitive leaves so user interfaces can avoid exposing protected data. Those markers are review signals. They tell the reviewer that a resource may need extra attention even when the high-level action is an update or create instead of a delete.

Action Bucketing Used For Review

Gate And Risk Formula

The destructive gate is deliberately narrow. It compares planned deletes plus planned replacements with the chosen threshold. Drift rows, output changes, unknown value markers, and sensitive value markers still contribute to review context and risk scoring, but they do not change the destructive count itself.

Everyday Use & Decision Guide

Start with a saved plan converted through terraform show -json when you can. Paste the JSON, browse for a plan JSON or text file, or drop it into the plan field. Keep the workspace or stack name meaningful, because it appears in review rows and export filenames. If the plan is larger than a few megabytes, trim the workflow upstream or summarize per stack so the review stays readable.

Set Destructive review threshold to match your approval policy. Use 0 when every delete or replacement should trip the gate. Use a higher number only when your team has a clear reason, such as planned churn in a disposable test environment. A clear gate does not mean the plan is harmless. It only means the planned delete-plus-replace count is at or below the threshold you set.

• Read Apply Gate Snapshot first when you need a quick approval summary for a change ticket.
• Use Destructive Review Queue to focus on deletes, replacements, unknown actions, and rows with unknown or sensitive markers.
• Use Resource Change Ledger when you need a broader resource-by-resource handoff. Raise the row limit when a large plan needs more visible detail.
• Turn on Include no-op/read rows only when read and no-op context helps the audit trail. Leave it off for a focused review queue.
• Use Plan Action Mix and Provider Blast Radius to see whether one provider or action family dominates the change.
• Copy or download CSV, DOCX, chart images, chart CSV, or JSON when the review needs to move into a ticket, pull request, or release record.

If JSON parsing fails, the page scans recognizable Terraform text lines and the classic Plan: ... to add, ... to change, ... to destroy summary. That fallback is useful when someone pastes terminal output, but it has less structure than plan JSON. Treat fallback results as triage, not a full substitute for machine-readable plan data.

Plan content can contain resource names, account hints, network details, and sensitive values in the saved plan artifact. The analysis runs in the browser after the page loads, and selected files are read locally by the page, but copied rows, downloaded exports, and pasted text still need the same care as the original plan.

Step-by-Step Guide

1. Create a saved Terraform plan in your normal workflow, then convert it to JSON with terraform show -json <planfile>. Paste that JSON into the plan field, or load a file with the browse or drag-and-drop controls.
2. Name the workspace, stack, environment, or CI job under review. A concrete value such as prod-network keeps copied rows and exports tied to the right change.
3. Set the destructive threshold. Keep it at 0 for strict review gates where any delete or replacement should stop automatic approval.
4. Read the headline and badges. Confirm whether the page parsed plan JSON or fell back to text scanning, then check create, update, replace, and gate status before reading deeper rows.
5. Open Destructive Review Queue and inspect every high-risk row. For replacements, compare the reason and any replacement path with the change you expected.
6. Use Resource Change Ledger, Plan Action Mix, and Provider Blast Radius to spot concentration by resource type, action, or provider before exporting review evidence.
7. Copy the concise rows for a ticket, or download CSV, DOCX, chart image, chart CSV, or JSON artifacts when the approval record needs durable evidence.

Interpreting Results

The top summary answers the first approval question. Apply Review Required means the destructive count is above the threshold. Destructive Signal Found means at least one delete or replacement exists but the chosen threshold was not exceeded. Terraform Plan Summary means the parsed planned-resource actions did not contain deletes or replacements.

Changed is not the same thing as total rows parsed. It counts creates, updates, deletes, replacements, and unknown actions from planned resource changes. Output changes and drift rows are reported separately, and no-op or read rows are normally kept out of the headline so the review does not look larger than the material change set.

The review load score is a sorting and triage aid. Replacements and deletes weigh more than updates and creates. Unknown values, sensitive markers, drift, and output changes add weight because they increase review work. Do not treat the score as a policy grade. Use it to decide which rows deserve a human read first.

The provider chart is strongest when a plan touches many resource types. A heavy bar for one provider can show where a blast radius is concentrated, such as a large AWS change versus a small DNS-only update. It does not know the business importance of a provider or account. One small replacement can still matter more than a tall create bar.

Warnings about fallback parsing should slow the review down. Text scanning can identify common action lines and a summary count, but it cannot preserve the same structure as JSON plan data. If a release decision depends on replacement paths, sensitive markers, provider grouping, or exact output changes, get the JSON plan rather than relying on pasted terminal text.

Worked Examples

Strict production gate

A production networking stack has one security group update, one load balancer output update, and one instance replacement caused by an AMI change. Keep the destructive threshold at 0. The destructive count becomes 1 because the replacement is treated as destructive, and the gate trips. The next review step is to confirm the replacement path, lifecycle behavior, backup or cutover plan, and whether any downstream automation consumes the changed output.

This is the case where a small count still matters. The create and update totals may look routine, but the replacement row should control the approval conversation until the impact is understood.

Large non-destructive module rollout

A shared module rollout creates twenty logging resources and updates six tags without deletes or replacements. The destructive count remains 0, so a threshold of 0 stays clear. The action mix chart will show many creates, and the ledger can still reveal whether the resources are concentrated in one provider or spread across several services.

A clear gate is useful here, but it is not the only check. Quotas, naming conventions, policy attachments, and output changes still deserve review even when nothing is being destroyed.

Terminal text pasted during incident work

During a time-sensitive incident, someone pastes plain Terraform terminal output instead of JSON. The page cannot parse the JSON, so it scans lines such as resources that will be created, updated, destroyed, or replaced, and it also reads the terminal summary if present. The badges should show text scanning rather than plan JSON.

Use that result to identify the rough destructive count and obvious high-risk lines, then replace it with JSON evidence before final approval when the change has lasting infrastructure impact.

FAQ

Does a clear gate mean the plan is safe to apply?

No. A clear gate only means planned deletes plus replacements are at or below the threshold. Creates, updates, output changes, drift, provider-specific behavior, and operational timing can still make a plan risky.

Why are replacements counted with deletes?

A Terraform replacement destroys and recreates a resource. That can have the same operational danger as a direct delete when the resource is stateful, identity-bearing, externally referenced, or attached to production traffic.

Why does the page mention sensitive markers without showing secret values?

Terraform can mark sensitive leaves in the JSON structure. The review signal is that sensitive data is involved, not the secret itself. Keep the original plan artifact and any exports under the same access rules your team uses for infrastructure change records.

Can this replace policy-as-code checks?

No. It is a review and handoff aid. Policy engines can enforce organization-specific rules such as protected resource types, required tags, approved regions, or mandatory approvals. This summary helps humans see plan shape and risky rows quickly.

Why does text fallback show less detail?

Plain terminal output does not carry the full structured plan. It can expose recognizable action lines and summary counts, but it does not reliably preserve replacement paths, provider metadata, sensitive markers, output changes, or drift structure.

Glossary

Plan JSON

Machine-readable Terraform plan output produced from a saved plan with terraform show -json.

Replacement

A destroy-and-create change, commonly represented by both delete and create actions in the same resource change.

Destructive threshold

The allowed count of planned deletes plus replacements before the review gate trips.

Drift

A difference between real infrastructure and Terraform state or configuration detected during planning.

Unknown value

A value Terraform cannot determine until apply, marked separately from known planned values.

Sensitive marker

A flag indicating that a value is sensitive without displaying the value itself.

References

• Terraform show command reference
• Terraform JSON output format
• Terraform plan command reference