Build a PR Review Reminder Bot Without Coding

A PR review reminder bot built in n8n or Make takes under two hours to configure and integrates directly with GitHub or GitLab and Slack. Before this exists, PRs sit open for two days, authors nudge reviewers manually, and the release waits.

After you deploy it, targeted and contextual reminders go to the right reviewer at the right interval. The author does not have to ask, and no developer needs to write any custom bot infrastructure. This article walks through the exact build.

Key Takeaways

• Monitor at the repository level, not the PR level: Poll open PRs across the repo on a schedule rather than triggering per-PR to avoid webhook overload in high-volume repositories.
• Remind reviewers, not authors: The reminder should go to the assigned reviewer via Slack DM, not to the PR channel where it becomes background noise.
• Escalation logic is essential: A second reminder after 48 hours should go to the reviewer's team lead, not a repeat of the first message.
• Context in the reminder drives action: Include PR title, age, size (lines changed), and a direct link. Do not send just the PR number.
• Suppress reminders for draft PRs and blocked merges: Build filter logic to exclude PRs that are intentionally waiting.
• Connect to deployment timing: Pause or accelerate reminders based on upcoming deployment windows to prevent last-minute merge pressure.

Free Automation Blueprints

Deploy Workflows in Minutes

Browse 54 pre-built workflows for n8n and Make.com. Download configs, follow step-by-step instructions, and stop building automations from scratch.

Browse Blueprints

Why Do PRs Sit Unreviewed for Days, and What Does It Actually Cost the Pipeline?

Review delays are a structural problem, not a motivation problem. Reviewers deprioritise review work when it competes with feature development and there is no system-level pressure to act on pending requests.

The cost is concrete. A PR open for 48 hours blocks the downstream developer, creates merge conflict risk as the main branch moves forward, and delays the release by at least a sprint cycle.

• No system-level pressure: Without an automated trigger, review work has no deadline and gets consistently deprioritised against work that does.
• Merge conflict accumulation: Every hour a PR sits open, the main branch moves forward and the merge conflict risk grows proportionally.
• Pipeline release delays: Five open PRs across a team of eight means no one has a complete picture of what is blocking the release.
• Social friction from manual nudges: Slack DMs from the PR author create awkward team dynamics and still do not solve the structural problem.
• No visibility on compound delays: Individual delay is invisible at the team level until sprint planning reveals the accumulation.

A bot solves this without making it personal. Process automation for team handoffs addresses the same structural gap: when a human is expected to trigger the next step, the step often does not happen on time.

What Does a PR Review Reminder Bot Need to Monitor to Be Effective?

The engineering workflow automation guide covers how to think about monitoring scope before building any pipeline step, and the same principle applies here.

Before you configure any tooling, define the full set of PR state signals the bot must evaluate to produce accurate reminders.

• Open PR age: Track time elapsed since the PR was opened or since the last review activity. A comment, approval, or change request resets the clock.
• Review assignment: Identify who is specifically assigned as a reviewer, whether assignment is explicit (GitHub Assigned Reviewer) or implicit via CODEOWNERS.
• PR state filters: Draft PRs, PRs with failing CI checks, and PRs marked WIP or DO NOT MERGE must be fully excluded from all reminder logic.
• PR size signal: Large PRs with more than 500 lines changed warrant a longer review window before the first reminder fires. Reviewers need more time for substantive feedback.
• Repository and team scope: Configure the bot to operate on specific repositories and only send reminders during the reviewer's working hours in their timezone.

Getting these signals defined before building prevents the most common failure mode: a bot that fires on every open PR regardless of state and trains the team to ignore it.

How to Build a PR Review Reminder Bot — Step by Step

This section covers the exact build from GitHub API connection to Slack delivery. The PR reminder bot blueprint provides the complete n8n workflow structure. Use it alongside these steps for faster configuration.

Step 1: Connect to GitHub or GitLab and Pull Open PR Data on a Schedule

Schedule a recurring workflow to pull all open PR data and extract the fields needed for downstream filtering and reminder logic.

• Schedule trigger: Configure a Schedule Trigger in n8n to run every four hours during working hours, not continuously, to avoid unnecessary API calls.
• GitHub API call: Use the GitHub API node to call GET /repos/{owner}/{repo}/pulls?state=open&per_page=100 and retrieve all open PRs in scope.
• Fields to extract: Parse the response for PR number, title, created_at, updated_at, requested_reviewers array, draft status, labels, and additions plus deletions counts.
• GitLab equivalent: For GitLab, use the Merge Requests API with state=opened and extract the same fields using equivalent field names.
• Staging step: Store all extracted results in a temporary n8n Set node so downstream filter and classification steps have a consistent data structure to work with.

Store results in a Set node before any filtering so each downstream step receives clean, consistently named fields.

Step 2: Filter Out PRs That Should Not Receive Reminders

Apply all exclusion filters in a single node before any reminder logic runs to prevent noise from reaching the reminder tiers.

