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. Flashduty creates it when the run waits for confirmation and updates it 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.

How changes are merged

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

Flashduty maps end events by run status: applied is Done, and errored is Failed. A canceled or discarded status would map to Canceled, but Scalr doesn’t 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 with run status planned_and_finished: a plan-only or no-change run that applied nothing
  • 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.
  • … is missing or invalid …: the payload is incomplete or a field is malformed. Confirm it comes from a Scalr webhook
  • unsupported … or unknown …: Flashduty does not support this event or run status yet. Contact us