GitHub Slack Label Filters Not Working? Checks and Fixes

A label filter on a GitHub subscription fails quietly. You typed the command, the app confirmed it, and then the channel stayed empty, or it kept filling with things you thought you had excluded. Nothing tells you which of the possible causes bit you.

The short version: inspect the channel's subscription feature list with /github subscribe list features, check the label string character by character (spaces, case, quotes), and remember that the official GitHub app for Slack supports one required label filter per repository subscription. Those three checks explain most cases.

This guide covers the official GitHub app for Slack only. Every command below follows GitHub's current customize notifications documentation, and none of it needs a custom webhook or any code. You will work through five numbered checks in order, then finish with how to remove a filter without wrecking the rest of your subscription. One promise we will not make: that applying or fixing a label replays earlier events. It does not, and Step 5 shows how to test properly.

Short answer: three things to check first

Before reading further, run these three checks in the affected channel. They take under two minutes.

First, run /github subscribe list features and read the output. It shows which features the channel is subscribed to for each repository, and whether a label filter is attached. If the output doesn't show the filter you thought you set, the filter isn't there, and no amount of staring at the label will help.

Second, compare the label in the command to the label on the repository, character by character. A label named priority:HIGH is not priority:high in your head, and a label named needs review with a space is not needs-review. Labels with spaces or special characters need quotes.

Third, count your filters. The official app supports one required label filter per repository subscription. If you added a second filter to the same repo, you didn't get two filters. You replaced the first.

If none of these explain it, read Steps 4 and 5. The remaining causes are about what labels filter at all, and about timing: a label filter applies to events that happen after you set it, not to events that already passed.

A useful frame: this is a three-link chain. The subscription has to exist, the filter has to match the label exactly, and the event has to be the kind of event labels apply to. Break any link and the channel stays quiet. The steps below test the links in that order.

Step 1: Run /github subscribe list features and read what the channel actually has

Start with the channel, not the repository. Slack channels are where subscriptions live, so a filter set in #backend tells you nothing about #frontend.

In the channel where notifications should appear, run:

/github subscribe list features

The output lists the repositories the channel is subscribed to along with the features enabled for each, such as issues, pulls, commits, releases, deployments and workflow activity. If a label filter is attached, it appears next to the repository entry.

Read it with three questions in mind:

• Is the repository listed at all? If not, the channel was never subscribed (or the subscription was removed), and the label filter is irrelevant.

• Is pulls or issues among the features? A label filter narrows items that exist for a feature. If you subscribed to commits only, there are no labeled items to filter.

• Does the filter text match what you typed? Copy it out of the output and compare it to the label on GitHub's repository label page.

Two common findings here. One: the subscription exists but only with default features, because the filter command was run in a different channel. Two: the filter is present but spelled differently than the real label, which is Step 2.

Do this step first, every time. Guessing at label quoting while the subscription itself is missing wastes an hour. The feature list is the ground truth for what the official app will do in that channel, and it's the first thing anyone helping you debug will ask to see.

If the repository is private and the list shows nothing even for an unfiltered subscribe, jump to the private-repo section near the end before returning here.

Step 2: Check the label string, spelling, spaces and quoting (+label:"priority:HIGH")

The documented syntax adds a label filter to a subscription with a +label: prefix:

/github subscribe owner/repo pulls +label:"priority:HIGH"

The quotes matter. The documentation's filter examples show labels containing colons like priority:HIGH wrapped in double quotes, though common special characters are supported. A multiword label looks like this:

/github subscribe owner/repo issues +label:"needs review"

Simple labels such as bug work without quotes, but quoting everything is a safe habit because it costs nothing.

Now the failure modes, in order of how often they cause trouble:

• Case and spelling drift. The label on the repo is priority:HIGH, and someone types priority:high or priority: HIGH. Open the repository's Labels page and copy the exact name.

• A trailing or doubled space. A label renamed from needs review to needs review (two spaces) looks identical in the GitHub UI and fails to match a typed single space.

• Curly quotes. Pasting a command from a document or chat app can turn straight quotes into curly ones. Slack then sends characters the app doesn't treat as quote delimiters. Retype the quotes by hand.

• Renamed labels. If the repository label was renamed after you created the subscription, the old filter text no longer matches anything. Check the feature list from Step 1 against the current label name.

• Emoji or special characters in labels. Copy the label verbatim rather than retyping it.

After correcting the string, rerun the subscribe command and then /github subscribe list features again to confirm the stored filter is what you intended. Don't trust the confirmation message alone. Read the list.

Step 3: Remember one label filter per repo, and a new one replaces the old

This is the check that surprises people who already use label routing elsewhere. The official GitHub app supports one required label filter per repository subscription. It doesn't accept a list.

The practical consequences:

• Running a second subscribe command with a different +label: for the same repository in the same channel replaces the earlier filter. You end up with one filter, the newest one.

• There's no documented way to ask for "label A or label B" in a single subscription. Comma-separated matching, which you may have seen in other tools or in GitLab's integration, isn't GitHub app behavior, so don't paste a GitLab-style rule here. Our GitLab label filter guide covers that platform separately.

• If you want two different label streams, the straightforward pattern is two channels: one subscribed with +label:"bug", another with +label:"security". Each channel holds one filter per repo.

Here's a before and after that shows the trap:

/github subscribe acme/api pulls +label:"priority:HIGH"
/github subscribe acme/api pulls +label:"needs review"

After the second command, /github subscribe list features shows needs review as the filter. priority:HIGH is gone. Anyone who expected both to apply is now missing every high-priority PR that lacks the needs review label.