• Draft PR exclusion: Exclude PRs where draft: true. This is a must-have exclusion, not optional, and must be the first filter applied.
• Label-based exclusion: Exclude PRs with labels containing "WIP", "DO NOT MERGE", or "blocked" regardless of how long they have been open.
• No reviewer exclusion: Exclude PRs with no assigned reviewer; these need a routing fix, not a reminder, and should be flagged separately.
• Minimum age filter: Exclude PRs opened within the last 24 hours to give reviewers first-pass time before automated reminders begin.
• Filter node choice: Use an n8n IF or Filter node to apply all conditions in sequence and pass only actionable PRs to the next step.

What remains after all filters is the set of open PRs that have waited long enough and have the right state to warrant a nudge.

Step 3: Calculate Review Age and Assign Reminder Tier

Calculate how long each filtered PR has been waiting and assign it to the correct reminder tier based on elapsed time since last activity.

• Age calculation: For each filtered PR, calculate hours elapsed since updated_at, which reflects the last review activity rather than just the PR open date.
• Tier 1 (24 to 47 hours): Send the first reminder to the assigned reviewer via Slack DM with no escalation to the team lead at this stage.
• Tier 2 (48 to 71 hours): Send a second reminder to the reviewer and a separate Slack DM to their team lead flagging the stall explicitly.
• Tier 3 (72 or more hours): Send escalation to the engineering lead and add a Jira or Linear comment on the linked issue flagging the delay.
• Switch node structure: Build a Switch node with three output branches, one per tier, so each tier routes to its own message composition step.

Use updated_at rather than created_at so reviewers who left a comment do not receive a Tier 1 reminder the same day they engaged.

Step 4: Resolve GitHub Username to Slack User ID

Username resolution is the most common point of failure. Without it, targeted DMs are impossible and the bot defaults to noisy channel posts.

• Mapping table location: Maintain a lookup table in Airtable or a Google Sheet that maps GitHub usernames to Slack user IDs for every team member.
• n8n lookup query: Query the table using the reviewer's GitHub username pulled from the requested_reviewers array in the PR payload.
• Match found path: When a match exists, use the resolved Slack user ID to send a direct message via the Slack API chat.postMessage method.
• No match fallback: If no match is found, post in the team's Slack channel with an @mention rather than a DM to avoid silent failures.
• Why this matters: Without the mapping, the bot cannot send targeted DMs and defaults to channel posts that lose effectiveness within days of launch.

Keep the mapping table current whenever team members join or leave; stale entries are the most common cause of misdirected reminders.

Step 5: Compose and Send the Contextual Slack Reminder

The reminder message must include enough context to prompt immediate action without requiring the reviewer to open a separate tab to understand what is waiting.

• Block Kit message fields: Include PR title linked to the PR URL, repository name, author's name, time open formatted as "Open for 52 hours", and a size badge based on lines changed.
• CTA button: Add a single button linking directly to the PR Files Changed tab so the reviewer can start reviewing with one click.
• Escalation context note: For Tier 2 and Tier 3 messages, add: "This PR is blocking [downstream branch or linked issue]" to make the impact explicit.
• Send target: Send via the Slack API chat.postMessage method to the resolved user ID only. Do not send to the channel, and do not send to the author.
• Tier 2 and 3 recipient: For escalations, send two separate messages: one to the reviewer and one to the team lead or engineering lead, not a single group message.

Never send the same message content at two different tiers. Each escalation must look and read differently so reviewers treat it as a distinct event.

Step 6: Test and Validate Before Going Live

Cover every filter and tier scenario with test PRs before enabling the schedule trigger on live repositories.

• Draft PR test: Create a draft PR and confirm it is fully excluded with no reminder sent at any tier.
• Early PR test: Create a PR open for 20 hours and confirm no reminder fires before the 24-hour minimum threshold.
• Tier 1 test: Create a PR open for 30 hours with an assigned reviewer and confirm a Tier 1 Slack DM arrives for the reviewer only.
• Tier 2 test: Create a PR open for 55 hours and confirm both the reviewer and team lead receive separate, distinct messages.
• Tier 3 test: Create a PR open for 80 hours and confirm escalation fires with a Jira or Linear comment added to the linked issue.

Run the schedule trigger manually before enabling the time-based schedule to confirm the full workflow executes without errors across all scenarios.

How Do You Connect PR Reminders to Deployment Pipeline Timing?

Deployment notification automation already tracks pipeline events. The reminder bot can read from the same event log to adjust its urgency based on upcoming deploy windows.

The integration prevents two failure modes: reminders that fire immediately before a production deployment create rushed reviews, and reminders that ignore upcoming deploys miss the window to surface blocking PRs in time.

• Deployment calendar query: Configure n8n to query a deployment schedule from Google Calendar, a Notion database, or an Airtable record to identify when the next deploy window opens.
• Accelerated escalation: If a PR is blocking a feature scheduled for the next deployment, escalate to Tier 2 immediately rather than waiting the standard 48 hours.
• Freeze logic: Suppress all non-critical PR reminders during and immediately after a production deployment window to prevent merge pressure at the worst possible time.
• Shared event log: The deployment notification workflow writes deployment events to a shared log that the reminder bot queries when calculating urgency.

