Get Alerted When CI/CD Pipelines Fail (or Succeed)

The problem

Your CI pipeline fails at 2:47pm. You notice at 3:23pm. In between, your deploy went out with the broken artifact, your team is reviewing a PR against a broken main branch, and someone on Slack is asking why staging looks weird.

The failure mode is not that CI systems lack notifications. They all have notifications. The failure mode is that the notifications they send are not the notifications you actually see. Email gets filtered. The dashboard icon turns red on a browser tab you closed three hours ago. The default GitHub notification lands in a browser while you’re heads-down in your editor with notifications muted. By the time you find out, the window where fixing the problem was cheap has closed.

Worse: a build that succeeds but produces a broken artifact gets no notification at all. Success without verification is still failure with a delay.

The general shape of the fix

Every modern CI system has at least one of: a native HTTP integration, a shell step that can run curl, or a plugin ecosystem. That’s all you need. Add one step at the end of the pipeline that posts the outcome to API Alerts, and your phone buzzes the moment it finishes.

The shape of every implementation below is the same:

1. Run on both success and failure. A success notification is cheap to ignore. A missing failure notification is expensive.
2. Include a direct link back to the run. You want to tap the notification and land on the broken pipeline, not hunt for it in a dashboard.
3. Include the branch, commit SHA, and job name. Enough context to know what broke without opening the link.
4. One channel per pipeline or environment. Production deploys, staging deploys, mobile CI, and long-running test suites each get their own channel so the feed stays scannable instead of turning into a firehose.

What this buys you: the failure lands on your home screen the moment it happens, with a tap-through link straight to the broken run. No inbox archaeology, no Slack catch-up, no tab graveyard of CI dashboards you forgot you had open.

Implementation by CI system

GitHub Actions

GitHub Actions has a first-party integration via the apialerts/notify-action@v2 action. Add it as the final step in any workflow:

- name: Notify
  if: success() || failure()
  uses: apialerts/notify-action@v2
  with:
    api_key: ${{ secrets.API_ALERTS_KEY }}
    channel: 'developer'
    message: ${{ job.status == 'success' && 'Deploy succeeded' || 'Deploy failed' }}
    tags: 'deploy,staging'
    link: ${{ format('{0}/{1}/actions/runs/{2}', github.server_url, github.repository, github.run_id) }}

The if: success() || failure() guard ensures the step runs regardless of outcome, so you get notifications on failed jobs (which GitHub would otherwise skip by default).

See the GitHub Actions integration page for the full input reference, example workflows for mobile CI, deployment notifications, and more.

Jenkins

Jenkins uses a post block in a Declarative pipeline to run steps regardless of build outcome:

post {
    always {
        sh '''
            curl -X POST https://api.apialerts.com/event \\
              -H "Authorization: Bearer $API_ALERTS_KEY" \\
              -H "Content-Type: application/json" \\
              -d "{
                \\"channel\\": \\"developer\\",
                \\"message\\": \\"Build $BUILD_NUMBER finished with status $BUILD_STATUS\\",
                \\"link\\": \\"$BUILD_URL\\",
                \\"tags\\": [\\"jenkins\\"]
              }"
        '''
    }
}

Store API_ALERTS_KEY as a Jenkins credential and expose it to the step via withCredentials or your pipeline’s environment block. The $BUILD_URL env var gives you a direct link back to the run.

GitLab CI

GitLab CI uses a dedicated job with when: always to run regardless of the rest of the pipeline’s outcome:

notify:
  stage: .post
  when: always
  script:
    - |
      curl -X POST https://api.apialerts.com/event \
        -H "Authorization: Bearer $API_ALERTS_KEY" \
        -H "Content-Type: application/json" \
        -d "{
          \"channel\": \"developer\",
          \"message\": \"Pipeline $CI_PIPELINE_ID on $CI_COMMIT_REF_NAME finished with status $CI_JOB_STATUS\",
          \"link\": \"$CI_PIPELINE_URL\",
          \"tags\": [\"gitlab\"]
        }"

GitLab’s $CI_JOB_STATUS resolves to the job’s final outcome, and $CI_PIPELINE_URL links directly to the run. Set API_ALERTS_KEY as a project or group CI/CD variable.

CircleCI

CircleCI runs steps conditionally via when: always inside a run command:

- run:
    name: Notify
    when: always
    command: |
      curl -X POST https://api.apialerts.com/event \
        -H "Authorization: Bearer $API_ALERTS_KEY" \
        -H "Content-Type: application/json" \
        -d "{
          \"channel\": \"developer\",
          \"message\": \"$CIRCLE_JOB on $CIRCLE_BRANCH finished (build $CIRCLE_BUILD_NUM)\",
          \"link\": \"$CIRCLE_BUILD_URL\",
          \"tags\": [\"circleci\"]
        }"

Set API_ALERTS_KEY as a project environment variable or via a CircleCI context so multiple projects can share the same credential.

Bitrise

Add a Script step at the end of your workflow with the same curl pattern. Bitrise exposes build details via $BITRISE_BUILD_URL, $BITRISE_GIT_BRANCH, and $BITRISE_BUILD_NUMBER:

#!/usr/bin/env bash
curl -X POST https://api.apialerts.com/event \
  -H "Authorization: Bearer $API_ALERTS_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"channel\": \"developer\",
    \"message\": \"Bitrise build $BITRISE_BUILD_NUMBER on $BITRISE_GIT_BRANCH finished\",
    \"link\": \"$BITRISE_BUILD_URL\",
    \"tags\": [\"bitrise\"]
  }"

Set API_ALERTS_KEY as a secret env var in your app’s settings. Bitrise will mask it in logs automatically.

Any CI with a shell step

If your CI system is not listed above, the generic pattern works anywhere you can run a shell command at the end of a pipeline. The only variables are your own API key, your channel name, and whatever env vars your CI exposes for the build URL and branch:

curl -X POST https://api.apialerts.com/event \
  -H "Authorization: Bearer $API_ALERTS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "developer",
    "message": "Build finished",
    "link": "https://your-ci.com/build/123",
    "tags": ["ci"]
  }'

See the curl reference for the full request shape and the HTTP API introduction for the complete event schema.

Related integrations

• GitHub Actions integration. First-party action with a full input reference.
• curl reference. For the generic shell-step pattern used by Jenkins, GitLab CI, CircleCI, Bitrise, and anything else with a shell step.
• HTTP API introduction. The complete event schema and authentication shape.

Get started in 5 minutes

1. Create a free workspace and grab an API key
2. Add the snippet for your CI system to your pipeline’s final step (or post block)
3. Push a commit and watch the notification land
4. Install the API Alerts mobile app if you haven’t, and confirm the notification lands on your home screen

Works with any CI system that has a shell step. Free tier is 1,000 events per month, no credit card required.