The fix is a decision, not a command. Pick the one label that matters most for this channel, or split the work across channels. If you want five labels in one channel, the channel is doing two jobs.

Finally, if the channel goes silent after someone else touched the subscription, assume a replaced filter until proven otherwise. The feature list from Step 1 settles it in seconds.

Step 4: Know what labels do and don't filter (issues and PRs versus workflow, deployment and commit traffic)

A label is metadata on an issue or a pull request. That's the whole scope. If a feature produces events that aren't issues or pull requests, there's no label for the filter to match against.

Label filters affect issues, pull requests, comments, and reviews. The features it doesn't narrow are things like:

• commits, which are pushes to branches

• workflows (GitHub Actions run results)

• deployments

• releases

If your channel is subscribed to workflow or deployment activity for the repo and you expected the label filter to quiet it, it won't. Those events don't carry the pull request's labels as a filter condition, so they follow the subscription's feature settings, not your +label:. Our post on GitHub Actions Slack notifications on workflow failure explains how that traffic is controlled instead.

This cuts in both directions, and it explains two opposite complaints:

• "My label filter is not filtering." Check whether the unwanted messages are issue and PR activity (a filter problem) or workflow, deployment and commit messages (a feature selection problem). The fix for the second is disabling the feature, not tweaking the label.

• "My label filter hides everything." Check whether the items you expected actually carry the label. A pull request without the label is correctly excluded, even if it's important.

Also watch for events that happen before the label exists on the item. If a PR opens at 9:00 and is labeled at 9:10, the opening event happened while the item had no label. The documentation for the filter describes what is matched, so read it for the exact trigger behavior rather than assuming either outcome. We make no guarantee that a labeling action surfaces earlier activity in the channel.

Step 5: Test a fresh eligible event in a test channel, without expecting replay

Don't debug by waiting for the next real event. Create one on purpose, in a channel where a mistake costs nothing.

Here's a safe test plan:

1. Create a private test channel such as #github-label-test and invite the GitHub app if needed.

2. In the test channel, subscribe to a low-traffic repository with the exact filter you want to verify:

/github subscribe owner/test-repo pulls +label:"priority:HIGH"

1. Run /github subscribe list features and confirm the repo, the pulls feature and the filter all appear as intended.

2. In GitHub, open a fresh pull request (a one-line change in a scratch branch is enough) and apply the label. Then open a second PR without the label.

3. Watch the channel. You should see activity for the labeled PR and not for the unlabeled one. Allow a short delay, because Slack delivery isn't instantaneous.

Two cautions keep this test honest.

First, a test channel keeps your production subscription untouched. A new subscribe for the same repo in the same channel overwrites its filter, so running experiments in the production channel can quietly change what production receives.

Second, don't expect replay. Changing a filter or adding a label doesn't retroactively post notifications for events that already occurred. If a PR was opened yesterday and you fix the filter today, the way to confirm the fix is a new eligible event, not the old one. Treat any tool or guide that promises otherwise with suspicion.

If the labeled test PR produces nothing even with a clean filter, remove the label filter from the test subscription and try a plain pulls subscription. If that's also silent, the problem isn't the filter. It's access or installation, covered next.

Subscribe versus unsubscribe: removing a label filter without losing features, and when to check private-repo access

Subscribing in the official app is additive. Running /github subscribe owner/repo pulls enables the pulls feature on top of whatever the channel already had for that repo. It doesn't claim to switch everything else off, so don't assume enabling one feature changes your other features, and don't assume it leaves them alone either. Read the result with /github subscribe list features afterward.

Removing a filter is where people get nervous. The documented route is unsubscribe with the same label expression:

/github unsubscribe owner/repo +label:"your label"

That targets the label filter. Be careful with the shorter form /github unsubscribe owner/repo, which removes the repository subscription from the channel entirely. Use the narrow command when you only want to drop the filter, and check the feature list afterward to confirm the other features you wanted to keep are still there. If a feature went missing, re-add it with a normal subscribe command.

After any change, run the list command once more. It's the cheapest verification there is.

If an unfiltered subscription still produces nothing for a private repository, stop adjusting labels. The cause is then access, not filtering: the GitHub app generally needs to be installed on that repository and the Slack account connected to GitHub with permission to see it. Work through Fix GitHub Slack Private Repo Notifications first, then come back to label filters. A filter can't fix a subscription that can't see the repository.

One last note on a community question you may find while searching: forum threads and bot replies are a useful hint about what other people hit, but the official documentation outranks them when they disagree.

Optional: if you want one updating card per PR in Slack

Everything above is about getting the native app to behave. If the native app meets your needs, stay with it and use the checks above.

Some teams prefer a different shape of channel: one updating card per pull request or merge request. That's what MergeMe provides, for GitHub.com, GitLab.com and self-hosted GitLab in one Slack workspace.

This is optional and separate from fixing your label filter. Finish the native checks first, because a correctly stored filter and a fresh test event will resolve most of what you're seeing. If your real complaint is channel shape rather than a broken filter, a one-card-per-PR layout is worth a look.

Conclusion

A silent label filter is a three-link chain, so test it in order: read /github subscribe list features, compare the quoted label to the repository's exact name, and confirm you only ever set one filter per repo. Then prove the fix with a fresh labeled pull request in a test channel, because old events aren't replayed.

My prediction: most label filter bug reports on the official app trace back to either a replaced filter or a typed label that differs by one character from the real one. Check those before anything exotic.

If you want to explore another layout, try MergeMe on the free Hobby plan: connect it, open a pull request, and see whether one updating card per PR gives your reviewers a cleaner channel than a filter ever will.