Release Metrics Snapshot in Hex on Every Deploy

Two days after a release, someone asks whether conversion dipped because of the deploy, and the answer depends on whether anyone remembered to capture the numbers at ship time. This blueprint removes the remembering: the CI pipeline calls a Kestra webhook when the deploy finishes, io.kestra.plugin.hex.projects.Run executes the metrics notebook with the release version passed through inputParams, waits for the snapshot to publish, and Slack posts the run link next to the version. Every release gets its baseline, produced by machinery.

How it works

1. deploy_done (io.kestra.plugin.core.trigger.Webhook) exposes a URL your CI job calls after a successful deploy, posting a JSON body that carries the version.
2. snapshot_metrics (io.kestra.plugin.hex.projects.Run) maps that version onto the notebook's release_version input parameter via {{ trigger.body.version ?? inputs.release_version }}, so manual executions fall back to the flow input.
3. wait: true blocks until the snapshot run reaches a terminal state, and the task exposes status, runUrl, and timing as outputs.
4. announce_snapshot posts the version and the run URL to Slack, putting the evidence in the same channel as the release thread.
5. The errors block warns the channel explicitly that this release has no metrics baseline yet, which is the failure mode worth being loud about.

What you get

• A metrics snapshot tied to every release version, without anyone remembering to run a notebook on deploy day.
• Before-and-after evidence for release retrospectives and incident timelines, linked from the release channel.
• A webhook contract with CI that is one curl call in a pipeline step.
• A manual fallback path, so rerunning the snapshot for a hotfix is one execution with one input.

Who it's for

• Product and growth teams who judge releases by metrics and need the baseline captured at ship time.
• Platform engineers wiring deploy pipelines to the analytics stack without writing glue services.
• Anyone who has reconstructed pre-release numbers from a dashboard's history because nobody snapshotted them.

Why orchestrate this with Kestra

CI systems can call APIs, but chaining an API call, a poll-until-complete wait, a parameterized notebook, and a notification into a deploy step turns pipelines into shell-script orchestrators. Kestra takes the single webhook call and owns the rest: the version flows from the request body into the notebook's parameters, the run is waited on and recorded, and both success and failure land in the channel where the release is being discussed.

Prerequisites

• A Hex project that exposes a release_version input parameter.
• A Hex API token with permission to run the project.
• A CI pipeline able to POST JSON to the webhook URL after deploys, and a Slack incoming webhook for announcements.

Secrets

• HEX_API_TOKEN: Hex API token used to run the project.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the HEX_API_TOKEN and SLACK_WEBHOOK_URL secrets to your Kestra namespace, and change the webhook key to a random value.
2. Set project_id to a notebook with a release_version parameter and execute the flow manually; Slack should link a snapshot for the fallback version.
3. Add a curl step to your CI deploy job that POSTs {"version": "<tag>"} to the webhook URL and ship a release.

How to extend

• Pass more context from CI through the body, such as the commit SHA or environment, and map each onto a notebook parameter.
• Post the announcement into a per-release channel by deriving the webhook body into the Slack payload.
• Chain a warehouse load before the snapshot when release metrics depend on freshly ingested events.
• Pair this with the run completion reactor blueprint so downstream consumers also react when the snapshot publishes.

Links

• Hex plugin documentation
• Hex documentation