Ordyn creates monitors and verifies deploys when a change reaches the environment you configured as production. There are three ways to tell Ordyn that happened. Pick one in Auto Monitors setup.
GitHub Deployments
In GitHub Actions, set the deploy job’s environment::
The Ordyn GitHub App needs the Deployments: Read-only permission and the Deployment statuses webhook. Existing installations are asked to approve this once. Jobs without an environment: do not create deployment records, so use GitHub Workflow for those.
GitHub Workflow
Choose GitHub Workflow, name the environment, and pick the deploy workflow from the list of your repository’s Actions workflows. A successful run of that workflow counts as a deploy of the run’s commit.
Ordyn creates the repository webhook for you if the GitHub App has the Repository webhooks: write permission. If it cannot, the form shows a payload URL and secret to add yourself under the repository’s Settings → Webhooks, subscribed to Workflow runs only. Then click Continue or Save again.
Because a workflow run does not name an environment, one workflow maps to one environment. If a single workflow deploys to several environments by input, use Other Webhook instead.
Other Webhook
Create a deployment key in Settings → Deployment Keys (admins only). The key is shown once. Then report each deploy once it has landed.
From GitHub Actions, add the notify-deploy action after the step that finishes your rollout:
By default the action reports the workflow run’s commit (github.sha) and repository, and builds an idempotency key from the run. Pass sha: yourself when the run was not started by the deployed commit, for example with repository_dispatch, workflow_run, or a schedule, where github.sha is the tip of the default branch. Pass repository: when the deploy runs from a different repository than the code, such as a separate GitOps repository. It runs on Linux and macOS runners with bash, curl, and standard Unix tools such as grep and sed, and it never fails your deploy if Ordyn is unreachable. The action’s README lists every input, including how to report failed deploys.
If one run deploys several services from the same commit, give each deploy its own idempotency-key built from the service name, the environment, the commit, and the run. Use the same environment value you pass to environment::
Ordyn records one deploy per key, and a retry with the same key is not recorded twice. A fixed key such as api would record only the service’s first deploy, and a key without the environment would record a canary deploy but drop the production deploy that follows it in the same run.
From any other tool, post to the API:
Post when the SHA has reached, or failed to reach, the environment. Canary then production is two posts with the same SHA and two environment names. Full field reference: Deployments API.
Do not point a GitHub webhook at this endpoint. GitHub cannot send the authorization header it needs. Use GitHub Workflow for that case.
For GitHub Deployments and Other Webhook, the environment name must match your Auto Monitors setting exactly, including case.
What happens on deploy
- Ordyn works out which pull requests are in the deploy and combines the monitors it expected across all of them. One monitor can cover several PRs.
- Ordyn waits for real production telemetry, up to about an hour, and sets thresholds from it.
- Ordyn creates the monitors in your providers and updates each PR review to show what is now being watched.
- Ordyn checks the deploy itself against your telemetry, recent pull requests, and code. Confirmed regressions are traced back to the PR that caused them and posted to Slack.
The Deploys tab
Detect → Deploys lists every deploy Ordyn verified. Filter to Regressions to see deploys that introduced a problem, or Clean for deploys that came through healthy. Each row shows the pull requests in the deploy and the monitors written or re-verified by it. 