General

How to Create a Bot That Sends Slack Messages Using Block Kit and GitHub Actions

Chris Trześniewski
7 min read
How to Create a Bot That Sends Slack Messages Using Block Kit and GitHub Actions
This article was written over 18 months ago and may contain information that is out of date. Some content may still be relevant, but please refer to official documentation for the latest information.

Have you ever wanted to get custom notifications in Slack about new interactions in your GitHub repository? If so, then you're in luck. With the help of GitHub actions and Slack's Block Kit, it is super easy to set up automated workflows that will send custom messages to your Slack channel of choice. In this article, I will guide you on how to set up the Slack bot and send automatic messages using GH actions.

Create a Slack app

Firstly, we need to create a new Slack application. Go to Slack's app page. If you haven't created an app before you should see:

Screenshot 2023-10-18 140337

otherwise you might see a list of your existing apps:

Screenshot 2023-10-18 140452

Let's click the Create an App button. Frpm a modal that shows up, choose From scratch option:

Screenshot 2023-10-18 140628

In the next step, we can choose the app's name (eg. My Awesome Slack App) and pick a workspace that you want to use for testing the app.

Screenshot 2023-10-18 140742

After the app is created successfully, we need to configure a couple of additional options. Firstly we need to configure the OAuth & Permissions section:

Screenshot 2023-10-18 140846

In the Scopes section, we need to add a proper scope for our bot. Let's click Add an OAuth Scope in the Bot Token Scopes section, and select an incoming-webhook scope:

Screenshot 2023-10-18 141024

Screenshot 2023-10-18 141158

Next, in OAuth Tokens for Your Workspace section, click Install to Workspace and choose a channel that you want messages to be posted to.

Screenshot 2023-10-18 141332

Screenshot 2023-10-18 141434

Finally, let's go to Incoming Webhooks page, and activate the incoming hooks toggle (if it wasn't already activated).

Screenshot 2023-10-18 141917

Screenshot 2023-10-18 142009

Copy the webhook URL (we will need it for our GitHub action).

Screenshot 2023-10-18 144856

Create a Github Action Workflow

In this section, we will focus on setting up the GitHub action workflow that will post messages on behalf of the app we've just created. You can use any of your existing repositories, or create a new one.

Setting Up Secrets

In your repository, go to Settings -> Secrets and variables -> Actions section and create a New Repository Secret.

Screenshot 2023-10-18 145029

We will call the secret SLACK_WEBHOOK_URL and paste the url we've previously copied as a value.

Screenshot 2023-10-18 145510

Create a workflow

To actually send a message we can use slackapi/slack-github-action GitHub action. To get started, we need to create a workflow file in .github/workflows directory. Let's create .github/workflows/slack-message.yml file to your repository with the following content and commit the changes to main branch.

name: 'Send Slack notification'

on:
  workflow_dispatch:

jobs:
  send-slack-notification:
    runs-on: ubuntu-latest
    steps:
    - name: Send message to Slack workflow
      id: slack
      uses: slackapi/slack-github-action@v1.24.0
      with:
        payload: |
          {
            "text": "Hello Slack",
            "blocks": [
              {
                "type": "section",
                "text": {
                  "type": "mrkdwn",
                  "text": "GitHub Action (${{ github.run_id }}) posted this message"
                }
              }
            ]
          }
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
        SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK

In this workflow, we've created a job that uses slackapi/slack-github-action action and sends a basic message with an action run id. The important thing is that we need to set our webhook url as an env variable. This was the action can use it to send a message to the correct endpoint.

We've configured the action so that it can be triggered manually. Let's trigger it by going to Actions -> Send Slack notification

Screenshot 2023-10-18 145716

We can run the workflow manually in the top right corner.

Screenshot 2023-10-18 145828

After running the workflow, we should see our first message in the Slack channel that we've configured earlier.

Screenshot 2023-10-18 145950

Manually triggering the workflow to send a message is not very useful. However, we now have the basics to create more useful actions.

Automatic message on pull request merge

Let's create an action that will send a notification to Slack about a new contribution to our repository. We will use Slack's Block Kit to construct our message.

Firstly, we need to modify our workflow so that instead of being manually triggered, it runs automatically when a pull requests to main branch is merged. This can be configured in the on section of the workflow file:

on:
  pull_request:
    branches:
      - main
    types:
      - closed

Secondly, let's make sure that we only run the workflow when a pull request is merged and not eg. closed without merging. We can configure that by using if condition on the job:

    - name: Send message to Slack workflow
      id: slack
      uses: slackapi/slack-github-action@v1.24.0
      with:
        payload: |
          {
            "blocks": [
              {
                "type": "header",
                "text": {
                  "type": "plain_text",
                  "text": "A PR was just merged into ${{ github.repo }} :tada:",
                  "emoji": true
                }
              },
              {
                "type": "divider"
              },
              {
                "type": "section",
                "text": {
                  "type": "mrkdwn",
                  "text": "*${{ github.event.pull_request.user.login }}* has just contributed to ${{ github.repository }} :partying_face:"
                }
              }
            ]
          }

We've used a repository name (github.repository) as well as the user login that created a pull request (github.event.pull_request.user.login), but we could customize the message with as many information as we can find in the pull_request event. If you want to quickly edit and preview the message template, you can use the Slack's Block Kit Builder.

