Deployments

What a deployment event is

A deployment belongs to a team. It names a service and a version, the environment it went to (production when you send none), when it started and finished, and its status. A pipeline sends one request when the deploy starts and one when it ends, with the same external_id, and the second updates the first.

The console shows them in the team’s Deployments tab and on the dashboard, and the AI insights read them next to the alerts.

Recording from a pipeline

Record with the team’s integration key, the same kind of key that sends alerts. Give each pipeline a key of its own, created for the team and kept as a repository or environment secret, so one can be revoked without stopping the others. A key records only its own team’s deployments.

printf 'Authorization: %s\n' "$IGNITEOPS_KEY" | curl --fail-with-body --retry 3 --retry-delay 5 \
  -X POST "https://api.igniteops.io/v1/organizations/{org}/incident-management/{team}/deployments" \
  -H @- \
  -H "Content-Type: application/json" \
  -d '{ "service": "checkout-api", "version": "2.14.0", "status": "succeeded", "external_id": "9123456789-1-checkout-api" }'

curl reads the Authorization: ign_… line from its standard input, so the key never appears on a command line or in a file. In GitHub Actions, record the start before the deploy step and the end only when the deploy ran, with its outcome:

# .github/workflows/deploy.yml
- name: Record the deployment start
  continue-on-error: true
  env:
    IGNITEOPS_KEY: ${{ secrets.IGNITEOPS_INTEGRATION_KEY }}
    VERSION: ${{ github.sha }}
    EXTERNAL_ID: ${{ github.run_id }}-${{ github.run_attempt }}-checkout-api
    RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
  run: |
    jq -n --arg version "$VERSION" --arg external_id "$EXTERNAL_ID" --arg url "$RUN_URL" \
      '{service: "checkout-api", version: $version, status: "started", external_id: $external_id, url: $url}' > "$RUNNER_TEMP/deployment-body"
    printf 'Authorization: %s\n' "$IGNITEOPS_KEY" | curl -sS --fail-with-body --retry 3 --retry-delay 5 \
      -X POST "https://api.igniteops.io/v1/organizations/acme/incident-management/platform/deployments" \
      -H @- -H "Content-Type: application/json" --data @"$RUNNER_TEMP/deployment-body" \
      || { echo; echo "::warning::The deployment start was not recorded in IgniteOps"; }

- name: Deploy
  id: deploy
  run: make deploy

- name: Record the deployment end
  if: always() && (steps.deploy.outcome == 'success' || steps.deploy.outcome == 'failure')
  continue-on-error: true
  env:
    IGNITEOPS_KEY: ${{ secrets.IGNITEOPS_INTEGRATION_KEY }}
    VERSION: ${{ github.sha }}
    STATUS: ${{ steps.deploy.outcome == 'success' && 'succeeded' || 'failed' }}
    EXTERNAL_ID: ${{ github.run_id }}-${{ github.run_attempt }}-checkout-api
  run: |
    jq -n --arg version "$VERSION" --arg status "$STATUS" --arg external_id "$EXTERNAL_ID" \
      '{service: "checkout-api", version: $version, status: $status, external_id: $external_id}' > "$RUNNER_TEMP/deployment-body"
    printf 'Authorization: %s\n' "$IGNITEOPS_KEY" | curl -sS --fail-with-body --retry 3 --retry-delay 5 \
      -X POST "https://api.igniteops.io/v1/organizations/acme/incident-management/platform/deployments" \
      -H @- -H "Content-Type: application/json" --data @"$RUNNER_TEMP/deployment-body" \
      || { echo; echo "::warning::The deployment end was not recorded in IgniteOps"; }

• One external_id per attempt and per service. A re-run of a job is a new attempt, and a job that deploys several services records each under its own id. The same id again updates the recorded deployment and answers 200; a new one answers 201.
• Resending is safe with an external_id. Only a timeout, a 408, a 429 or a 5xx is worth retrying, and the retry lands on the same deployment. Without an external_id every request records a new one, so a retry can record it twice.
• A refusal never fails the deploy. The steps continue on error and leave a warning: a plan limit, a renamed team or a field the API refuses should not stop a release.
• A run cancelled or failed before the deploy records nothing, and a run cancelled during it stays started (it reads unknown after 24 hours).

The fields

A later request for the same deployment keeps its environment and kind unless it sends them.

Statuses and transitions

A status only moves forward: started to succeeded, failed or rolled_back, and succeeded to rolled_back. A move backwards is refused with 409 invalid_transition.

The team list and the organization timeline

Every member of the organization can read deployments. A team’s list answers its deployments, and the organization timeline answers every team’s, both newest first:

GET …/incident-management/{team}/deployments?environment=production&status=failed&from=2026-11-01T00:00:00Z
GET /v1/organizations/{org}/deployments?service=checkout-api&limit=100

• Filters: service, environment, status (unknown included), and from / to on the start (RFC 3339).
• Pages: limit from 1 to 100 (50 by default), then the answer’s next_token. With filters a page can hold fewer deployments, or none, while has_more is true: follow next_token until it is null.
• Deployments are kept for 400 days.

In the console the team’s Deployments tab has the same filters, and the dashboard shows the organization’s last 7 days, the failed and rolled back ones marked.

Who can record, change and delete

How the insights use deployments

On Pro, the AI insights read the deployments next to the alerts:

• Alerts after a deployment. When a team gets unusually many alerts in the hour after a deployment starts (at least 3, and at least twice its usual hourly rate over the week before), or its first P1 of that week, the insight names the deployment. The hour ends early at the next deployment of the same team and environment, whose alerts are its own.
• Change failure rate. Once a team has 10 deployments that ended in the last 30 days, the share that failed or was rolled back is reported from 15%, and as a warning from 30%. A deployment still started does not count.
• The weekly review includes the week’s changes and the change failure rate.

The insights read the service, version, environment, status and times, never the description, the link or the tags.

Limits

Past the Free plan’s daily cap a new deployment is refused with 402 plan_limit_reached and the key deployments_per_day; the pipeline step above leaves a warning and the deploy goes on. See plans and limits.