> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploys

> Tell Ordyn when a change reaches production. Ordyn creates the monitors and confirms the deploy is healthy.

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.

| Option | Use it when |
| - | - |
| **GitHub Deployments** | Your pipeline already creates GitHub Deployment records, for example a GitHub Actions job with `environment:` set. |
| **GitHub Workflow** | You deploy from a GitHub Actions workflow that does not create Deployment records. You pick the workflow whose success means "deployed". |
| **Other Webhook** | Your deploy finishes outside a single workflow run, for example through ArgoCD or Helm, several services ship from one repository, or your pipeline is not GitHub Actions. Your deploy step reports to Ordyn with a deployment key, using our GitHub Action or one HTTP request. |

## GitHub Deployments

In GitHub Actions, set the deploy job's `environment:`:

```yaml theme={null}
jobs:
  deploy:
    environment: production
```

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](https://github.com/struct-dot-ai/notify-deploy) after the step that finishes your rollout:

```yaml theme={null}
- uses: struct-dot-ai/notify-deploy@v1
  with:
    api-key: ${{ secrets.STRUCT_DEPLOY_KEY }}
    environment: production
```

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:`:

```yaml theme={null}
    idempotency-key: api-production-${{ github.sha }}-${{ github.run_id }}-${{ github.run_attempt }}
```

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:

```bash theme={null}
curl -X POST "https://api.ordyn.dev/api/deployments/" \
  -H "Authorization: Bearer sk-..." \
  -H "Content-Type: application/json" \
  -d '{
    "repository": "acme/api",
    "sha": "abc1234deadbeef",
    "environment": "production",
    "status": "success",
    "idempotencyKey": "production-abc1234"
  }'
```

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](/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.

> [!WARNING]
>
> For GitHub Deployments and Other Webhook, the environment name must match your Auto Monitors setting exactly, including case.

## What happens on deploy

1. 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.
2. Ordyn waits for real production telemetry, up to about an hour, and sets thresholds from it.
3. Ordyn creates the monitors in your providers and updates each PR review to show what is now being watched.
4. 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.