Terraform PR cost comment workflow: putting dollars in the review

Quick answer

A PR cost comment workflow runs on every infrastructure pull request: it generates a Terraform plan, prices it statically against a catalog, and posts the monthly cost and diff as a comment on the GitHub or GitLab pull request, so reviewers see the cost beside the code. You build it as a CI job triggered on PRs that runs terraform plan, exports the plan JSON, runs a cost tool that comments via the platform API, and updates the same comment on each push. The goal is make the cost of a change a standing, automatic part of every review, updated as the PR evolves.

The pull request is where infrastructure decisions get reviewed, so it is where cost belongs. A cost comment workflow puts the monthly cost of a change directly in the review thread, automatically, on every push. Once it is running, no one has to remember to check cost; it is simply there, next to the diff, every time.

What the workflow does

Step	Action
Trigger	PR opened or updated
Plan	terraform plan, export JSON
Price	Cost tool prices the plan
Comment	Post cost and diff to the PR
Update	Edit the same comment on each push

The workflow triggers on pull request events, generates and prices the plan, and posts the result as a comment. On subsequent pushes it updates the existing comment rather than adding new ones, so the thread stays clean and always reflects the current state of the branch. That single, self-updating comment is the whole user-facing surface.

Building it on GitHub Actions

On GitHub Actions, a workflow triggered on pull_request checks out the code, runs terraform init and plan, exports the plan with terraform show -json, and runs the cost tool, which uses the repository token to post or update a comment. Because pricing iscredential-free, the job needs no cloud secrets, only the token to comment, so it runs safely even on fork PRs with a read-only token variant. This is the same shape asGitHub Actions cost estimation.

Building it on GitLab CI

On GitLab CI, a job in the merge request pipeline runs the same steps and posts the cost as a merge request note via the GitLab API using a project token. The pattern is identical: plan, price, comment, update. c3x supports both platforms from one CLI, so the same tool posts the comment whether the change lives in a GitHub PR or a GitLab MR, keeping the workflow consistent across a mixed estate.

What the comment should contain

A useful cost comment leads with the monthly cost delta of the change, shows the total for context, and breaks the delta down by resource so the driver is clear. Keep it concise, since a wall of numbers gets ignored. The best comments read like a review note: this change adds 180 dollars a month, driven by a new read replica. That single line is what turns cost into a normal review consideration.

Making it a standard

Add the workflow to your repository template so every new infrastructure repo inherits it, and require the cost check to run before merge so it is never skipped. Once it is a default, cost visibility spreads across the organization without per-team effort. Price your changes against theresource catalog so the comment reviewers read every day is grounded in real rates and stays trustworthy.

FAQ

What is a PR cost comment workflow?

It is a CI job that runs on every infrastructure pull request: it generates a Terraform plan, prices it statically against a catalog, and posts the monthly cost and diff as a comment on the GitHub or GitLab pull request, updating the same comment on each push. That puts the cost of a change beside the code so reviewers see it automatically.

How do I build a cost comment workflow on GitHub Actions?

Trigger a workflow on pull_request, check out the code, run terraform init and plan, export the plan with terraform show -json, and run a cost tool that uses the repository token to post or update a PR comment. Because pricing is credential-free, the job needs no cloud secrets, only the token to comment, so it runs safely even on fork PRs.

How do I post cost on a GitLab merge request?

Add a job to the merge request pipeline that runs terraform plan, exports the plan JSON, prices it, and posts the cost as a merge request note via the GitLab API using a project token. The pattern is identical to GitHub, plan, price, comment, update, and a tool that supports both platforms keeps the workflow consistent across a mixed estate.

What should a cost comment contain?

Lead with the monthly cost delta of the change, show the total for context, and break the delta down by resource so the driver is clear, kept concise so it is not ignored. The best comments read like a review note, such as this change adds a given amount per month driven by a new read replica, turning cost into a normal review consideration.

How does C3X post cost comments on PRs?

C3X reads your Terraform, prices the plan statically against a live catalog with no cloud credentials, and posts the monthly cost and diff as a comment on the GitHub pull request or GitLab merge request from a single CLI invocation, updating the same comment on each push. Supporting both platforms from one tool keeps the cost comment workflow consistent across a mixed estate.

What to do next

Put cost in every review thread. C3X prices your Terraform and comments the cost on GitHub and GitLab. Start with the quickstart.