CI/CD deploys

Q: How do I notify my team about a finished deploy?

With a curl step at the end of the CI job that posts to /api/push/send. Any runner that speaks HTTP will do. The team gets the message on their phones in real time without watching the pipeline.

Q: How do I tell successful builds from failed ones?

Set the notification step to always so it also runs after a failure, and pass the job status in the title. For failed builds it is worth adding "urgent": true so the message arrives immediately even during quiet hours.

Q: How do I separate staging from production?

With separate channels, for instance deploys-staging and deploys-prod. API key scopes then let a CI key write only to the channel it is meant for.

Automatically tell your team when a build or deploy is done.

No more staring at the pipeline: with PushPig your CI/CD notifies the team automatically as soon as a build or deployment finishes or fails. A single HTTP request at the end of the job is all it takes.

Wire it into the pipeline

GitHub Actions, GitLab CI, Jenkins or a shell deploy script. Any runner that can run curl can send:

- name: Notify PushPig
  if: always()
  run: |
    curl -X POST https://pushpig.de/api/push/send \
      -H "Authorization: Bearer pp_YOUR_API_KEY" \
      -H "Content-Type: application/json" \
      -d "{\"channel\":\"deploys\",\"title\":\"Deploy ${{ job.status }}\",\"body\":\"${{ github.repository }} @ ${{ github.sha }}\"}"

Tell success from failure

Set the job to always and pass the status in the title, so you know at a glance whether the deploy went through or needs attention. For failed builds, "urgent": true makes sure the message arrives even during quiet hours.

One channel per environment

Split deploys-staging and deploys-prod into separate channels. With API key scopes a CI key can then write only to the production channel, for example: cleanly separated and locked down.

Save recurring messages as a template and let the pipeline fill in just the variables (version, environment): consistent deploy messages without copy-and-paste.

And the other way round

Want to feed PushPig events back into your own system? With webhooks you get HMAC-signed delivery events (push.sent, push.failed) straight into your infrastructure.

Frequently asked questions

How do I notify my team about a finished deploy?

With a curl step at the end of the CI job that posts to /api/push/send. Any runner that speaks HTTP will do. The team gets the message on their phones in real time without watching the pipeline.

Does this work with GitHub Actions, GitLab CI and Jenkins?

Yes, with all three and with any shell deploy script. No plugin and no integration is required, just an HTTP request with your API key in the Authorization header.

How do I tell successful builds from failed ones?

Set the notification step to always so it also runs after a failure, and pass the job status in the title. For failed builds it is worth adding "urgent": true so the message arrives immediately even during quiet hours.

How do I separate staging from production?

With separate channels, for instance deploys-staging and deploys-prod. API key scopes then let a CI key write only to the channel it is meant for.

Can I feed delivery events back into my own system?

Yes, via webhooks. PushPig then calls a URL in your infrastructure on push.sent or push.failed, HMAC-signed and with a stable delivery ID across every retry.

Help & API · Pricing · Contact · Imprint · Privacy