Now we can create any PR, eg. add some changes to README.md, and after the PR is merged, we will get a Slack message like this.

Screenshot 2023-10-18 150326

Summary

As I have shown in this article, sending Slack messages automatically using GitHub actions is quite easy. If you want to check the real life example, visit the starter.dev project where we are using the slackapi/slack-github-action to get notifications about new contributions (send-slack-notification.yml)

If you have any questions, you can always Tweet or DM me at @ktrz. I'm always happy to help!

About the author

Chris Trześniewski

Chris Trześniewski

Senior Software Engineer

Software Engineer, ultra-marathoner. He is passionate about functional programming in JavaScript and loves working with RxJS. In his free time he likes to go jogging.

Keep reading

View all posts →

“We were seen as amplifiers, not collaborators,” Ashley Willis, Sr. Director of Developer Relations at GitHub, on How DevRel has Changed, Open Source, and Holding Space as a Leader

Ashley Willis has seen Developer Relations evolve from being on the sidelines of the tech team to having a seat at the strategy table. In her ten years in the space, she’s done more than give great conference talks or build community—she’s helped shape what the DevRel role looks like for software providers. Now as the Senior Director of Developer Relations at GitHub, Ashley is focused on building spaces where developers feel heard, seen, and supported. “A decade ago, we were seen as amplifiers, not collaborators,” she says. “Now we’re influencing product roadmaps and shaping developer experience end to end.” DevRel Has Changed For Ashley, the biggest shift hasn’t been the work itself—but how it’s understood. “The work is still outward facing, but it’s backed by real strategic weight,” she explains. “We’re showing up in research calls and incident reviews, not just keynotes.” That shift matters, but it’s not the finish line. Ashley is still pushing for change when it comes to burnout, representation, and sustainable metrics that go beyond conference ROI. “We’re no longer fighting to be taken seriously. That’s a win. But there’s more work to do.” Talking Less as a Leader When we asked what the best advice Ashley ever received, she shared an early lesson she received from a mentor: “Your presence should create safety, not pressure.” “It reframed how I saw my role,” she says. “Not as the one with answers, but the one who holds the space.” Ashley knows what it’s like to be in rooms where it’s hard to speak up. She leads with that memory in mind, and by listening more than talking, normalizing breaks, and creating environments where others can lead too. “Leadership is emotional labor. It’s not about being in control. It’s about making it safe for others to lead, too.” Scaling More Than Just Tech Having worked inside high growth companies, Ashley knows firsthand: scaling tech is one thing. Scaling trust is another. “Tech will break. Roadmaps will shift. But if there’s trust between product and engineering, between company and community—you can adapt.” And she’s learned not to fall for premature optimization. Scale what you have. Don’t over design for problems you don’t have yet. Free Open Source Isn’t Free There’s one myth Ashley is eager to debunk: that open source is “free.” “Open source isn’t free labor. It’s labor that’s freely given,” she says. “And it includes more than just code. There’s documentation, moderation, mentoring, emotional care. None of it is effortless.” Open source runs on human energy. And when we treat contributors like an infinite resource, we risk burning them out, and breaking the ecosystem we all rely on. “We talk a lot about open source as the foundation of innovation. But we rarely talk about sustaining the people who maintain that foundation.” Burnout is Not Admirable Early in her career, Ashley wore burnout like a badge of honor. She doesn’t anymore. “Burnout doesn’t prove commitment,” she says. “It just dulls your spark.” Now, she treats rest as productive. And she’s learned that clarity is kindness—especially when giving feedback. “I thought being liked was the same as being kind. It’s not. Kindness is honesty with empathy.” The Most Underrated GitHub Feature? Ashley’s pick: personal instructions in GitHub Copilot. Most users don’t realize they can shape how Copilot writes, like its tone, assumptions, and context awareness. Her own instructions are specific: empathetic, plainspoken, technical without being condescending. For Ashley, that helps reduce cognitive load and makes the tool feel more human. “Most people skip over this setting. But it’s one of the best ways to make Copilot more useful—and more humane.” Connect with Ashley Willis She has been building better systems for over a decade. Whether it’s shaping Copilot UX, creating safer teams, or speaking truth about the labor behind open source, she’s doing the quiet work that drives sustainable change. Follow Ashley on BlueSky to learn more about her work, her maker projects, and the small things that keep her grounded in a fast moving industry. Sticker Illustration by Jacob Ashley....

3 mins
Engineering LeadershipGitHub

Integrating Playwright Tests into Your GitHub Workflow with Vercel

Usually workflows configure Playwright to run against a project running on the GitHub action worker itself, maybe with dependencies in Docker containers as well, however why bother setting that all up and configuring yet another environment for your app...

Jamie Kuppens7 mins
VercelPlaywrightGitHub

Ensuring Accurate Workflow Status in GitHub for Enhanced Visibility

Master the nuances of GitHub workflows with our latest blog post. Discover key strategies to ensure your workflows accurately reflect the true status of tests and tasks, preventing misleading green checks. ...

William Mimura3 mins
GitHubGit

Deploying Multiple Apps From a Monorepo to GitHub Pages

Explore deploying multiple front-end applications on GitHub Pages with our guide. Learn how to navigate the challenges of client-side routing and efficiently manage multiple apps in one repository....

Jan Kaiser4 mins
GitHubGitHub ActionsNxReact