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.

For concrete implementations, use the GitHub Actions terminal-result recipe, Jenkins Pipeline phone-alert recipe, or GitLab CI terminal-result guide. Each covers protected credentials, terminal-state mapping, and retry-safe request identity without turning every build step into an alert.

When Vercel owns the production transition, use the Vercel production-promotion webhook recipe to verify the platform signature, filter one project, and keep deployment metadata out of the phone alert.

When Netlify owns it, use the Netlify production-deploy webhook recipe to verify the JWS, accept one site’s ready production deploys, and forward fixed copy rather than deploy metadata.

When CircleCI owns the workflow, use the CircleCI workflow-completion recipe to verify circleci-signature, filter one project and workflow, and reuse the event ID for retry-safe success Pings.

When Buildkite owns the pipeline, use the Buildkite build-success recipe to verify its timestamped raw-body signature, accept one pipeline's unblocked passed state, and reuse the build UUID for retry identity.

When Azure DevOps owns it, use the Azure DevOps build-success service-hook recipe to select one pipeline definition, accept only Succeeded, and keep build metadata out of the phone alert.

When AWS CodeBuild owns it, use the CodeBuild success-alert recipe to gate on CODEBUILD_BUILD_SUCCEEDING, protect the webhook URL in Secrets Manager, and reuse the build ID for an exact retry.

When Google Cloud Build owns it, use the Google Cloud Build success-alert recipe to accept authenticated Pub/Sub pushes in a private receiver, filter one trigger's SUCCESS event, and reuse the Pub/Sub message ID for replay safety.

For TeamCity, the build-success phone-alert recipe filters one BUILD_FINISHED webhook by build configuration and status, then maps retries to one fixed Ping.

For Travis CI, the signed build-success webhook recipe verifies the published-key signature, filters one repository and branch, and keeps build metadata out of the shared alert.

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.