How to Send CI/CD Deployment Notifications to a Team

Add a PingRoom incoming webhook or CLI step to the transitions where a deployment changes human work: Started, Succeeded, Failed, and Rolled back. Do not forward every build log line.

Give each release one identity

Include the service, environment, short revision, and safe run URL. Use the pipeline run or deployment ID as correlation_id so later events can be associated with the same release.

{
  "title": "Production deploy failed",
  "message": "payments-api · revision 8f31c2",
  "data": {"environment":"production","revision":"8f31c2"},
  "correlation_id": "deploy-48219"
}

Store the room webhook URL as a masked CI secret. Never include source tokens, cloud credentials, full environment dumps, or sensitive log output in the payload.

Use separate rooms or urgency levels for preview and production environments. A routine preview success should not have the same sound as a production rollback.

Keep the integration symmetrical: every Started event should eventually have a terminal Succeeded, Failed, or Rolled back event. If a workflow is cancelled, say so explicitly. This makes the room history understandable without asking engineers to infer state from silence.

Use a Question for a real gate

A notification that says “deploying” is informational. If the workflow must pause for a human, create an approval or Question with explicit options and treat expiry as no approval—not success. Record the decision in the CI system that owns the deployment.

PingRoom is an attention and decision layer, not the deployment engine or immutable audit log. Preserve native CI status, retry behavior, and incident escalation. Explore the CI approval gate pattern and developer documentation.