Skip to main content
A deployment audit checks a SHA that reached an environment against your production telemetry, recent pull requests, and code. Struct posts the result in Slack. The same deploy event can also create Auto Monitors for that environment. You can notify Struct in two ways:
  1. GitHub Deployments — Struct listens for GitHub deployment_status events
  2. Webhook — your deploy script posts to Struct with a deployment key
Use GitHub Deployments when your pipeline already creates them (GitHub Actions environment:, or GitHub’s Deployment API). Use a webhook when it does not — for example a custom roll script, or canary then full in two named environments.
In the app: Monitors → Deployment audit to create an audit, or Auto Monitors to pick which environment counts as production.

​
GitHub Deployments

Struct needs the GitHub App installed on the repository, with:
  • Permission Deployments: Read-only
  • Webhook subscription Deployment statuses
Existing installations must approve the added Deployments permission. Your pipeline must create GitHub Deployment records for the environment you monitor. In GitHub Actions, set the job’s environment::
You can also create and update deployments through GitHub’s Deployment API. Jobs without an environment, and environments configured not to create deployment records, will not trigger Struct. workflow_run is not supported — finishing a workflow does not prove a SHA reached an environment. In Struct, create the monitor with GitHub Deployments and pick the environment from recent history. The environment name must match GitHub’s name exactly.

​
Webhook

If your pipeline does not create GitHub Deployments, create the monitor with Webhook and type the environment name your script will send. Create a deployment key in Settings → Deployment Keys (org admins), or from the Webhook option on the monitor form / Auto Monitors some other environment row. The secret is shown once. Do not put it in application code or commit it. Then POST when a SHA reaches that environment:
Ingest keys (pk-…) cannot call this endpoint. The GitHub App still needs access to the repository so audits can compare SHAs and open PRs. Canary then production is two POSTs: same SHA, two environment names, two idempotency keys.
Only terminal statuses are recorded. There is no in_progress / started event — post when the SHA has reached (or failed to reach) the environment.

​
Auto Monitors

Auto Monitors run when a change deploys to the environment you configured as production.
  • If that name is one GitHub already deploys to, GitHub deployment_status events are enough
  • If you choose some other environment, notify Struct with a deployment key as above
The name must match exactly either way.