Slack or Email Notifications

You just pushed a fix to your main branch, your CI pipeline is running, and you walk away to grab coffee. Twenty minutes later you come back to find that the build failed — and the only reason you know is because you happened to refresh the page. That's the pain of a silent pipeline. Without proactive notifications, you're always one step behind, discovering broken builds, failed deployments, or stuck workflows only when it's too late. In this lesson, you'll learn how to set up Slack or email notifications for your CI/CD pipeline, so you're alerted the moment something goes wrong — and you can act before your users ever notice.

The problem this lesson solves

CI/CD pipelines are the automation engine of modern software delivery, but automation alone isn't enough. A pipeline that runs silently is like a smoke detector with a dead battery. When a build fails, a test suite breaks, or a deployment hits a snag, you need to know immediately. Without proactive notifications, you suffer:

• Delayed incident response — the longer a failure goes unnoticed, the harder it is to diagnose and fix.
• Wasted developer time — manually checking pipeline status is tedious and error-prone.
• Broken trust — if users hit a broken deployment before you do, your team's reliability reputation suffers.

Email and Slack are the two most common notification channels for CI/CD. Email is universal, reliable, and perfect for audit trails. Slack (or other chat tools like Microsoft Teams or Discord) is immediate, interactive, and central to developer workflows. This lesson gives you both options, because you'll need different channels for different situations — a failure alert deserves Slack's instant visibility, while a nightly test report might be better suited for email.

Core concept / mental model

Think of your CI pipeline as a watchdog — it runs your tests, builds artifacts, and deploys code. Notifications are the leash. The watchdog only helps if it can pull you to attention when something's wrong.

Here's the mental model:

• Pipeline events → Notification triggers → Delivery channel → Your attention

A pipeline has events (e.g., a job starts, a job finishes, a failure occurs). Notification configuration defines triggers that map those events to actions (e.g., send a Slack message, send an email). The channel is just the medium — Slack for real-time, email for async.

In GitHub Actions, notifications work through third-party actions (like slackapi/slack-github-action or dawidd6/action-send-mail) or through native features like email notifications built into GitHub. But the key insight is: notifications are configured, not automatic. You have to explicitly wire the pipeline event to the notification action, often using conditionals to only alert on failures or successes.

How it works step by step

Whether you're using GitHub Actions (which this track focuses on) or any other CI system, the steps follow the same pattern:

1. Identify the events you care about — usually failure, success, or both. Most teams alert on failures first, then gradually add success alerts for important branches or deployments.

