Deployment Tracking

What you’ll get: ewake correlates production issues with deployment events in real time. When an alert fires, it automatically checks whether a recent deployment on the affected service could be the cause.

How it works

Deployment tracking is a single authenticated HTTPS request. Each time you deploy to production, your pipeline sends one POST to the ewake API. Ewake stores these events in your environment’s knowledge map and uses them as context during alert investigations. There is nothing to install and no dependency on a particular git host or CI vendor. Any tool that can make an HTTP request can report deployments. The ewake GitHub Action is a thin convenience wrapper around exactly the same request, so if you’re not on GitHub Actions, send the request directly.

The artifactName field must match the service name as it appears in your observability stack (Datadog, Grafana, etc.) for correlation to work.

Prerequisites

You need an ewake API key to authenticate deployment events. In your ewake dashboard, open API Keys in the sidebar and create a key. Copy it immediately, it’s shown once and starts with ew_. Store it in whatever secret store your pipeline already uses, exposed to the build as EWAKE_API_KEY.

An ewake API key is not scoped to a single purpose. Keys carry a name for your own bookkeeping, nothing more. The same key that posts deployment events also authenticates against the MCP server, which can read your service map and past investigations. Treat it as a full workspace credential: never commit it, never paste it inline in a pipeline definition, and revoke it from API Keys the moment it might have leaked.

The request

curl -X POST https://api.ewake.ai/api/v1/events/deployment \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "timestamp": "2026-04-14T12:00:00Z",
    "repository": "my-org/my-service",
    "repositoryUrl": "https://github.com/my-org/my-service",
    "artifactName": "my-service",
    "commitSha": "abc1234",
    "version": "1.2.3",
    "message": "Deployed by CI",
    "source": "ci",
    "labels": {"env": "production"}
  }'

A 202 Accepted response confirms the event was received. The body carries a traceId you can quote to support.

Field	Required	Description
`timestamp`	✅	ISO 8601 datetime, e.g. `2026-04-14T12:00:00Z`
`repository`	✅	Repository identifier, `owner/name`
`repositoryUrl`	✅	Full repository URL, e.g. `https://github.com/my-org/my-service`
`artifactName`	✅	Must match the service name in your observability stack
`commitSha`	✅	Deployed commit SHA, 7 to 40 characters (short or full)
`version`	—	Semver, image tag, or short SHA
`url`	—	Link back to the deploy, e.g. the CI run
`message`	—	Free-text deployment description
`source`	—	Deployment source identifier (e.g. `ci`, `github-actions`)
`labels`	—	Flat JSON object of string keys and string values

All five required fields must be present. A request missing any of them is rejected with 400 Bad Request and a message naming the field, it is not accepted-and-ignored.

https://api.ewake.ai is the hosted ingestion endpoint. Self-hosted ewake instances use the same path on your own host, for example https://ewake.your-domain.com/api/v1/events/deployment.

Add it to your pipeline

GitHub Actions
Any other tool

The ewake GitHub Action is available on the GitHub Marketplace. Add ~5 lines to any existing workflow, no changes to your deployment logic required.

- name: Report deployment to ewake
  uses: ewake-ai/report-deployment-action@v1
  with:
    api-key: ${{ secrets.EWAKE_API_KEY }}
    artifact-name: "my-service"
    version: ${{ github.sha }}
    message: "Deploy ${{ github.ref_name }} to production"
    # labels: '{"env": "production"}'          # optional: custom metadata
    # api-url: "https://your-ewake-instance"   # optional: self-hosted override

Parameter	Required	Description
`api-key`	✅	Your ewake API key
`artifact-name`	✅	Must match the service name in your observability stack
`version`	—	Semver, image tag, or short SHA
`message`	—	Free-text deployment description
`labels`	—	JSON object with custom metadata
`api-url`	—	Override for self-hosted ewake instances. Defaults to `https://api.ewake.ai`

The action fills in timestamp, repository, repositoryUrl, commitSha, source and the run url from the workflow’s own GitHub context, so there are no inputs for them.

