GitHub Slack Reminders Not Sending: Checks and Fixes

A scheduled reminder that never arrives is the worst kind of bug, because silence looks exactly like "nothing to report". You set up GitHub's native scheduled reminders for your team, picked a channel and a time, and Monday morning came and went with an empty Slack channel. Meanwhile three pull requests have been sitting for a week.

The cause is almost always one of a short list, and the symptoms split cleanly in two. Either no post appeared in the channel at all, or a post appeared but nobody was pinged. Those are different failures with different fixes, so the first job is to say which one you have.

This guide is an ordered diagnosis for GitHub scheduled reminders for teams. It starts with the cheapest checks (authorization, channel access, schedule), moves to the filter logic that quietly empties a reminder, and uses the reminder's own test control to prove each fix instead of waiting for next Monday. Work top to bottom and stop at the first thing that is wrong.

Quick answer: the four things to check first

If you want the short version, these four checks explain most cases of GitHub Slack reminders not sending, in rough order of how often they bite:

1. Authorization. The Slack workspace was never authorized for the GitHub organization by an org owner, or the authorization was removed.

2. Channel reach. The reminder points at a private channel and the GitHub app was never invited to it.

3. Schedule. The days, time or timezone are not what you think they are, so the reminder fires at a moment you did not expect.

4. Filters. Every open PR is excluded by a filter, so the reminder has nothing to say and posts nothing.

Number four is the sneaky one. A reminder with zero matching pull requests does not post an empty digest. It stays silent, and that looks exactly like a broken integration unless you know to check.

Before you touch anything, decide which symptom you have. If the channel shows no post at all, work through Steps 1 to 5. If a post shows up but nobody got a notification, skip to the section on mentions and /github signin. Don't mix the two. Fixing channel permissions won't make an unlinked account start receiving pings, and relinking an account won't make a missing post appear.

One rule for the whole process: change one thing, then run the test in Step 5 before you change the next. If you change three settings at once and the post arrives, you won't know which one mattered, and you'll repeat the same mistake on the next team.

Step 1: Confirm the Slack workspace is authorized by an org owner

Team reminders are configured against the GitHub organization, and the Slack side has to be authorized for that organization before anything can post. If that handshake never completed, the reminder saves fine in the UI and then does nothing.

The usual failure is permissions. Team maintainers and organization owners can set team scheduled reminders, but an organization owner must authorize the Slack workspace before a team reminder can be created. If the person who set up the reminder was not an owner, the form may look finished while the underlying connection was never approved.

Check these in order:

• Ask an org owner to open the organization's settings, find the Slack integration for scheduled reminders, and confirm the correct Slack workspace is listed as authorized.

• If your company has more than one Slack workspace (a common leftover from acquisitions), confirm the authorized workspace is the one where your channel actually lives. Authorizing the wrong one is easy and produces total silence.

• If the authorization was granted long ago by someone who has since left, have a current owner re-authorize. Removing a person's access can break a connection they created.

Here's a before and after. Before: a maintainer saves a Monday 09:30 reminder for @acme/payments and nothing ever appears. After: an owner re-authorizes the workspace, the maintainer reruns the test (Step 5), and the post lands in the channel within moments.

If you keep hitting ownership problems, treat it as a process fix. Put the Slack authorization on the checklist for whoever owns org tooling, not on the personal to-do list of one engineer. Connections tied to one person's account fail when that person changes roles.

Step 2: Confirm the channel is reachable (private channels need /invite @github)

A correctly authorized workspace still can't post into a channel it can't see. Public channels are usually fine. Private channels are where reminders go to die.

The fix is one line. In the private channel, type:

/invite @github

Slack adds the GitHub app as a member, and the reminder can now post there. Without it, the app has no standing in that channel, so the reminder has nowhere to deliver and nothing appears. People often assume that because they, an admin, can see the channel, the app can too. It can't. Membership is per member, and the app is a separate member.

A few related traps are worth checking while you're in Slack:

• Renamed or archived channels. If someone archived #team-payments-reviews and created #payments-reviews, a reminder still pointed at the old channel will fail quietly. Reopen the reminder and reselect the channel.

