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:
- Go to your repository Settings → Secrets and variables → Actions
- Click New repository secret
- Name it
APIALERTS_API_KEYand 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_KEYonce 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).
| Input | Description |
|---|---|
api_key | API Alerts workspace API key. Optional if APIALERTS_API_KEY env var is set. |
message | Human-readable notification text. Required. This is what appears on the push notification lock screen. |
channel | Workspace channel the push notification fires on. Defaults to the workspace default channel when omitted. |
event | What 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. |
title | Short headline some destinations render separately from the message body. |
tags | Comma-separated categorisation tags for filtering and search. |
link | URL associated with the event. Available as a deeplink for push notifications and as a call-to-action for routed destinations. |
data | JSON 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 Action | CLI via npx | |
|---|---|---|
| Syntax | Named with: inputs | Same flags as local CLI |
| Cold start | Fast (single binary download, cached per runner) | Slower (npm fetch on first call) |
| Marketplace presence | Yes | No |
| Pinning | @v2 (or exact @v2.2.0) | @apialerts/cli (or exact @apialerts/[email protected]) |
| Best for | Most workflows | Power users who already use the CLI locally |
Resources
- GitHub Marketplace
- GitHub Actions integration overview
- API Alerts CLI
- Mobile CI/CD build alerts for a full walkthrough with Android and iOS examples