Non-blocking by design, the action always exits 0. If ewake is unreachable it logs a warning and your deployment continues unaffected.

Drop this script into your repository and call it at the end of any deploy, from any CI/CD system or deploy script.

report-deployment.sh

#!/usr/bin/env sh
set -eu

ARTIFACT_NAME="my-service"
REPOSITORY="my-org/my-service"
REPOSITORY_URL="https://github.com/my-org/my-service"
COMMIT_SHA="$(git rev-parse HEAD)"
VERSION="$(git rev-parse --short HEAD)"
TIMESTAMP="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

curl -sS --max-time 10 -X POST "${EWAKE_API_URL:-https://api.ewake.ai}/api/v1/events/deployment" \
  -H "Authorization: Bearer ${EWAKE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{
    \"timestamp\": \"${TIMESTAMP}\",
    \"repository\": \"${REPOSITORY}\",
    \"repositoryUrl\": \"${REPOSITORY_URL}\",
    \"artifactName\": \"${ARTIFACT_NAME}\",
    \"commitSha\": \"${COMMIT_SHA}\",
    \"version\": \"${VERSION}\",
    \"message\": \"Deployed by ${USER:-ci}\",
    \"source\": \"ci\",
    \"labels\": {\"env\": \"production\"}
  }" || echo "ewake deployment report failed, continuing"

Set EWAKE_API_KEY in the environment, and EWAKE_API_URL too if you run a self-hosted ewake instance. The trailing || echo keeps a failed report from failing your deploy.Most CI systems expose the commit SHA, repository and branch as built-in variables, use those instead of the git rev-parse calls if the deploy runs without a checkout.

Report the deployment after the deploy succeeds, not before. An event sent from a pipeline that later fails will make ewake correlate incidents against a release that never reached production.

Verify the connection

Send a one-off event from your terminal before wiring up the pipeline. All five required fields have to be there, so this is a complete event rather than a bare ping:

curl -i -X POST https://api.ewake.ai/api/v1/events/deployment \
  -H "Authorization: Bearer $EWAKE_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
    \"repository\": \"my-org/my-service\",
    \"repositoryUrl\": \"https://github.com/my-org/my-service\",
    \"artifactName\": \"my-service\",
    \"commitSha\": \"$(git rev-parse HEAD)\",
    \"message\": \"Connectivity test\",
    \"source\": \"manual\"
  }"

A 202 Accepted means the key is valid and the event was stored. The deployment then shows up against my-service on the Releases page in your ewake dashboard.

Troubleshooting

Error	Cause
`401 Unauthorized`	Invalid or missing API key, or the secret is not exposed to the pipeline step
`400 Bad Request`	A required field is missing or malformed. The response names the field, most often `repositoryUrl` (it must be a full URL, not `owner/name`), `commitSha` (7–40 characters), or `timestamp` (must be ISO 8601)
Empty or truncated fields	Shell quoting, run the command locally with `echo` first to check the JSON your pipeline actually builds
Event accepted but no correlation	`artifactName` doesn’t match the service name in your observability stack
Timeout	Check proxy or firewall settings for outbound HTTPS from your runners

Self-hosted runners on a private network need outbound HTTPS to api.ewake.ai (or to your self-hosted ewake instance). This is the most common cause of events never arriving.

Connect GitHub →

Let ewake read pull requests and diffs alongside your deployment events.

Connect GitLab →

Let ewake read merge requests and diffs alongside your deployment events.

Introduction

Get Started

Integrations

Working With Ewake

Interfaces

Trust & Security

Resources

FAQ

How it works

Prerequisites

The request

Add it to your pipeline

Verify the connection

Troubleshooting

Connect GitHub →

Connect GitLab →

​How it works

​Prerequisites

​The request

​Add it to your pipeline

​Verify the connection

​Troubleshooting

Connect GitHub →

Connect GitLab →

How it works

Prerequisites

The request

Add it to your pipeline

Verify the connection

Troubleshooting