Notifications

HCP Terraform can use webhooks to notify external systems about run progress and other events. Each workspace has its own notification settings and can notify up to 20 destinations.

Configuring notifications requires admin access to the workspace. Refer to Permissions for details.

Viewing and Managing Notification Settings

To add, edit, or delete notifications for a workspace, go to the workspace and click Settings > Notifications. The Notifications page appears, showing existing notification configurations.

Creating a Notification Configuration

A notification configuration specifies a destination URL, a payload type, and the events that should generate a notification. To create a notification configuration:

1. Click Settings > Notifications. The Notifications page appears.

2. Click Create a Notification. The Create a Notification form appears.

3. Configure the notifications:

• Destination: HCP Terraform can deliver either a generic payload or a payload formatted specifically for Slack, Microsoft Teams, or Email. Refer to Notification Payloads for details.

• Name: A display name for this notification configuration.

• Webhook URL This URL is only available for generic, Slack, and Microsoft Teams webhooks. The webhook URL is the destination for the webhook payload. This URL must accept HTTP or HTTPS POST requests and should be able to use the chosen payload type. For details, refer to Slack's documentation on creating an incoming webhook and Microsoft's documentation on creating a workflow from a channel in teams.

• Token (Optional) This notification is only available for generic webhooks. A token is an arbitrary secret string that HCP Terraform will use to sign its notification webhooks. Refer to Notification Authenticity for details. You cannot view the token after you save the notification configuration.

• Email Recipients This notification is only available for emails. Select users that should receive notifications.

• Workspace Events: HCP Terraform can send notifications for all events or only for specific events. The following events are available:

  • Drift: HCP Terraform detected configuration drift. This notification is only available if you enable health assessments for the workspace.
  • Check Failure: HCP Terraform detected one or more failed continuous validation checks. This notification is only available if you enable health assessments for the workspace.
  • Health Assessment Fail: A health assessment failed. This notification is only available if you enable health assessments for the workspace. Health assessments fail when HCP Terraform cannot perform drift detection, continuous validation, or both. The notification does not specify the cause of the failure, but you can use the Assessment Result logs to help diagnose the issue.
  • Auto destroy reminder: Sends reminders 12 and 24 hours before a scheduled auto destroy run.
  • Auto destroy results: HCP Terraform performed an auto destroy run in the workspace. Reports both successful and errored runs.

• Run Events: HCP Terraform can send notifications for all events or only for specific events. The following events are available:
  • Created: A run begins and enters the Pending stage.
  • Planning: A run acquires the lock and starts to execute.
  • Needs Attention: A plan has changes and Terraform requires user input to continue. This event may include approving the plan or a policy override.
  • Applying: A run enters the Apply stage, where Terraform makes the infrastructure changes described in the plan.
  • Completed: A run completed successfully.
  • Errored: A run terminated early due to error or cancellation.

1. Click Create a notification.

Enabling and Verifying a Configuration

To enable or disable a configuration, toggle the Enabled/Disabled switch on its detail page. HCP Terraform will attempt to verify the configuration for generic and slack webhooks by sending a test message, and will enable the notification configuration if the test succeeds.

For a verification to be successful, the destination must respond with a 2xx HTTP code. If verification fails, HCP Terraform displays the error message and the configuration will remain disabled.

For both successful and unsuccessful verifications, click the Last Response box to view more information about the verification results. You can also send additional test messages with the Send a Test link.

Notification Payloads

Slack

Notifications to Slack will contain the following information:

• The run's workspace (as a link)
• The HCP Terraform username and avatar of the person that created the run
• The run ID (as a link)
• The reason the run was queued (usually a commit message or a custom message)
• The time the run was created
• The event that triggered the notification and the time that event occurred

Microsoft Teams

Notifications to Microsoft Teams contain the following information:

• The run's workspace (as a link)
• The HCP Terraform username and avatar of the person that created the run
• The run ID
• A link to view the run
• The reason the run was queued (usually a commit message or a custom message)
• The time the run was created
• The event that triggered the notification and the time that event occurred

Email

Email notifications will contain the following information:

• The run's workspace (as a link)
• The run ID (as a link)
• The event that triggered the notification, and if the run needs to be acted upon or not

Generic

A generic notification will contain information about a run and its state at the time the triggering event occurred. The complete generic notification payload is described in the API documentation.

Some of the values in the payload can be used to retrieve additional information through the API, such as:

• The run ID
• The workspace ID
• The organization name

Notification Authenticity

Slack notifications use Slack's own protocols for verifying HCP Terraform's webhook requests.

Generic notifications can include a signature for verifying the request. For notification configurations that include a secret token, HCP Terraform's webhook requests will include an X-TFE-Notification-Signature header, which contains an HMAC signature computed from the token using the SHA-512 digest algorithm. The receiving service is responsible for validating the signature. More information, as well as an example of how to validate the signature, can be found in the API documentation.