Approve the prod deploy from your phone.

The pipeline pauses, asks on WhatsApp, and continues only on your tap. One step in your GitHub Actions workflow sends the question with ship it / abort buttons (POST /v1/ask under the hood) and blocks until you answer; the deploy step runs only when the answer is the first button. No reply means no deploy — silence never ships. And when the job finishes, a one-line ping (POST /v1/notify) tells you how it went.

Two steps: the gate asks and waits (up to 90 seconds, the server maximum), the deploy runs behind an if on the gate's button-id output. That's the whole wiring — the action is grzgrzgrz3/pingwa-action, your key sits in a repo secret.

name: deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Ask before shipping
        id: gate
        uses: grzgrzgrz3/pingwa-action@v1
        with:
          api-key: ${{ secrets.PINGWA_KEY }}
          mode: ask
          message: "Deploy ${{ github.repository }} @ ${{ github.sha }} to prod?"
          buttons: "ship it,abort"

      - name: Deploy
        if: steps.gate.outputs.button-id == 'b0'
        run: ./deploy.sh

The fail-safe reading: if you don't answer within the 90 seconds, /v1/ask returns HTTP 408 and the gate step fails — the deploy step never runs. Tapping abort keeps the gate green with button-id=b1 and the deploy is simply skipped. button-id is positional: b0 is the first label you passed, b1 the second — only an explicit b0 ships. The question was still delivered to your phone either way; a late tap is retrievable afterwards via GET /v1/messages/<id>/reply.

If the ask lands outside your 24h reply window (likely, for deploys that arrive out of the blue), the buttons arrive as a numbered list instead of tap buttons — replying 1 (or the button's text, ship it) works the same and still maps to b0.

Same action, mode: notify (the default). With if: always() the ping fires on success and failure, and job.status puts the verdict in the message — the deploy you approved from the couch reports back to the couch.

      - name: Ping when done
        if: always()
        uses: grzgrzgrz3/pingwa-action@v1
        with:
          api-key: ${{ secrets.PINGWA_KEY }}
          message: "${{ github.workflow }} on ${{ github.repository }}: ${{ job.status }}"

GitLab CI, Jenkins, Woodpecker, a bare deploy script — the gate is the same /v1/ask call with a jq check on .reply.button_id. The GitHub action is exactly this curl inside; there's nothing platform-specific about the pattern.

reply=$(curl -sS --max-time 95 -X POST https://pingwa.dev/v1/ask \
  -H "Authorization: Bearer $PINGWA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text": "Deploy to prod?", "buttons": ["ship it","abort"], "timeout": 90}')

[ "$(printf '%s' "$reply" | jq -r '.reply.button_id')" = "b0" ] || exit 1
./deploy.sh

curl -sS -X POST https://pingwa.dev/v1/notify \
  -H "Authorization: Bearer $PINGWA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text": "deploy: done"}'

Same fail-safe shape: the gate compares against b0, so anything else fails it — a 408 or error body makes jq print null, an abort tap yields b1, and either way exit 1 stops the script before the deploy line. One difference from the GitHub variant: that exit 1 also skips the final notify (a bare script has no if: always()) — move the notify before the exit, or trap it, if you want failure pings too.

Scan the code and get instant access. It opens WhatsApp with “join” ready to send, and your API key comes straight back.

Deploy gates are exactly the messages you want rare and deliberate — the free plan's 30 paid messages a month cover a healthy release cadence, and your button-tap replies inside the 24h window are free.