Weekday Slack nudges for stale Bitbucket pull requests

Every weekday at 9am, help me nudge reviewers about stale Bitbucket pull requests by posting one grouped message to our engineering Slack channel. The point is to keep review latency low without pinging people individually all day. Bitbucket has no native "remind reviewer" feature, so this workflow fills that gap.

Start by listing open pull requests across the Bitbucket repositories we track using the List Pull Requests operation. It defaults to OPEN, and pagelen caps at 50, so page through when a repo has more than that. Narrow the query with the BBQL q parameter filtering on updated_on so we only look at PRs that have been idle for more than two business days, for example q=updated_on<"2026-07-10T00:00:00Z". Bitbucket pull request states are always uppercase (OPEN, MERGED, DECLINED, SUPERSEDED).

For each candidate, skip pull requests authored by a bot account, and skip pull requests where a reviewer already has a changes-requested state on their review, because those are correctly stalled on the author and not on the reviewers. For everything that survives, call the List Pull Request Activity operation on the pull request to walk the log of approvals, updates, and comments so you can identify which listed reviewers still owe a review (they have not approved yet, and they have not just been handed a new revision to react to).

Once you have a per-reviewer picture, assemble one grouped Slack message and post it to the engineering channel using the Slack Bot Send a Message operation. Open the message with a bulleted line per pending reviewer using their Slack handle where you can resolve it ("@alice - 3 PRs waiting on you", "@bob - 1 PR waiting on you"), then list each stale pull request as a short human-readable line with title, author, how long it has been waiting, and a link to the PR. Slack messages use mrkdwn (*bold*, _italic_, <url|text> for links), not standard Markdown, so format links accordingly. When you know a reviewer's Slack user ID, use the <@USERID> mention syntax so the message actually pings them; fall back to a plain @handle display when you do not.

Post exactly one grouped message per run. If nothing qualifies on a given morning, skip the post rather than sending an empty ping. Only run on weekdays - the cron schedule should already enforce that.

Additional information

What does this prompt do?

Every weekday morning, checks the Bitbucket repositories you track for open pull requests that have been sitting idle for more than two business days
Skips pull requests authored by bots, and skips pull requests where a reviewer has already requested changes (those are correctly on the author, not the reviewers)
Reads each remaining pull request's activity to work out which reviewers still owe a review
Posts one grouped Slack message to your engineering channel with a bulleted per-reviewer summary and a short line per pull request (title, author, age, link)

What do I need to use this?

A Bitbucket workspace and a login that can see the repositories you want to track
A Slack workspace with a channel for engineering announcements
Permission to install a bot in that Slack channel so it can post the nudge

How can I customize it?

Change the schedule (default is 9am on weekdays) or the time zone
Adjust the staleness threshold (default is more than two business days without an approval)
Point it at a different Slack channel, or split by repository group so mobile and platform each get their own nudge

Frequently asked questions

Does this DM people individually?

No. It posts one grouped message to a shared channel with a per-reviewer bullet summary. Individual DMs every morning tend to feel like noise and get muted, which defeats the point.

Will it nag reviewers on pull requests that already have changes requested?

No. Changes-requested pull requests are correctly waiting on the author to update, so the workflow skips them.

What about pull requests opened by our own automation bots?

Pull requests authored by bot accounts are skipped, since nudging humans about bot-owned PRs usually is not the goal.

How does it decide who still owes a review?

For every candidate pull request it walks the activity log (approvals, updates, and comments) so a reviewer who has already approved, or who has already been given a new revision to react to, can be treated appropriately.

Can I run it at a different time or more often?

Yes. It is a scheduled workflow, so you can move it to a different time of day, extend it to weekends if your team ships then, or run a lighter afternoon reminder as a second copy.

Additional information

Frequently asked questions

Related templates