Get an SMS when your GitHub Actions deploy fails.
Add a failure-only SMS step to an existing GitHub Actions deployment job. Keep deployment status intact and send alerts to your own verified phone.
1. Get your key and save a repository secret
Sign in with your phone number and copy or create a key on the SelfPing dashboard. Each key can text only that phone. Free accounts get 10 texts a month; Hobby is $5/month for 100. Each send uses one credit.
In the repository that runs your deployment, add an Actions secret named SELFPING_API_KEY. Keep the value out of YAML, source control, and logs. This guide extends an existing GitHub Actions deploy job.
2. Add this after your deployment step
Place this step inside the same job, after the steps whose failure you want to catch. GitHub's failure() condition runs it when an earlier step in that job fails. continue-on-error prevents an SMS problem from changing the failed deployment's outcome.
This watches the GitHub Actions job. A separate deployment launched by a hosting provider's Git integration needs that provider's deployment-status event instead.
- name: Text me if deployment fails
if: failure()
continue-on-error: true
env:
SELFPING_API_KEY: ${{ secrets.SELFPING_API_KEY }}
run: |
curl --fail-with-body --connect-timeout 5 --max-time 15 \
https://www.selfping.com/api/sms \
-H "Authorization: Bearer $SELFPING_API_KEY" \
--json '{"message":"Production deploy failed. Check the GitHub Actions run before retrying."}'3. Verify it with a controlled failure
Use a test branch and an isolated workflow with no production deployment steps. Add a step that runs exit 1 before the alert step. Running that test sends a real text and consumes one credit. Do not deliberately break your production deploy.
Confirm the workflow remains failed, the SMS arrives, and the SelfPing dashboard records delivery. An accepted API request alone does not prove delivery. The step does not automatically retry; a timeout can leave a send unconfirmed.
4. Check the job and delivery logs
No alert step: check that it is in the failed job, not a different job, and that the workflow was not cancelled. No text: check the secret, credit balance, and final delivery status. HTTP 401 indicates an authentication problem; HTTP 429 can indicate exhausted credits or a rate limit.
Name the deployment or project in the message if you run several. Keep stack traces, credentials, and private build output in Actions logs rather than in the text.