2. Get the credentials — for Slack, create an incoming webhook URL; for email, use an SMTP server (like Gmail's SMTP or SendGrid) and obtain credentials.

3. Store secrets securely — never hardcode tokens or credentials in your workflow files. Use GitHub's secrets feature (Settings → Secrets → Actions) to store them securely.

4. Add the notification step — in your workflow YAML, add a step after the critical jobs that uses the notification action. Use conditionals (if: failure(), if: success()) to control when it runs.

5. Test the trigger — intentionally break your pipeline to verify the notification fires. There's nothing worse than a silent alert.

6. Monitor and adjust — notifications are not set-and-forget. If you get too many alerts, your team will tune them out. Adjust thresholds and channels as your pipeline evolves.

Hands-on walkthrough

Let's set up both Slack and email notifications for a GitHub Actions workflow. First, set up Slack.

Step 1: Create a Slack incoming webhook

In Slack, go to Your Slack → Apps → Incoming Webhooks, create a new webhook for your channel, and copy the URL. It looks like: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX.

Store it as a secret in your GitHub repository: Settings → Secrets and variables → Actions → New repository secret → name it SLACK_WEBHOOK_URL.

Step 2: Add a Slack notification step

Create a workflow file .github/workflows/notify.yml:

name: CI with Slack Notifications

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          echo "Running tests..."
          # Simulate a failing test for illustration
          exit 1
      - name: Notify Slack on failure
        if: failure()
        uses: slackapi/slack-github-action@v1.26.0
        with:
          payload: |
            {
              "text": "🚨 CI failed in ${{ github.repository }} on ${{ github.ref }} by ${{ github.actor }}"
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Expected output: The Run tests step fails, and then the Notify Slack on failure step runs — a message appears in your Slack channel with the text "🚨 CI failed in your/repo on refs/heads/main by your-username".

Step 3: Set up email notifications

Email notifications in GitHub Actions use the dawidd6/action-send-mail action. You'll need SMTP credentials. Here's an example using Gmail's SMTP:

Storing secrets: SMTP_SERVER=smtp.gmail.com, SMTP_PORT=465, SMTP_USERNAME=you@gmail.com, SMTP_PASSWORD=your-app-password (use an app password, not your regular password).

name: Email on Failure

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: exit 1
      - name: Send email on failure
        if: failure()
        uses: dawidd6/action-send-mail@v3
        with:
          server_address: ${{ secrets.SMTP_SERVER }}
          server_port: ${{ secrets.SMTP_PORT }}
          username: ${{ secrets.SMTP_USERNAME }}
          password: ${{ secrets.SMTP_PASSWORD }}
          subject: 'CI Failed - ${{ github.repository }}'
          to: 'team@example.com'
          from: 'CI Bot <ci@example.com>'
          body: |
            The build failed on ${{ github.ref }}.
            Check the logs: ${{ github.server_url }}/${{ github.repository }}/actions

Expected output: An email arrives with the subject "CI Failed - your/repo" and the body containing the branch and a link to the failed run.

Pro tip: For Gmail, you must enable 2-factor authentication and create an App Password (Google Account → Security → App passwords). Using your regular password won't work.

Step 4: Notify on success too (optional)

Some teams want success notifications for important branches (like main) or for deployments. Use if: success() to trigger only when the job passes:

      - name: Notify Slack on success
        if: success()
        uses: slackapi/slack-github-action@v1.26.0
        with:
          payload: |
            {
              "text": "✅ Build passed for ${{ github.repository }} on ${{ github.ref }}"
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Compare options / when to choose what

When to choose what:

• Slack for anything time-sensitive — pull request failures, deployment issues, or when you want to use @channel to grab the whole team's attention.
• Email for non-urgent, historical summaries — like nightly test reports or weekly build health digests.
• GitHub native email is a no-code option for individual contributors, but lacks the customization and centralization of a dedicated notification action.

Troubleshooting & edge cases

Even with straightforward configuration, things go wrong. Here's how to fix common issues:

• Notification step doesn't run — Check your if condition. A common mistake is using if: failure() but putting the step in a job that succeeded. Use if: always() if you want the notification to run regardless, but be careful — it will fire on success too. Better: use failure() and success() which are job-level functions that evaluate the entire job's outcome.

• Secrets not found — You'll see an error like Error: Input required and not supplied: webhook. This means the secret isn't set or you misspelled the name. Go to Settings → Secrets, verify the exact name matches what you reference in ${{ secrets.SECRET_NAME }}.

• SMTP authentication fails — For Gmail, double-check you're using an app password, not your regular Gmail password. For other SMTP providers, make sure the port is correct (465 is SSL, 587 is TLS — most actions handle SSL automatically, but verify).

• Slack message doesn't appear — Check the webhook URL is correct and the channel the webhook points to exists. Also verify the payload is valid JSON — a malformed payload will be silently ignored.

• Too many notifications (alert fatigue) — If your team gets flooded, narrow your triggers. Only alert on failures, or only on main branch, or use a job.step condition like if: failure() && github.ref == 'refs/heads/main'.

• Email goes to spam — Add your sender address (like ci@example.com) to your team's safe senders list. Consider using a dedicated email service like SendGrid for better deliverability.

What you learned & what's next

By now you've learned how to set up Slack or email notifications for your CI/CD pipeline. You can explain the core idea — that pipeline events become notification triggers — and you've completed a practical exercise wiring both Slack and email alerts to a GitHub Actions workflow. You also know how to compare Slack versus email versus native GitHub notifications, and you can troubleshoot the most common misconfigurations.

Ready to take the next step? In the next lesson, you'll move from notifying about pipeline status to controlling the flow — learning how to add manual approvals and gate promotions so a human can sign off before code reaches production. That's where real operational maturity begins: first you see the fire, then you control who opens the door.