• Channel converted from public to private. This happens during tidy-ups. A reminder that worked for months stops the week the channel went private, because the app lost its access in the conversion.

• Wrong channel entirely. Confirm the channel in the reminder settings is the one you're actually watching. Teams with similar names (#frontend-reviews and #frontend-review) make this embarrassingly common.

Once the app is in the channel, don't wait for the schedule. Run the test in Step 5 immediately. If the test post appears, you've found the cause. If it doesn't, the channel wasn't the problem, so carry on to the schedule.

Step 3: Check the configured days, times and timezone

A reminder that works perfectly can look broken because it fires at a time you aren't watching. Before you assume the integration is dead, read the schedule back as a skeptic.

Open the reminder and check three things:

• Days. Confirm the weekdays you selected. A reminder set for Monday to Thursday will never fire on Friday, and a team that reviews on Fridays will conclude it's broken.

• Time. Confirm the time is what you intended, including AM versus PM if the picker uses a 12-hour clock.

• Timezone. This is the one that causes real confusion. A reminder scheduled for 09:00 in one timezone lands at a very different local hour for a distributed team. If your maintainer set it from a laptop in London and your reviewers sit in New York, the post may have arrived at 04:00 their time and scrolled out of view by the time anyone looked.

A concrete example: a reminder set for "9:00" while the team assumed local time in Berlin, but configured against a US timezone. It did fire. It fired six hours later than expected, after the stand-up where it was supposed to prompt reviews. To the team it looked like it never sent.

Don't move on to the filter logic until you've ruled out the schedule. It costs thirty seconds to check and an hour to chase the wrong theory. If the schedule is right, note the next fire time, and use the test in Step 5 to avoid waiting for it.

Also remember that a reminder only posts when there is something to report. A correct schedule combined with an empty result looks identical to a missed run, which is exactly what Step 4 addresses.

Step 4: Check whether any open PR survives the eligibility filters (repos, drafts, review requests, approved PRs, minimum age and staleness, ignored and required labels)

This is the most common reason a healthy reminder posts nothing. The reminder is configured, authorized, reachable and on schedule, and still silent, because every open pull request is excluded by a filter. No matching PRs means no post.

Walk through each filter and ask whether it removes everything you expected to see:

• Repositories. Reminders cover only the repos in scope. If the stuck PR lives in a repo that isn't selected, it will never appear. Confirm the repo is included.

• Drafts. Draft pull requests are commonly excluded. If your team keeps work in draft for a long time, the reminder will skip it. That may be right, but check it's deliberate.

• Review requests. If the reminder is limited to PRs where a review has been requested from your team, a PR with no review request attached is invisible to it. A PR that was opened for "anyone" and never assigned can fall straight through.

• Approved PRs. Approved pull requests may be filtered out on the assumption they only need merging. If your open PRs are all approved and waiting on a merge, the reminder will be empty.

• Minimum age and staleness. If you set a minimum age of, say, three days, a PR opened yesterday doesn't qualify yet. Teams that merge fast can easily end up with no PR old enough to remind about, so the channel stays quiet because the process is working.

• Ignored labels. A label like wip or do-not-review on every open PR removes them all.

• Required labels. The reverse trap: if a required label is set and your PRs aren't tagged with it, nothing matches. Required labels are strict. A PR missing the label is out.

Take one specific PR you expected to see and trace it through every filter until you find the one that excludes it. Loosen that single filter, then rerun the test in Step 5.

If you also route PRs by label elsewhere, the same hygiene applies. See how to route GitHub PRs and GitLab MRs to Slack channels by label for keeping label conventions consistent so filters don't surprise you.

Step 5: Run a controlled test with the reminder UI and read the result

Stop waiting for Monday. The reminder UI has its own test control, and it's the fastest way to confirm whether a fix worked. Use it after every change, one change at a time.

The loop is simple:

1. Make one change (authorize the workspace, invite the app, correct the timezone, loosen one filter).

2. Trigger the reminder's test from the reminder settings.

3. Read what happened, then decide the next move.

People skip the third part, which is reading the result. There are three outcomes, and each one points somewhere different:

