Open Status
Deployment events

Deployment events

Publish release markers and compare service health around deployments.

Deployment tools can publish release markers so responders can correlate service health changes with releases. The Deployments page shows the newest 200 events with service, environment, version, status, correlated monitors, and health comparisons.

Publish an event

POST/api/deployment-events
Scope
events:write
Autorisatie
Bearer-API-sleutel
Snelheidslimiet
120 requests per minute
Herhaalde aanvragen
Idempotent on organization + source + externalId

Records one release marker. Unknown fields are rejected.

Body
sourcestringverplicht

The system publishing the event — the name of your CI provider or deploy tool. Part of the idempotency key.

regel1–80 characters
servicestringverplicht

The service being deployed, as your team names it.

regel1–120 characters
environmentstringverplicht

Which environment the release went to, matching the environment labels you filter monitors by.

regel1–80 characters
versionstringverplicht

The release identifier — a commit, a tag, a build number.

regel1–200 characters
statusenumverplicht

Where the deployment got to.

een vanstarted, succeeded, failed, rolled_back
externalIdstring | nulloptioneel

The originating system's own identifier for this run. Send a stable one: it is the other half of the idempotency key, and an event without it is always new.

standaardnullregel1–200 characters
messagestringoptioneel

A human-readable note shown alongside the event.

standaard""regelup to 2000 characters
urlstringoptioneel

A link back to the run in the originating system.

standaard""regela URL, up to 2000 characters
monitorIdsstring[]optioneel

Monitor IDs used to correlate deployment and health changes. Every ID must belong to the key’s organization or the request is rejected. The Deployments page resolves current monitor names and omits monitors deleted after the deployment.

standaard[]regelup to 100 UUIDs, deduplicated
deployedAtstringoptioneel

When the deployment happened, if that is not when you are telling us about it.

standaardingestion timeregelISO 8601 with an offset
201Created
JSON
{
  "duplicate": false,
  "event": {
    "id": "9c1f0b6e-6c1a-4a75-9d4f-6bb4a4a0f0d1",
    "source": "github-actions",
    "externalId": "run-1842",
    "service": "checkout-api",
    "environment": "production",
    "version": "7d65a2f",
    "status": "succeeded",
    "message": "Production rollout completed",
    "url": "https://example.com/actions/runs/1842",
    "monitorIds": ["5a75c040-9383-4fe3-8c08-aa66c5f149d4"],
    "deployedAt": "2026-01-07T12:00:00.000Z",
    "createdAt": "2026-01-07T12:00:04.118Z"
  }
}
200Duplicate delivery

The same source and externalId were already recorded. The original event is returned and nothing new is stored, so a retrying pipeline is safe.

JSON
{ "duplicate": true, "event": { "id": "9c1f0b6e-…" } }
400Rejected

A field failed validation, or a correlated monitor does not belong to the organization. The body carries the first failing message.

JSON
{
  "error": "Correlated monitors must belong to the organization",
  "code": "error.correlatedMonitorsMustBelong"
}
429Rate limited

RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and Retry-After are on the response. See API rate limits.

Voorbeeldaanvraag
Bash
curl -X POST https://status.example.com/api/deployment-events \
  -H "Authorization: Bearer $STATUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "github-actions",
    "externalId": "run-1842",
    "service": "checkout-api",
    "environment": "production",
    "version": "7d65a2f",
    "status": "succeeded",
    "monitorIds": ["5a75c040-9383-4fe3-8c08-aa66c5f149d4"]
  }'

Read recent events

GET/api/deployment-events
Scope
events:read
Autorisatie
Bearer-API-sleutel
Snelheidslimiet
300 requests per minute

Returns the organization's 200 most recent events, newest first by deployedAt. The same shape the Deployments page renders.

200OK
JSON
{
  "events": [
    { "id": "9c1f0b6e-…", "service": "checkout-api", "status": "succeeded" }
  ]
}

Use deployment evidence during an incident

The incident workspace suggests nearby deployments automatically from a ±24 hour window and affected-monitor overlap. Responders can classify each as suspected, contributing, unrelated, or rolled back. See Incident work.

Related documentation