Stale Pull Requests: How to Set Up PR Reminders in Slack (GitHub, GitLab, Bitbucket)

A stale pull request is one that has sat open without review or activity for longer than your team considers normal. The fix is rarely a new policy. It is a reminder that reaches the right people, in the place they already read, before the pull request goes cold.

This guide explains what makes a pull request stale, how to set up GitHub Slack pull request reminders with the built-in tools, what GitLab and Bitbucket offer, where those options run out, and how to set thresholds that get pull requests moving without flooding a channel.

What Is a Stale Pull Request?

There is no universal definition. In practice, a pull request is stale when it is open, not a draft, and nothing has happened on it for longer than your team's expected review time. "Nothing" usually means no review, no new commits and no reply to the last comment. On GitLab the same idea is called a stale merge request; the problem is identical.

Stale pull requests usually fall into a few groups:

• Waiting for a first review. Nobody has looked at it. This is the most common and the easiest to fix.
• Waiting on the author. Review comments were left and the author has moved on to something else.
• Approved but not merged. Everyone agreed, and nobody pressed the button.
• Abandoned. The work is no longer needed and the pull request should be closed.

Why stale pull requests cost more than they look

A pull request that waits three days doesn't just add three days to delivery. The author switches context and has to reload it later. The branch drifts from the default branch and picks up merge conflicts. Other work that depends on it stalls. Review time is one of the biggest components of cycle time, which is why it shows up in every serious set of engineering metrics and in the lead time part of DORA.

The problem is growing as AI coding agents open more pull requests. Agents can produce changes faster than people can review them, so the review queue is where work piles up.

GitHub Pull Request Reminders in Slack

GitHub has a built-in answer: scheduled reminders, delivered through the GitHub integration for Slack. The broad steps are:

1. Install the GitHub app in Slack and connect it to your GitHub organization.
2. Create a scheduled reminder in your organization's settings (for the whole organization) or in a team's settings (for team scheduled reminders). Organization owners and team maintainers can set these up.
3. Choose the Slack channel and schedule, for example weekday mornings at 9:30.
4. Set filters, such as which repositories to track, whether to ignore draft or already-approved pull requests, and how old a pull request must be before it is included.

Individual developers can also turn on personal scheduled reminders, which message them directly about pull requests where their review is requested. Separately, the GitHub app for Slack can subscribe a channel to repository events, so new pull requests and reviews are posted as they happen.

For a single team working on GitHub only, this is a good starting point and costs nothing extra. Exact menus change over time, so follow GitHub's own documentation on scheduled reminders for the current steps.

"Dismiss Stale Pull Request Approvals" Is Something Else

Search for stale pull requests on GitHub and you'll run into a branch protection setting called dismiss stale pull request approvals when new commits are pushed. Despite the name, it isn't about old pull requests.

When it's enabled, any approval on a pull request is dismissed as soon as someone pushes a new commit to it. The change has to be approved again before it can merge. "Stale" here means the approval no longer matches the code. It's a useful safeguard against changes slipping in after review, and it can actually create more stale pull requests if reviewers aren't told that their approval was reset. If you turn it on, make sure your reminders include pull requests that need re-approval.

GitLab and Bitbucket Options

GitLab: stale merge requests

GitLab's Slack integration posts notifications to a channel when events happen, such as a merge request being opened, commented on or merged. Reviewers also see assigned merge requests in their GitLab to-do list. For reminders about merge requests that have gone quiet, teams typically write a small script against the GitLab API that runs on a schedule (for example as a scheduled pipeline) and posts a list to Slack, or use a third-party bot.

Bitbucket: stale pull requests

Bitbucket Cloud's Slack integration is also event-driven: it notifies a channel or a person when a pull request is created, reviewed, commented on or merged. A Bitbucket stale pull request reminder usually means an Atlassian Marketplace app or a scheduled script using the Bitbucket REST API. Our Bitbucket analytics guide covers the metrics side in more detail.

Limits of Built-in Reminders

Built-in options work well for a single team on a single provider. They start to strain when:

• You use more than one provider. Each integration is configured separately, with its own rules and its own message format. There is no single view of everything that is waiting.
• Event notifications become noise. A channel that receives every opened, commented and merged event quickly gets muted, and then the important message is muted too.
• The same pull request is repeated every day. Without control over how often a finding repeats, a reminder list turns into wallpaper.
• Staleness is only one risk. You may also want to know when a pull request was merged without any reviewer, or when an AI agent's pull request has been waiting on a human. Most reminder tools don't look for those.

A Cross-Provider Approach with Gitmore Alerts

Gitmore alerts apply one set of rules to all your connected repositories, whether they live on GitHub, GitLab or Bitbucket. You choose from these rules:

• Stale pull requests: open pull requests that have gone quiet past your threshold.
• AI-agent pull requests waiting on a human: pull requests from coding agents that nobody has reviewed yet (see how to measure AI coding agents).
• Pull requests merged without a reviewer.
• AI-share spikes: a sudden jump in the share of work written by AI agents.
• Dormant repositories: repositories that have stopped seeing activity.

How it behaves:

• Alerts go to a Slack channel or to email.
• Rules are checked hourly, and findings are batched into one message rather than one message per pull request.
• Each finding repeats only after an interval you set, so the same pull request doesn't appear every hour.
• You can preview what a rule would flag before you enable it.
• Alerts don't use AI credits and are available on every plan (see pricing).

Best Practices for Pull Request Reminders

Set thresholds from your own data

Look at your current median time to first review before picking a number. If it is two days, a 4-hour threshold will flag almost everything and the channel will be ignored. Start slightly above your median, then tighten it as the team improves. Exclude drafts, and consider a longer threshold for large pull requests.

Route reminders to the people who can act

Send reminders to the team channel that owns the repository, not to a company-wide #engineering channel. A reminder that reaches everyone is owned by no one. For on-call or release-critical repositories, a dedicated channel with stricter thresholds works well.

Agree on a review SLA

Reminders work best when they enforce something the team already agreed to. A simple service level, such as "first review within one working day", gives the reminder a purpose and makes it easy to discuss misses in a retrospective or sprint report.

Batch, don't stream

A single digest at the start of the day is read. Twenty individual pings are not. Keep real-time notifications for events people need to react to at once, and send everything else as a batched list.

Make each reminder actionable

A good pull request reminder answers four questions at a glance, so nobody has to click through to find out whether it concerns them:

• What is it? Repository and pull request title, with a link.
• How long has it waited? Age since the last meaningful activity, not since it was opened.
• What is it waiting on? A first review, the author, a re-approval or simply a merge.
• Who can unblock it? The requested reviewers or the owning team.

Sort the list by age so the oldest pull requests are at the top, and keep it short. If a digest regularly lists more than ten items, the threshold is too tight or the team has a capacity problem that reminders alone won't fix.

Close what is abandoned

A reminder list full of pull requests nobody intends to merge trains people to ignore it. Make closing abandoned pull requests part of the routine; they can always be reopened.

Keep pull requests small

Small pull requests get reviewed faster, which means fewer reminders in the first place. A clear pull request template also helps reviewers start quickly.

Frequently Asked Questions