Every Terraform incident postmortem contains the same sentence: "the plan was reviewed and approved." The plan is always reviewed. The problem is how: a wall of diff text at the end of a long day, where aws_db_instance.orders must be replaced scrolls past with the same visual weight as a tag change.
"Replaced" means destroyed and recreated. On a database. That line deserves to be on fire, and in raw plan output it isn't.
So here's the Terraform Plan Analyzer: paste your terraform plan output (plain text or terraform show -json), and it flags every destructive change, risk-weights each resource by what it actually is, and gives the whole plan a blast-radius rating. Free, no sign-up, and fully client-side, which matters here more than anywhere else on my tools page: your infrastructure plan never leaves your browser. There is no server to trust, because there is no server.
What the risk weighting actually does
All destroys are not equal. The analyzer starts from the action (delete and replace score high, update low, create near zero) and then weights by resource family:
- Databases, object storage, persistent volumes: highest weight. Destruction here can mean unrecoverable data, not downtime.
- IAM and keys/secrets: high weight even on updates, because a "small" policy change is how privilege escalation ships.
- Security groups, network ACLs: high weight; these are your security boundary.
- DNS, load balancers, core networking: medium; wrong changes here are outages with wide reach.
- Everything else: scored by action alone.
Changes come back sorted by risk, so a plan with 40 changes shows you the three that can actually hurt you first. A summary rating (LOW / MEDIUM / HIGH) plus a "copy risk report" button gives you something to paste into the PR review instead of "LGTM".
The scoring is heuristic and honest about it: it reads resource types and names, not your architecture. It will never replace understanding your own plan. What it replaces is the scan-blindness of reading 400 lines of diff with tired eyes.
The replace trap, specifically
The single most dangerous word in Terraform output is "replaced", because it sounds like an upgrade and behaves like a demolition. Common triggers: changing an RDS identifier, an immutable attribute on a bucket, a launch configuration rename. The plan "succeeds", the apply "succeeds", and the data is gone in the gap between destroy and create.
When the analyzer sees a replace on a stateful resource, it says so explicitly and reminds you of the three questions that should block the apply: is create_before_destroy set, is deletion protection on, does a final snapshot exist? If you can't answer all three, the apply waits.
Where this fits: the machine reviews the machine
I wrote last week about why vibe infrastructure will page you at 3 AM: AI-generated infrastructure code is fluent, plausible, and wrong in the silent 5%, and human skim-review is precisely the wrong tool for catching it. The answer isn't slower humans; it's structure. Spend machine attention first, human attention last:
- Adversarial pass: an agent instructed to prove the diff is broken, which yields far more than "check this".
- This analyzer: paste the plan, read the ranked risks, not the raw wall.
- Policy scanners (tfsec, checkov, OPA) in CI.
- Deterministic guardrails: a terraform destroy guard hook for the mistakes that must never happen regardless of anyone's attention level. The $47K near-miss was caught by a hook, not by vigilance.
- A human, now reading a pre-annotated, risk-sorted change list.
The plan output was always the best early-warning signal in infrastructure work. It was just formatted like a punishment. Paste one in and see what your last apply actually looked like.