The deployment pipeline blueprint shows how to structure the shared event log both workflows can query, including the timestamp and environment fields the reminder bot needs.

How Do You Connect Reminder Context to Bug Triage Data?

An automated bug triage system that classifies severity at intake gives the reminder bot the priority signal it needs to make reminders context-aware rather than generic.

The specific scenario this solves: a PR fixes a P1 bug, but the reviewer receives a generic "open for 36 hours" reminder with no indication that a hotfix is waiting on their action.

• Issue reference extraction: Parse the PR description and branch name for Jira or Linear issue references. A branch named fix/PROJ-1234 or a PR description linking to an issue provides the lookup key.
• Priority lookup: Query the bug triage system using the issue reference to retrieve the severity tier assigned at intake. It will be P1, P2, or P3.
• Severity injection: Add the severity context to the reminder message: "This PR resolves a P1 bug reported 18 hours ago. Review is blocking the hotfix."
• No linked issue fallback: PRs with no linked issue default to the standard reminder message without modification. Do not block reminders on missing issue data.

The bug triage automation blueprint covers how to store and expose priority data that the reminder bot can query, including the field names and Airtable schema used for cross-workflow data sharing.

How Do You Avoid Reminder Fatigue, and What Escalation Logic Keeps Reminders Effective?

A bot that sends the same message repeatedly trains the team to ignore it. Long-term effectiveness depends on three specific design decisions from the start.

The core rule is non-negotiable: never send the same message twice. Each tier must be visually and contextually distinct so reviewers treat each escalation as a genuinely different event.

• Tier differentiation: Tier 1 is a standard reminder. Tier 2 flags the stall to the team lead explicitly. Tier 3 names the engineering lead and linked issue. Each message looks and reads differently.
• Snooze mechanism: Allow reviewers to respond to the Slack message with a "snooze 4h" button using Slack interactive components and an n8n webhook. This is optional but significantly improves long-term adoption.
• Working hours gate: Configure the schedule trigger to fire only between 9am and 6pm in the reviewer's timezone, looked up from the Airtable user table by Slack user ID.
• Maximum reminder cap: No PR should generate more than three automated messages. After the third, the issue escalates to a human process decision and the bot stops messaging.
• Sent reminder tracking: Log which PRs have received which reminder tier in an Airtable row or n8n static data so the workflow does not repeat tiers on each schedule run.

The tracking step is what prevents the bot from re-sending Tier 1 reminders to reviewers who already received them on the previous schedule run. Without it, a reviewer with a stalled PR receives a new Tier 1 message every four hours.

Conclusion

A PR review reminder bot built without custom code is a realistic two-hour project. The value is not just faster reviews. It is removing the social friction of manual nudges while keeping the pipeline moving on a schedule the team can predict and rely on.

Start with the GitHub API connection and the username-to-Slack mapping table. Those two pieces are the foundation everything else depends on. Get both working with test data before configuring any reminder logic, and you will avoid the most common failure modes on launch day.

Free Automation Blueprints

Deploy Workflows in Minutes

Browse 54 pre-built workflows for n8n and Make.com. Download configs, follow step-by-step instructions, and stop building automations from scratch.

Browse Blueprints

Build a PR Review Bot That Fits Your Team's Workflow and Stack

Engineering teams running PR workflows on manual nudges are accepting avoidable pipeline delays as a permanent operating condition.

At LowCode Agency, we are a strategic product team, not a dev shop. We design reminder bots that match your repository structure, escalation hierarchy, and deployment schedule rather than applying a one-size template to every team's workflow.

• GitHub and GitLab integration: We configure the API connections and schedule triggers that pull accurate open PR data for your specific repository setup.
• Username resolution setup: We build and populate the GitHub-to-Slack mapping table that makes targeted DMs possible from day one.
• Three-tier escalation logic: We implement the reviewer, team lead, and engineering lead escalation sequence with distinct message content at each tier.
• Draft and WIP filter configuration: We build every exclusion filter correctly at the start so the bot never reminds reviewers on PRs that are intentionally waiting.
• Deployment timing integration: We connect the bot to your deployment schedule so reminders accelerate before deploy windows and pause after production releases.
• Bug triage priority injection: We connect the reminder bot to your triage system so P1-linked PRs carry severity context in every message they generate.
• Reminder fatigue prevention: We implement tier tracking, working hours gating, and the three-message cap so the bot stays effective over months, not just the first week.

We have built 350+ products for clients including Coca-Cola, American Express, and Medtronic.

Our engineering automation agent development team builds bots that integrate with GitHub, GitLab, Jira, Linear, and Slack with no custom code required on your side. Scope your bot requirements with us and we will show you what a working reminder system looks like for your repository structure.