Send a weekly GitHub digest to Slack: four ways

GitHub’s official Slack integration will not do this. It is worth stating up front, because most people start there and lose an afternoon. The GitHub Slack app subscribes a channel to events and notifies as they happen: commits on the default branch, pull requests, issues, releases, deployments. Real-time, one message per event. Its scheduled reminders feature nudges people about pending reviews rather than summarising what shipped.

So a weekly digest means building or buying something. Four routes, roughly in order of effort.

Route 1: Zapier

The lowest-effort option. Zapier has a prebuilt path that posts a digest of new GitHub commits to a Slack channel on a daily, weekly, or monthly basis, and a companion one for pull requests. Commits accumulate into a digest, and the digest releases on your schedule.

Set up is minutes and requires no code. The limits show up quickly. You are digesting commit subjects, so the output quality is capped by how your team writes commit messages, and you are paying per task in a plan that scales with repository count. It works well for one or two repositories and gets expensive and noisy past that.

Route 2: A GitHub Actions cron job

Free, lives in the repository, and you control the format entirely. GitHub Actions supports a schedule trigger using POSIX cron syntax.

name: Weekly digest
on:
  schedule:
    # 08:17 UTC every Monday. Odd minute is deliberate, see below.
    - cron: "17 8 * * 1"
  workflow_dispatch:

jobs:
  digest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Build the digest
        id: build
        run: |
          {
            echo "body<<EOF"
            git log --since="7 days ago" --no-merges \
                    --pretty=format:"• %s (%an)" main
            echo ""
            echo "EOF"
          } >> "$GITHUB_OUTPUT"

      - name: Post to Slack
        env:
          WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}
        run: |
          jq -n --arg t "${{ steps.build.outputs.body }}" \
             '{text: ("*This week in \(env.GITHUB_REPOSITORY)*\n" + $t)}' \
            | curl -sS -X POST -H 'Content-type: application/json' \
                   --data @- "$WEBHOOK"

fetch-depth: 0 matters. The default checkout is shallow and git log --since will silently return almost nothing without it. That one line is the most common reason this workflow appears to work and posts an empty digest.

Three caveats GitHub documents on the events that trigger workflows page, all of which will bite eventually:

• Scheduled runs can be delayed during periods of high Actions load, and the top of every hour is a high load time. Schedule at an odd minute past the hour, which is why the example uses 17.
• The shortest interval is once every five minutes. Irrelevant for a weekly digest, relevant if you get ambitious.
• In public repositories, scheduled workflows are disabled automatically after 60 days with no repository activity. A quiet public repo will stop reporting exactly when the silence was the thing you wanted to know about.

Also worth knowing: the schedule runs on the default branch only, and cron has no notion of your team’s timezone unless you account for it yourself.

Route 3: A bot or script on your own scheduler

If you have more than a handful of repositories, per-repository Actions workflows stop making sense. The usual next step is one small service that queries the GitHub API across the org, formats a digest, and posts to Slack from a cron job you already run.

More work up front, but you get things the previous two routes cannot give you: a digest that spans repositories, grouping by project or team rather than by repo, and a report that still arrives when a repository has been quiet. If you are prototyping the formatting logic locally first, generating a commit report from the command line covers the git log invocations to build on.

The maintenance cost is real and easy to underestimate. Token rotation, rate limits, pagination, and someone noticing when the job dies quietly.

Route 4: A purpose-built reporting tool

The category exists because every route above delivers commit subjects, and commit subjects are written by developers for developers. If the Slack channel receiving the digest contains a founder, a PM, or an account manager, a list of forty lines beginning fix: and chore: is not a report. It is a feed with a schedule attached.

Tools in this space read the actual changes and write prose, scoped to a project or a team rather than a repository. What to check before paying for one: whether it can scope to something other than a single repository, whether it reads the branch you actually ship from, and whether it will show you real output on your own code during a trial. We compare the current options in the best GitHub reporting tools.

Picking a route

One repository, technical audience, want it today: Zapier.

One or two repositories, want control over the format, comfortable in YAML: the Actions cron job.

Many repositories, engineers reading it, and someone who will own the code: your own script.

Any repository count, non-technical people in the channel: a reporting tool, or accept that you are shipping a feed and adjust who is in the channel.

What goes inside the digest is a separate decision from how it gets there, and how to report engineering progress to non-technical stakeholders covers the format that survives a real audience.

The formatting choices that make a digest readable, and the scope and cadence decisions behind them, are covered in the guide to GitHub reporting for non-technical stakeholders.

DevSummary is the fourth route, with email delivery alongside Slack, because the digest that ends up in a board pack needs to be forwardable.

Delivery is the easy half. Getting something worth delivering is the rest of it.