Browse Docs

GitHub Actions

Send API Alerts notifications directly from your GitHub Actions workflows. Get notified on deployments, test results, releases, and more.

Two ways to send

Use this for most workflows. Named with: inputs, listed on the GitHub Marketplace, pinned to a known-good version of the API Alerts JavaScript SDK under the hood. Runs on the GitHub-provided Node 24 runner - no separate install step.

@v2 always points at the latest 2.x release. Exact tags like @v2.2.0 are also published per release if you need to pin.

Use this if you’d rather call the API Alerts CLI directly. Same syntax you use locally, no action indirection. Slightly slower cold start while npx fetches the package.

npx @apialerts/cli always resolves the latest release. Pin to an exact version with npx @apialerts/[email protected].

Setup

Add your API Alerts workspace API key as a GitHub Actions secret:

  1. Go to your repository Settings → Secrets and variables → Actions
  2. Click New repository secret
  3. Name it APIALERTS_API_KEY and paste your API key as the value

Two ways to hand the key to the action. Pick whichever fits the workflow:

  • One notification? Inline the secret as api_key: on the step. Zero setup.
  • Multiple notifications in the same workflow? Set APIALERTS_API_KEY once at the workflow or job level. Every step inherits it.

GitHub Actions does not auto-inject repo secrets into actions for security reasons - you always declare the binding somewhere.

Usage

Single notification

Inline the key. One step, one line.

- uses: apialerts/notify-action@v2
  with:
    api_key: ${{ secrets.APIALERTS_API_KEY }}
    event: ci.deploy.success
    message: '🚀 Production deployed'

Success and failure

Two steps with if: success() and if: failure() so each outcome has its own clean configuration. GitHub Actions skips steps after a failure by default, so the if: guards are what make the failure branch fire.

Set APIALERTS_API_KEY once at the job (or workflow) level so neither step has to repeat the credential.

jobs:
  deploy:
    env:
      APIALERTS_API_KEY: ${{ secrets.APIALERTS_API_KEY }}
    steps:
      - run: ./deploy.sh

      - if: success()
        uses: apialerts/notify-action@v2
        with:
          event: ci.deploy.success
          channel: releases
          message: '🚀 Production deployed'
          tags: deploy,production
          link: 'https://app.example.com'

      - if: failure()
        uses: apialerts/notify-action@v2
        with:
          event: ci.deploy.failure
          channel: releases
          message: '❌ Production deploy failed'
          tags: deploy,production
          link: ${{ format('{0}/{1}/actions/runs/{2}', github.server_url, github.repository, github.run_id) }}

Promote env: to the workflow root (above jobs:) instead of a single job if multiple jobs in the same file also fire notifications.

With all options

Every input the action accepts.

- uses: apialerts/notify-action@v2
  with:
    api_key: ${{ secrets.APIALERTS_API_KEY }}
    event: user.signup
    message: 'New user signed up'
    channel: developers
    title: 'New Signup'
    tags: signup,organic
    link: 'https://dashboard.example.com/users/123'
    data: '{"plan": "pro", "region": "us-east-1"}'

Simple notification

- name: Notify
  run: npx @apialerts/cli send -e ci.deploy.success -m '🚀 Production deployed'

Success and failure

- if: success()
  run: npx @apialerts/cli send -e ci.deploy.success -m '🚀 Production deployed' -c releases

- if: failure()
  run: npx @apialerts/cli send -e ci.deploy.failure -m '❌ Production deploy failed' -c releases -l "${{ format('{0}/{1}/actions/runs/{2}', github.server_url, github.repository, github.run_id) }}"

With all options

- name: Notify
  run: |
    npx @apialerts/cli send \
      -e user.signup \
      -m 'New user signed up' \
      -c developers \
      -t 'New Signup' \
      -g signup,organic \
      -l https://dashboard.example.com/users/123 \
      -d '{"plan":"pro","region":"us-east-1"}'

event is optional but recommended. Routers match this value with Unix glob (fnmatch), so ci.* catches all CI events, *.failed catches every failure, and an exact string like user.signup matches only itself. Dotted keys are a tidy convention, not a requirement: free-form keys like User Signup match User * just as well.

Inputs

message is required. Everything else is optional. api_key is also optional if APIALERTS_API_KEY is set in the environment (recommended).

InputDescription
api_keyAPI Alerts workspace API key. Optional if APIALERTS_API_KEY env var is set.
messageHuman-readable notification text. Required. This is what appears on the push notification lock screen.
channelWorkspace channel the push notification fires on. Defaults to the workspace default channel when omitted.
eventWhat kind of thing happened. Optional but recommended. Routers match this value with Unix glob (fnmatch): dotted keys like ci.deploy.success match ci.*, and free-form keys like User Signup match User *. Dotted notation is just a tidy convention, not a requirement.
titleShort headline some destinations render separately from the message body.
tagsComma-separated categorisation tags for filtering and search.
linkURL associated with the event. Available as a deeplink for push notifications and as a call-to-action for routed destinations.
dataJSON string of key-value metadata. Available to non-push destinations for templating.

For the CLI form, the flags map 1:1 - see the CLI reference.

Common scenarios

Deployment notification

- if: success()
  uses: apialerts/notify-action@v2
  with:
    event: ci.deploy.success
    message: "Deployed ${{ github.sha }} to production"
    channel: releases
    link: "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"
    tags: deploy,production

Test failure notification

- if: failure()
  uses: apialerts/notify-action@v2
  with:
    event: ci.tests.failure
    message: "Tests failed on ${{ github.ref_name }}"
    channel: ci
    tags: tests,failure

Which one should I pick?

GitHub ActionCLI via npx
SyntaxNamed with: inputsSame flags as local CLI
Cold startFast (single binary download, cached per runner)Slower (npm fetch on first call)
Marketplace presenceYesNo
Pinning@v2 (or exact @v2.2.0)@apialerts/cli (or exact @apialerts/[email protected])
Best forMost workflowsPower users who already use the CLI locally

Resources