GitHub Slack Notifications After Repository Transfer

An engineering team moves an internal repository from a personal account into their main GitHub organization. Local git pull and git push keep working because GitHub redirects the old URL. Then an engineer opens a pull request, and Slack stays quiet. The team channel expects review alerts. Nothing arrives.

A repository transfer changes administrative boundaries, permissions, and app installations. Git remote operations survive via automatic redirects, but webhook routing and third-party integrations don't always follow. Teams assume the chat integration broke silently or that GitHub wiped their webhook configs. Usually the cause is organization-level app authorization, repository access scopes, or a channel subscription pointing at an old handle.

Fixing GitHub Slack notifications after a repository transfer takes a structured validation pass, not guess-and-check slash commands. Verify what GitHub preserved, update the destination organization's app permissions, and prove delivery with a controlled test.

What changes (and what doesn't) when a GitHub repository changes owner

A repository transfer doesn't delete existing webhooks or integration configs, but it does change who governs them. Transfer old-org/repo-a to new-org/repo-a and GitHub leaves the repository's webhook definitions intact. Secrets, target endpoints, and active flags carry over to the destination organization unchanged.

GitHub Apps, though, answer to the owning account. If your Slack integration connects via a GitHub App installed on old-org, that installation loses authority over the repository the moment the transfer completes. The repository now falls under new-org and its installation policies. If new-org doesn't have the app installed, or restricts it to specific repositories, event dispatching stops immediately.

Repository permissions also reset to the target organization's defaults. Team access lists from the old organization disappear unless teams with identical names exist in the target. When access tightens, especially on private repositories, integrations often lose read permissions. As covered in our guide on GitHub Slack integration private repository notifications, permission changes block bot read access entirely. The repository exists and the webhooks fire, but the integration can't inspect metadata for the new owner.

Before the transfer: record owner, repo, channel and subscription state

Never start a repository transfer without a baseline snapshot of your Slack subscriptions. Open your Slack workspace and run slash commands to document settings across every team channel that receives alerts.

Run /github subscribe list in each relevant channel. Record the exact channel names, repository paths, and configured filters such as pulls, issues, or commits. Engineering teams often route code review alerts to #eng-reviews and deployment notices to #releases. If you use MergeMe to post notifications as one updating card per PR across GitHub.com or GitLab projects, check your channel mappings in the dashboard before you transfer.

Next, record the current webhook delivery history in GitHub repository settings under Settings > Webhooks. Note the latest 200 OK delivery IDs and response payloads. If you need to troubleshoot failed deliveries later, you'll want to compare event headers from before the move against post-transfer payloads.

Finally, write down collaborator logins and team handles tagged in review workflows. When a repository moves, CODEOWNERS rules referencing teams like @old-org/core-devs fail silently if that team doesn't exist in the destination. The pre-transfer snapshot takes five minutes. It saves hours of wondering why a channel went quiet.

After the transfer: confirm the target organization's app installation and repository scope

The most common failure after a transfer is an uninstalled or unscoped GitHub App in the destination organization. Once GitHub completes the move, log into the target organization as an administrator. Go to Organization Settings > GitHub Apps or Installed GitHub Apps, then find your Slack integration.

If the target organization already uses the app, inspect its repository access configuration. Many organizations restrict integrations to 'Only select repositories' instead of 'All repositories'. With select repositories, newly transferred repositories are excluded by default. Edit the app installation, add the transferred repository to the approved list, and save.

Third-party app restrictions are another roadblock. If the target organization enforces them, an organization owner must explicitly grant access before the integration bot can query repository metadata. Without that grant, GitHub drops the API requests the bot makes. Confirm these grants before you run any configuration commands inside Slack.

Re-check the subscription against the new canonical owner/repo

GitHub redirects web traffic from old-org/repo-a to new-org/repo-a, but Slack bot subscriptions shouldn't rely on legacy path aliases. Subscriptions tied to the old namespace often stop receiving events.

Open the target Slack channel and run /github subscribe list to see active bindings. If the output shows the legacy path, unsubscribe with /github unsubscribe old-org/repo-a. Then subscribe to the canonical location with /github subscribe new-org/repo-a.

Re-apply your custom event subscriptions and feature filters. If your channel previously listened only for pull request reviews and comments, restore those flags with /github subscribe new-org/repo-a pulls,reviews,comments. Teams with complex notification streams across many channels often end up with routing clutter. Review patterns to route GitHub repos and GitLab projects to the right Slack channels and keep review alerts clean.

If you manage subscriptions through an external platform like MergeMe, update the connected repository identifier to the new organization slug. MergeMe shows pull request notifications as one updating card per PR/MR, so there's no thread clutter when repository handles shift.

Run a test PR through the full lifecycle, including filters

A branch push or a static status check doesn't prove pull request alerts are being delivered. Only a full review cycle confirms the integration works under the new organization.

Create a temporary branch on the transferred repository, commit a trivial change, and open a test pull request against the default branch. Watch the designated Slack channel. Check that the initial pull request card appears and shows the new organization namespace.

Next, assign a reviewer and post a review comment. Confirm the review notifications reach Slack without delay. Then test your event filters. If you configured the subscription to ignore draft pull requests, convert the test PR to draft and verify Slack suppresses duplicate notices. Mark it ready for review again.

Finally, submit an approval, merge the pull request, and delete the feature branch. Confirm the Slack card reflects the merged state without spawning fragmented messages. If the test PR never shows up at the first step, check the webhook delivery tab under Settings > Webhooks. A 403 Forbidden or 404 Not Found points straight at missing organization permissions or an outdated repository slug.

Why a working Git URL redirect doesn't prove Slack delivery

Engineers often assume the integration works because git fetch and git push succeed after a transfer. It doesn't follow. Git network transport and application event delivery run on completely separate infrastructure.

GitHub keeps backward-compatible Git and HTTP redirects for transferred repositories. When your local client connects to github.com/old-org/repo-a.git, GitHub redirects internally or handles ref negotiation behind the scenes. That redirect exists so CI pipelines and local clones don't break right away.

Slack notifications run on an event-driven webhook pipeline and GitHub App API scopes. When an engineer opens a pull request, GitHub generates an event payload carrying the canonical repository owner (new-org). The webhook dispatcher sends that JSON payload to the integration endpoint. If the integration's authorization token is tied only to old-org, or the endpoint rejects payloads with mismatched owner identifiers, delivery fails silently.

Git operations verify routing to the Git object database. Slack notifications depend on webhook dispatching, API authorization tokens, payload verification secrets, and bot channel membership. A working remote origin tells you nothing about whether chat notifications work.

A short post-transfer validation checklist

Run this five-step audit in order to keep notifications stable across your team:

1. Audit app installation: Confirm the Slack app is installed in the target GitHub organization and explicitly authorized for the transferred repository under organization settings.

2. Clean legacy subscriptions: Run /github unsubscribe old-org/repo in every engineering channel that tracked the old repository slug.

3. Subscribe canonical path: Run /github subscribe new-org/repo [features] in the designated alert channels and check your custom event flags.

4. Validate bot permissions: Make sure the Slack bot user is a member of the channel (especially private channels) so it can post messages.

5. Complete end-to-end PR test: Open a pull request, request a review, submit an approval, and merge, checking that the notification card updates cleanly in Slack at each stage.

The checklist takes under ten minutes per repository. Skip it and unreviewed pull requests can sit in notification blind spots for days.

Conclusion

Repository transfers don't have to disrupt engineering velocity or silence your review workflows. When GitHub Slack notifications fail after a transfer, the cause is usually an organization permission boundary, not a deleted config. Run the audit, refresh your channel subscriptions, and confirm your apps hold valid installation scopes.

If your team reviews code across both GitHub and GitLab, juggling separate bots and noisy alert feeds is wasted effort. MergeMe connects GitHub.com, GitLab.com, and self-hosted GitLab to Slack, showing pull requests and merge requests as one updating card per PR/MR. Start with MergeMe's free Hobby tier (1 channel mapping and 5 user mappings), or move to the Team plan at £5 per dev seat monthly to keep your code review notifications organized and reliable.