On a schedule

See pull requests waiting for your review

Each weekday morning you get a list of pull requests where your review is requested, with how long each has waited.

Runs: On a schedule
Apps: GitHub
AI: Not needed
Access: Pull requests: read

Send this to your assistant

Create a ClickRuntime automation: every weekday at 9am, Slack me the open pull requests where my review is requested, oldest first, with how many days each has been waiting.

Paste it into your assistant. It tells you what it will send or change before it runs live.

Add to ChatGPT Add to Claude

First time? Adding ClickRuntime to your assistant takes about two minutes.

Why use it

Why teams use this automation

Being requested as a reviewer on GitHub is easy to overlook. The request is a single notification, it competes with everything else in your inbox, and the author is left waiting with a finished change. A pull request that waits four days for a first review often needs rework after the target branch moves on, so the delay costs both people twice.

Each morning on the schedule you pick, open pull requests that have you listed as a requested reviewer are found using a review-requested search. They are posted as a list with each PR's title, repository and how many days it has been waiting, so the oldest ones are impossible to overlook.

It is best for senior engineers who are named on many PRs, tech leads who share a review rota and developers who want to be the reviewer nobody has to chase.

What you get out of it

No one waits on you unknowingly
The author's change stops sitting idle because it hid below newer notifications, and your teammates learn they can count on a response from you within a day. Reliability is noticed and appreciated by the whole team.
Age shows what is most urgent
Seeing how many days each request has waited puts the oldest at the top of your attention, which prevents the situation where the stalest pull request is also the one that has drifted into merge conflicts.
Reviews fit into your routine
A consistent morning list lets you plan thirty minutes for review before meetings, rather than reviewing only when guilt strikes late on a Friday. That habit beats guilt-driven bursts of rushed reviews.
Fewer pings from the author
When people trust that you see your queue, they stop sending reminder messages, which reduces interruptions on both sides and keeps the relationship friendly. Everyone gets to spend less time chasing and more time building.
Faster merges for the whole team
Shortening the first-review wait is one of the biggest levers on cycle time, so the work your team ships each week goes up without anyone working longer hours. It is a gain that shows up in every sprint.

How it works

What happens, step by step

Every weekday at 9 am, ClickRuntime finds the open GitHub pull requests where your review has been requested.
It works out how long each one has been waiting.
The list is posted to your Slack channel, with the wait time next to each pull request.

Before it runs live

Connect GitHub

What you get

RunsOn a schedule

See pull requests waiting for your reviewtoday, 9:00Succeeded

Slack · #dev3 pull requests waiting on your review: • 6d · acme/app#471 Refactor billing service

Build your own

Need it to work differently?

This template is a starting point. Copy the prompt and change it, or describe a different automation from scratch, with your own conditions, more apps or an AI step. Your assistant writes it, tests it and runs it on ClickRuntime.

Your own rules
Conditions, thresholds, filters and exceptions, written the way you'd explain them to a colleague.
Any number of apps
One automation can read from one app and update several others. Over 248 apps are ready, and anything with an API works too.
AI where it helps
Summaries, classification, extraction and drafts use ClickRuntime's built-in AI, with no extra key.
On a schedule or on each event
Runs as often as every 5 minutes, or the moment an app sends an event, and keeps track of what it already handled.

Changes you can ask for

Run it at a different time, more or less often, or only on weekdays
Add an AI step, for example to summarize, sort or draft a reply
Add another app, for example also send it to Slack
Combine it with other GitHub steps into one automation

Under the hood

The code that runs this automation

This is the Python script that runs each time the automation starts. Your AI assistant writes it for you when you send the prompt, and you allow each step in your assistant. To change how the automation works, describe the change to your assistant and it updates the script for you. For every function it can use, see the script reference.

review_requests_waiting_on_me.pyexample

from datetime import datetime, timezone
from clickruntime import on_trigger, credentials, http, notify

def gh(method, path, **kw):
    resp = http.request(method, f"https://api.github.com{path}", headers={
        "Authorization": f"Bearer {credentials.connection('github', 'work')}",
        "Accept": "application/vnd.github+json"}, **kw)
    resp.raise_for_status()
    return resp.json() if resp.content else None


@on_trigger
def run(event):
    prs = gh("GET", "/search/issues", params={"q": "is:pr is:open review-requested:@me archived:false",
                                               "sort": "created", "order": "asc", "per_page": 50})["items"]
    if not prs:
        return {"waiting": 0}
    now = datetime.now(timezone.utc)
    lines = [f"• {(now - datetime.fromisoformat(p['created_at'].replace('Z', '+00:00'))).days}d · "
             f"{p['repository_url'].split('/repos/')[1]}#{p['number']} {p['title']}\n  {p['html_url']}" for p in prs]
    notify.slack(f"{len(prs)} pull requests waiting on your review:\n" + "\n".join(lines), channel="#dev")
    return {"waiting": len(prs)}

FAQ

Common questions

Does it include reviews requested from my team?

The search looks for pull requests where you are requested directly. Team requests can be included too if you name the team, since GitHub treats them as separate review requests on the same pull request.

Does a PR disappear from the list after I review it?

Yes. Once you submit a review, GitHub no longer shows you as a pending requested reviewer, so the PR drops out of the next list. If the author requests another review later, it returns. Nothing needs to be cleaned up by hand.

Where does the list get posted?

You choose the destination, most often a direct message or a private channel in Slack. Because it is a personal list, many people keep it out of shared channels so colleagues do not see the backlog.

What permissions does it need?

Pull requests: read. Nothing else in your accounts is used.

Does it need AI?

No. It runs without AI, so it doesn't use your plan's AI allowance.

How many runs does it use?

One run each time it runs (on a schedule). Checks that find nothing to do and stop right away aren't counted.

Can I change how it works?

Yes. Describe the change to your AI assistant, for example a different schedule, channel or filter. It updates the automation, tests it and tells you what changed.

Daily