Machine-Readable UI
Note: This format is available in Terraform 0.15.3 and later.
By default, many Terraform commands display UI output as unstructured text, intended to be read by a user via a terminal emulator. This text stream is not a stable interface for integrations. Some commands support a -json
flag, which enables a structured JSON output mode with a defined interface.
For long-running commands such as plan
, apply
, refresh
, and test
, the -json
flag outputs a stream of JSON UI messages, one per line. These can be processed one message at a time, with integrating software filtering, combining, or modifying the output as desired.
The first message output has type version
, and includes a ui
key, which as of Terraform 1.1.0 has
value "1.0"
. The semantics of this version are:
- We will increment the minor version, e.g.
"1.1"
, for backward-compatible changes or additions. Ignore any object properties with unrecognized names to remain forward-compatible with future minor versions. - We will increment the major version, e.g.
"2.0"
, for changes that are not backward-compatible. Reject any input which reports an unsupported major version.
We will introduce new major versions only within the bounds of the Terraform 1.0 Compatibility Promises.
Sample JSON Output
Below is sample output from running terraform apply -json
:
Each line consists of a JSON object with several keys common to all messages. These are:
@level
: this is normally "info", but can be "error" or "warn" when showing diagnostics@message
: a human-readable summary of the contents of this message@module
: always "terraform.ui" when rendering UI output@timestamp
: an RFC3339 timestamp of when the message was outputtype
: defines which kind of message this is and determines how to interpret other keys which may be present
Clients presenting the logs as a user interface should handle unexpected message types by presenting at least the @message
field to the user.
Messages will be emitted as events occur to trigger them. This means that messages related to several resources may be interleaved (if Terraform is running with concurrency above 1). The resource
object value can be used to link multiple messages about a single resource.
Message Types
The following message types are supported:
Generic Messages
version
: information about the Terraform version and the version of the schema used for the following messageslog
: unstructured human-readable log linesdiagnostic
: diagnostic warning or error messages; see theterraform validate
docs for more details on the format
Operation Results
resource_drift
: describes a detected change to a single resource made outside of Terraformplanned_change
: describes a planned change to a single resourcechange_summary
: summary of all planned or applied changesoutputs
: list of all root module outputs
Resource Progress
apply_start
,apply_progress
,apply_complete
,apply_errored
: sequence of messages indicating progress of a single resource through applyprovision_start
,provision_progress
,provision_complete
,provision_errored
: sequence of messages indicating progress of a single provisioner steprefresh_start
,refresh_complete
: sequence of messages indicating progress of a single resource through refresh
Test Results
test_abstract
: describes the test operation that Terraform executestest_file
: describes the status of a completed test filetest_run
: describes the status of a completedrun
block within a test filetest_cleanup
: describes the result of the test cleanup after a completed test filetest_summary
: describes the overall status of the completed test operationtest_plan
: describes the output of a givenrun
block whencommand = plan
test_state
: describes the output of a givenrun
block whencommand = apply
test_interrupt
: describes the result of an interrupted test operation
Version Message
A machine-readable UI command output will always begin with a version
message. The following message-specific keys are defined:
terraform
: the Terraform version which emitted this messageui
: the machine-readable UI schema version defining the meaning of the following messages
Example
Resource Drift
If drift is detected during planning, Terraform will emit a resource_drift
message for each resource which has changed outside of Terraform. This message has an embedded change
object with the following keys:
resource
: object describing the address of the resource to be changed; see resource object below for detailsaction
: the action planned to be taken for the resource. Values:update
,delete
.
This message does not include details about the exact changes which caused the change to be planned. That information is available in the JSON plan output.
Example
Planned Change
At the end of a plan or before an apply, Terraform will emit a planned_change
message for each resource which has changes to apply. This message has an embedded change
object with the following keys:
resource
: object describing the address of the resource to be changed; see resource object below for detailsprevious_resource
: object describing the previous address of the resource, if this change includes a configuration-driven moveaction
: the action planned to be taken for the resource. Values:noop
,create
,read
,update
,replace
,delete
,move
.reason
: an optional reason for the change, only used when the action isreplace
ordelete
. Values:tainted
: resource was marked as taintedrequested
: user requested that the resource be replaced, for example via the-replace
plan flagcannot_update
: changes to configuration force the resource to be deleted and created rather than updateddelete_because_no_resource_config
: no matching resource in configurationdelete_because_wrong_repetition
: resource instance key has no correspondingcount
orfor_each
in configurationdelete_because_count_index
: resource instance key is outside the range of thecount
argumentdelete_because_each_key
: resource instance key is not included in thefor_each
argumentdelete_because_no_module
: enclosing module instance is not in configuration
This message does not include details about the exact changes which caused the change to be planned. That information is available in the JSON plan output.
Example
Change Summary
Terraform outputs a change summary when a plan or apply operation completes. Both message types include a changes
object, which has the following keys:
add
: count of resources to be created (including as part of replacement)change
: count of resources to be changed in-placeremove
: count of resources to be destroyed (including as part of replacement)operation
: one ofplan
,apply
, ordestroy
Example
Outputs
After a successful plan or apply, a message with type outputs
contains the values of all root module output values. This message contains an outputs
object, the keys of which are the output names. The outputs values are objects with the following keys:
action
: for planned outputs, the action which will be taken for the output. Values:noop
,create
,update
,delete
value
: for applied outputs, the value of the output, encoded in JSONtype
: for applied outputs, the detected HCL type of the output valuesensitive
: boolean value,true
if the output is sensitive and should be hidden from UI by default
Note that sensitive
outputs still include the value
field, and integrating software should respect the sensitivity value as appropriate for the given use case.
Example
Operation Messages
Performing Terraform operations to a resource will often result in several messages being emitted. The message types include:
apply_start
: when starting to apply changes for a resourceapply_progress
: periodically, showing elapsed time outputapply_complete
: on successful operation completionapply_errored
: when an error is encountered during the operationprovision_start
: when starting a provisioner stepprovision_progress
: on provisioner outputprovision_complete
: on successful provisioningprovision_errored
: when an error is enountered during provisioningrefresh_start
: when reading a resource during refreshrefresh_complete
: on successful refresh
Each of these messages has a hook
object, which has different fields for each type. All hooks have a resource
object which identifies which resource is the subject of the operation.
Apply Start
The apply_start
message hook
object has the following keys:
resource
: aresource
object identifying the resourceaction
: the action to be taken for the resource. Values:noop
,create
,read
,update
,replace
,delete
id_key
andid_value
: a key/value pair used to identify this instance of the resource, omitted when unknown
Example
Apply Progress
The apply_progress
message hook
object has the following keys:
resource
: aresource
object identifying the resourceaction
: the action being taken for the resource. Values:noop
,create
,read
,update
,replace
,delete
elapsed_seconds
: time elapsed since the apply operation started, expressed as an integer number of seconds
Example
Apply Complete
The apply_complete
message hook
object has the following keys:
resource
: aresource
object identifying the resourceaction
: the action taken for the resource. Values:noop
,create
,read
,update
,replace
,delete
id_key
andid_value
: a key/value pair used to identify this instance of the resource, omitted when unknownelapsed_seconds
: time elapsed since the apply operation started, expressed as an integer number of seconds
Example
Apply Errored
The apply_complete
message hook
object has the following keys:
resource
: aresource
object identifying the resourceaction
: the action taken for the resource. Values:noop
,create
,read
,update
,replace
,delete
elapsed_seconds
: time elapsed since the apply operation started, expressed as an integer number of seconds
The exact detail of the error will be rendered as a separate diagnostic
message.
Example
Provision Start
The provision_start
message hook
object has the following keys:
resource
: aresource
object identifying the resourceprovisioner
: the type of provisioner
Example
Provision Progress
The provision_progress
message hook
object has the following keys:
resource
: aresource
object identifying the resourceprovisioner
: the type of provisioneroutput
: the output log from the provisioner
One provision_progress
message is output for each log line received from the provisioner.
Example
Provision Complete
The provision_complete
message hook
object has the following keys:
resource
: aresource
object identifying the resourceprovisioner
: the type of provisioner
Example
Provision Errored
The provision_errored
message hook
object has the following keys:
resource
: aresource
object identifying the resourceprovisioner
: the type of provisioner
Example
Refresh Start
The refresh_start
message hook
object has the following keys:
resource
: aresource
object identifying the resourceid_key
andid_value
: a key/value pair used to identify this instance of the resource
Example
Refresh Complete
The refresh_complete
message hook
object has the following keys:
resource
: aresource
object identifying the resourceid_key
andid_value
: a key/value pair used to identify this instance of the resource
Example
Resource Object
The resource
object is a decomposed structure representing a resource address in configuration, which is used to identify which resource a given message is associated with. The object has the following keys:
addr
: the full unique address of the resource as a stringmodule
: the address of the module containing the resource, in the formmodule.foo.module.bar
, or an empty string for a root module resourceresource
: the module-relative address, which is identical toaddr
for root module resourcesresource_type
: the type of resource being addressedresource_name
: the name label for the resourceresource_key
: the address key (count
orfor_each
value), ornull
if the neither are usedimplied_provider
: the provider type implied by the resource type; this may not reflect the resource's provider if provider aliases are used
Example
Test Abstract
The terraform test
command emits a test_abstract
message describing the test files and run
blocks that Terraform executes during the upcoming operation.
Example
Test File
After Terraform completes execution of each test file, terraform test
emits a test_file
message with the status of the test file.
Example
Test Run
After Terraform completes execution of each test file, terraform test
emits a series of test_run
messages with each run block's status within the test file.
Example
Test Cleanup
After Terraform completes the execution of each test file, terraform test
may emit a series of test_cleanup
messages detailing any state it could not destroy. You must locate and destroy the resources listed in these resources manually.
As the test framework can manage multiple state files for each test file, you can see multiple versions of this message for each state file that holds resources that Terraform could not destroy. Using the @testrun
field, you can pinpoint the run block that last updated the state file to locate the resources that Terraform could not destroy.
Example
Test Summary
After the test operation has completed all test files, terraform test
emits a test_summary
message with the status of the overall test operation.
Example
Test Plan
In -verbose
mode, terraform test
emits a test_plan
message for all run
blocks that executed a plan operation. The test_plan
message contains a subset of the attributes from the terraform show -json <planfile>
command output and the terraform providers schema -json
command output.
The message contains the following fields representing the plan: plan_format_version
, output_changes
, resource_changes
, resource_drift
and relevant_attributes
. These match the respective fields in the JSON Plan Representation.
The message contains the following fields representing the provider schemas: provider_format_version
and provider_schemas
. These match the respective fields in the JSON Providers Schema Representation.
Example
Test State
In -verbose
mode, terraform test
emits a test_state
message for all run
blocks that executed an apply operation. The test_state
message contains a subset of the terraform show -json
command output and the terraform providers schema -json
command output.
The message contains the following fields representing the state: state_format_version
, root_module
, and outputs
. These match the respective fields in the JSON Values Representation that are embedded in complete JSON state representation.
The message contains the following fields representing the provider schemas: provider_format_version
and provider_schemas
. These match the respective fields in the JSON Providers Schema Representation.
Example
Test Interrupt
When terraform test
is impeded or canceled, it emits a test_interrupt
message that describes the interrupted operation. This message includes any state that Terraform could not destroy before exiting and any leftover resources that Terraform did not finish creating.
As with the Test Cleanup message, Terraform might have been maintaining multiple state files. The state
field contains the resources from the main state for the test configuration, while the states
field contains a map of run
block names to the resources that each run
block created, which Terraform could not destroy.
Finally, the planned
field contains any resources that were in the process of being created by the interrupted run
block, which you can identify using the @testrun
field.
Example