How to send a push notification from GitHub Actions

Step 1: store your Lert URL as a secret

Open the Lert app and copy your endpoint — something like https://lert.dev/p/your-id. Because anyone with this URL can send you notifications, don't paste it directly into a workflow file that lives in the repo. Instead, store it as an encrypted secret:

1. In your repository, go to Settings → Secrets and variables → Actions.
2. Click New repository secret.
3. Name it LERT_URL and paste your endpoint as the value.

GitHub encrypts the value and masks it in logs, so even echo $LERT_URL shows up as *** in build output. Reference it in a workflow as ${{ secrets.LERT_URL }}.

Step 2: add a notify step

Add a final step to the job you care about. The key is if: always(), which tells Actions to run this step even if an earlier one failed — otherwise a failing build would skip your notification, which is exactly the run you most want to hear about. Pull the outcome from ${{ job.status }} so the message says whether it passed.

name: CI
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm ci && npm test

      - name: Notify phone
        if: always()
        env:
          LERT_URL: ${{ secrets.LERT_URL }}
          STATUS: ${{ job.status }}
        run: |
          curl -X POST "$LERT_URL" \
            -H "Content-Type: application/json" \
            -d "{\"title\":\"CI $STATUS\",\"body\":\"${{ github.repository }} @ ${{ github.ref_name }}\",\"tag\":\"ci\"}"

Push a commit and watch it run. When the job ends, job.status resolves to success, failure, or cancelled, and that word lands on your lock screen alongside the repo and branch. A 200 with {"delivered":1} confirms it went through. Passing the secret through the env block keeps the URL out of the visible command line.

Notify only when the build breaks

Green builds are the boring ones. If you only want a buzz when something is actually wrong, swap always() for failure(). That condition is true only when a previous step in the job failed, so successful runs stay silent.

      - name: Alert on failure
        if: failure()
        env:
          LERT_URL: ${{ secrets.LERT_URL }}
        run: |
          curl -X POST "$LERT_URL" \
            -H "Content-Type: text/plain" \
            --data-binary "❌ ${{ github.repository }} failed on ${{ github.ref_name }}"

Here we use text/plain with --data-binary so branch names or commit text with special characters don't need JSON escaping — the whole body becomes the notification text. This is the version most teams keep on their main branch: quiet until it isn't.

A note on matrix builds

If your job uses a strategy.matrix — say Node 18, 20, and 22 — a notify step inside that job runs once per matrix leg. On a broad matrix that's a lot of buzzes, and it can bump you toward the rate limit (60 requests/minute per IP, 50/day on the Free plan). Two ways to keep it to one notification:

• Reference the leg in the message if you genuinely want per-leg alerts: include ${{ matrix.node }} in the body so each push says which version failed.
• Move the notify to a dependent job that runs after the matrix. Give it needs: [test] and if: always(), and it fires exactly once with the overall result — cleaner for a wide matrix.

  notify:
    needs: [test]
    if: always()
    runs-on: ubuntu-latest
    steps:
      - name: Notify phone
        env:
          LERT_URL: ${{ secrets.LERT_URL }}
          STATUS: ${{ needs.test.result }}
        run: |
          curl -X POST "$LERT_URL" \
            -d "{\"title\":\"CI $STATUS\",\"body\":\"${{ github.repository }} matrix done\"}"

Note the dependent job reads needs.test.result rather than job.status, because it's reporting on the upstream job's outcome, not its own.

Beyond CI

The same one-step pattern works for any workflow: a scheduled cron job, a release pipeline, a nightly data export. Anywhere a runner can execute curl, it can buzz your phone. For deploy-specific wording, see deploy notifications; for the raw request, the curl guide.

Why Lert for GitHub Actions

Most CI notification setups mean adding a Marketplace action, granting it permissions, and storing a webhook or API token you then have to trust and maintain. Lert is a single curl against a secret you control: the endpoint URL is the authentication, nothing runs in your pipeline that you didn't write, and you can regenerate the URL any time. It's the least-privilege way to get your phone to tell you how the build went.