Deployment correlation
Record deploys from GitHub, GitLab or any CI so SutramX can show which deploys happened just before an incident started.
Deployment correlation answers the first question in most outages: what shipped just before this broke? You send SutramX your deploys through a signed webhook from GitHub, GitLab or any CI, or with an API call. Every incident then lists the deploys that landed around the time it started.
On Netlify or Render you can also connect the platform instead.
Availability#
Recording deploys and showing them on incidents needs a plan with deployment correlation (Growth and Pro). On other plans:
- The Deploy events tab shows an upgrade notice.
- The signed webhook and the API reject deploys with a "not available on your plan" error.
See Plans & limits.
How deploys appear on incidents#
Open any incident. If deploys were recorded nearby, the Possible related — heuristic (time overlap) panel lists them under Deploys around this time. Each entry shows the service name, environment, source, version, deploy time, a heuristic score and the reason it was matched. For example: "Service name matches the monitor; deployed 6 min before the incident started".
How matching works:
- SutramX considers deploys from 2 hours before to 10 minutes after the incident started.
- A deploy closer to the incident start scores higher. The time score falls from 1 at the incident start to 0 at 2 hours away.
- A deploy whose
service_nameexactly matches the monitor's name (ignoring case and surrounding spaces) gets a large boost. - Only deploys scoring 0.5 or higher are shown, up to 5 per incident, highest first.
In practice, a deploy for a matching service shows up if it landed within about 96 minutes before the incident. A deploy for any other service shows up only if it landed within about 20 minutes.
Send deploys from GitHub, GitLab or CI#
Go to Alerts → Channels & API and open the Deploy events tab. It shows your workspace's Endpoint URL and whether a signing secret exists.
1. Generate a secret#
Click Generate secret and copy the secret, which starts with dhsec_. It is shown only once. Until a secret exists, the endpoint rejects every delivery.
Rotate secret creates a new one. The old secret stops working immediately, so update GitHub, GitLab and your CI right away. Only the workspace owner can generate or rotate the secret.
2a. GitHub#
- In your repository, open Settings → Webhooks → Add webhook.
- Payload URL: your endpoint URL.
- Content type:
application/json. - Secret: your deploy secret.
- Events: choose Let me select individual events, then Deployments and Deployment statuses.
SutramX verifies the X-Hub-Signature-256 header. It records deployment events and deployment_status events with state success, and ignores other states and ping. The service name comes from the repository name, the environment from the deployment (default production), and the version from the commit SHA or ref.
2b. GitLab#
- In your project, open Settings → Webhooks → Add new webhook.
- URL: your endpoint URL.
- Secret token: your deploy secret.
- Trigger: Deployment events.
SutramX checks the X-Gitlab-Token header and records deployments with status success. The service name comes from the project name and the version from the commit.
2c. Any CI (signed JSON)#
Send a JSON body signed with HMAC-SHA256 over {timestamp}.{body}:
ENDPOINT='https://…/incidents/deploy-events/hook/<your-hook-id>'
SECRET='dhsec_…'
body='{"service_name":"checkout-api","environment":"production","version":"v1.2.3"}'
ts=$(date +%s)
sig=$(printf '%s.%s' "$ts" "$body" | openssl dgst -sha256 -hmac "$SECRET" | sed 's/^.* //')
curl -X POST "$ENDPOINT" \
-H 'Content-Type: application/json' \
-H "X-SutramX-Timestamp: $ts" \
-H "X-SutramX-Signature: sha256=$sig" \
-d "$body"| Field | What it does | Default / limits |
|---|---|---|
service_name | The service you deployed. Match it to a monitor name for stronger correlation | Required, up to 255 characters |
environment | Environment label shown on the incident | production, up to 64 characters |
version | Version, tag or commit | Optional, up to 120 characters |
deployed_at | When the deploy happened (ISO 8601) | Time of receipt |
| Header | Value |
|---|---|
X-SutramX-Timestamp | Current Unix time in seconds |
X-SutramX-Signature | sha256= + hex HMAC-SHA256 of {timestamp}.{raw body} with your secret |
Rules:
- The timestamp must be within 5 minutes of SutramX's clock, so a captured request can't be replayed later.
- Sign the exact bytes you send. Re-serialising the JSON after signing breaks the signature.
- The same signed delivery is recorded only once. Retries of an identical request are ignored.
- Bodies must be JSON, up to 100 KB.
Record a deploy with an API key#
From a script that already has a SutramX API key, you can skip signing and call the authenticated endpoint:
curl -X POST "https://api.sutramx.com/incidents/deploy-events" \
-H "Authorization: Bearer $SUTRAMX_API_KEY" \
-H "Content-Type: application/json" \
-d '{"service_name":"checkout-api","environment":"production","version":"v1.2.3","deployed_at":"2026-10-02T09:30:00Z"}'This endpoint accepts manual deploys only. GitHub and GitLab payloads must go to the signed webhook. See REST API for API keys.
Check what was recorded#
The Recent deploys list on the Deploy events tab shows the latest deploys with service, version, environment, source (github, gitlab or manual) and time. Click Refresh to reload it. Via the API, use GET /incidents/deploy-events?limit=20 (up to 100).
Deploy platforms#
Go to Alerts → Channels & API, open the Deploy events tab and click Connect your deploy platform. The Deploy platforms page (https://app.sutramx.com/dashboard/integrations-deploy) has a card for each platform:
- Render: paste a Render API key (from Render's Account settings → API keys), choose the Render workspace if you have more than one, and click Connect Render. The key is stored encrypted.
- Netlify: click Connect Netlify and approve access in Netlify. If the card says "Not available yet.", send deploys from your CI with the signed webhook instead.
A connection:
- Creates an HTTP uptime monitor for each project, site or service that has a public URL, within your plan's monitor limit. A monitor that already exists for the same URL is linked instead of duplicated.
- Records successful production deploys as deploy events. Preview and branch deploys are ignored.
- Is managed by the workspace owner. Disconnecting keeps the monitors it created.
Webhook responses#
| Response | Meaning |
|---|---|
201 | Recorded |
202 | Acknowledged and ignored (for example a GitHub ping, a failed deployment status or a duplicate delivery) |
401 Deploy hook has no signing secret | Generate a secret first |
401 Invalid, expired or missing signature | Wrong secret, a body changed after signing, or a timestamp more than 5 minutes off |
400 Body must be JSON | Send Content-Type: application/json with a JSON body |
403 | Your plan doesn't include deployment correlation |
404 Unknown deploy hook | The URL is wrong. Copy it again from the Deploy events tab |
429 | Too many requests. The webhook allows 120 deliveries per hour per IP address |
Common questions#
My deploys are recorded but never show on incidents. The deploy must fall between 2 hours before and 10 minutes after the incident start and score at least 0.5. Without a service-name match, only deploys within about 20 minutes qualify. Rename the monitor or the service_name so they match exactly.
Do staging deploys count? Every deploy you send is recorded and can be matched. environment is a label shown on the incident and doesn't filter anything, so send only the deploys you want correlated.
Can I silence alerts during a deploy? Yes, with a deployment window. See Escalation & on-call and Maintenance windows.
Related
- Incidents
- Reliability insights
- GitHub, OTel & more
- REST API
- Features: Reliability Insights
- Guides: MTTR, MTTD, MTTA & MTBF Explained
- Integrations: GitHub issues alerts setup
- More from SutramX: Developers & API
Last updated . Something unclear or missing on this page? Tell us at support@sutramx.com.