• A post appears in the channel. The pipeline works end to end: authorization, channel and filters are all fine for what the test selected. If your scheduled run was still silent, the schedule or timezone is the remaining suspect, so go back to Step 3.

• No post, and the test reports that nothing matched. The connection is fine and the filters are excluding everything. Go to Step 4 and loosen one filter at a time, retesting after each.

• No post and an error or no delivery. The problem is upstream of the filters. Revisit authorization (Step 1) and channel reach (Step 2). The private channel without /invite @github is the most likely culprit.

Here's a worked example. A team of eight saw nothing for two weeks. Test run one: no post, nothing matched. They found a required label that no PR carried, removed it, and reran the test. A post appeared. That single controlled test turned a two-week mystery into a ten-minute fix.

One caution: a successful test post proves the delivery path and the current filter set. It doesn't prove your real PRs will qualify at the scheduled time. After a good test, glance at the actual open PRs once more to confirm at least one would survive the filters on a normal day.

Posted but no @mention or push: /github signin and Slack notification settings

If the reminder posts into the channel but nobody is pinged, you have the second symptom, and none of the steps above will help. The delivery works. The identity linking or the notification settings don't.

Two separate causes produce this, and they need separate fixes.

The GitHub account is not linked to Slack. The reminder can only mention people it can map to a Slack user. If a reviewer never connected their accounts, the post names them as plain text or skips the mention. The fix is for each affected person to run:

/github signin

in Slack and complete the sign-in. Then rerun the test from Step 5. A linked account turns plain text into a working mention. Tell the whole team, not just the one person who complained, because unlinked accounts are usually a pattern.

Slack notification settings swallow the ping. Even with a working mention, the person may never get a push. Check, in Slack:

• Channel notification preferences. If the channel is muted, a mention may still show in the sidebar without a push, depending on the person's settings.

• Do Not Disturb and notification schedules. A post at 09:00 won't buzz a phone set to silent until 10:00.

• Per-keyword and mention settings in preferences, which can suppress mention alerts.

A mention-less post is not a broken reminder. It's almost always an account link or a personal notification setting, and both take one person and one test run to verify.

If your review comments also fail to alert people, the root cause is often the same linking gap. The related walkthrough on GitHub Slack review comments not showing covers it from the comment side.

Decision flow: which symptom points to which fix

Use this as a fast lookup once you've run the test in Step 5. Find your symptom, apply the fix, retest.

Symptom: nothing ever posts, test shows an error or no delivery.

• Check authorization first. Ask an org owner to confirm the correct Slack workspace is authorized (Step 1).

• Then check the channel. If it's private, run /invite @github (Step 2). Confirm it wasn't renamed, archived or converted.

Symptom: test works, scheduled run is silent.

• Reread days, time and timezone (Step 3). The reminder may be firing at an hour you aren't watching, or not on the day you expect.

Symptom: test says nothing matched.

• Trace one expected PR through the filters (Step 4): repos, drafts, review requests, approved PRs, minimum age, ignored labels, required labels. Loosen one at a time and retest.

Symptom: post appears but nobody is pinged.

• Have each person run /github signin in Slack, then check channel mute, Do Not Disturb and mention settings.

Symptom: post appears, mentions work, but the list looks wrong.

• This is a filter problem again. Review which PRs the filters include and exclude, particularly minimum age and review-request rules.

The order matters because the checks go from broad to narrow. Authorization and channel access gate everything. The schedule decides when. The filters decide what. Account linking decides who gets pinged. Skipping ahead wastes time, since a perfect filter set can't overcome a channel the app can't reach.

If you find yourself rerunning this checklist every quarter, the cause is usually process, not tooling: ownership of the Slack authorization is unclear, or label conventions drift. Fix that and the symptoms stop recurring.

Conclusion

Most missing reminders trace back to one of four plain causes: an unauthorized workspace, a private channel without the app, a schedule you misread, or filters that exclude every PR. Run them in that order and use the test control after each change. You stop guessing and start seeing results.

If you'd rather not maintain scheduled digests plus filter logic just to keep reviews moving, try MergeMe. GitHub scheduled reminders send a Slack message at a specified time listing open pull requests awaiting review, and real-time alerts are limited to selected events.