Skip to main content
Plan requirement: This feature requires an On-call Standard or higher subscription. Learn more
Use Scalr webhooks to sync Terraform and OpenTofu runs to Flashduty On-call. Each run becomes one Flashduty change: the change is created when a run waits for a person to confirm it, and the same change is updated when the run applies or errors.

​
In Flashduty On-call

  1. In the Flashduty console, go to Integration Center → Change Events
  2. Select Scalr and enter an integration name
  3. To assign changes to specific channels, add rules under the integration’s Routes that match labels such as environment or workspace
  4. Click Save and copy the generated Push URL

​
Configure Scalr

A webhook is created at account scope and then assigned to environments; once assigned, runs of every workspace in that environment trigger it.
1

Create the webhook

At account scope, go to Integrations → Events Forwarding → Webhook and create a webhook (the Scalr API and the Terraform provider’s scalr_webhook resource also work):
  1. URL: paste the full push URL of the Flashduty integration
  2. Events: select run:completed, run:errored, and run:needs_attention
  3. Secret key: required. Click Generate or enter any string. Scalr uses it to sign requests; Flashduty authenticates with the integration_key in the push URL and does not verify the signature
2

Assign it to environments

A new webhook is created with Allow all current and future environments to have access to this webhook turned on, so no assignment is needed. To limit it, turn that switch off in the webhook’s Environments access tab and select the environments you want to connect.

​
What one change is

Scalr sends a delivery at only three moments: a run needs a person’s confirmation, a run finishes successfully, and a run errors. Canceling a run or discarding it at the confirmation step sends nothing, so such a run’s change stays Planned (or is never created). A change therefore has no Ready or Processing state; its first state is Planned (waiting for confirmation) or an end state. A run that applies automatically produces one record, when it ends.

​
Status mapping

End events are mapped by run status: applied is Done and errored is Failed (a canceled or discarded status in an end event would be Canceled, but Scalr does not send one). Done and Failed are end states, and Flashduty records the change’s end time. These deliveries return success and create no change: an end event whose run status is planned_and_finished (a plan-only or no-change run, nothing was applied), and any event outside the run: family.

​
Change content

Labels for routing and for filtering the change list: Run variables (variables) and user emails are not recorded.

​
FAQ

  • Confirm the webhook is enabled and assigned to the environment the run belongs to
  • Confirm run:completed, run:errored, and run:needs_attention are all selected
  • Open the webhook’s Deliveries tab to see each delivery and Flashduty’s response; you can also resend from there
  • A plan-only run (a dry run, nothing applied) that succeeds creates no change
Yes. Scalr’s payload does not tell a dry run from an apply run, so a run that errors during the plan is delivered as run:errored and Flashduty records a Failed change. The source label can help tell them apart, for example runs triggered by a VCS pull request.
No. An event with the same run, status, and time is recorded once, so resending from Deliveries adds nothing.
  • unsupported event-name or unsupported run.status: the delivery carries an event or run status Flashduty does not support yet; contact us
  • run.id is missing or event-name is missing: the payload is incomplete; confirm it comes from a Scalr webhook