Skip to content

On a schedule

Get a morning list of pull requests waiting too long

Every weekday you see which pull requests have been open for more than three days, so reviews do not stall.

Runs
On a schedule
Apps
Bitbucket
AI
Not needed
Access
read:pullrequest

Send this to your assistant

Create a ClickRuntime automation: every weekday at 9am, email me the Bitbucket pull requests in our acme workspace that have been open more than 3 days, oldest first, with the author and repo.

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

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

Why use it

Why teams use this automation

Pull requests that nobody reviews are a quiet tax on engineering teams. A branch opened on Monday with a bug fix for a customer waits for a reviewer who thought someone else had it. By Thursday it has merge conflicts, the author has moved on to another task and context is lost. In Bitbucket nothing flags the pile of pull requests quietly aging in the repository.

Every morning ClickRuntime lists the open pull requests in your repository, keeps those whose created_on date is more than three days old and emails you a single list with titles, authors and links. If nothing is stale, there is nothing to chase and the email can say so.

Engineering managers and tech leads use it to run a short, regular review of what is stuck instead of relying on stand-up reminders.

What you get out of it

  • Reviews stop going stale

    A daily list of pull requests older than three days puts pressure on the oldest work first. Branches get reviewed before they drift far from the main branch. Nothing sits unreviewed long enough to become someone else's problem, and the oldest requests are raised first.

  • Fewer painful merge conflicts

    Short-lived pull requests merge cleanly. Surfacing stuck ones early prevents the Friday afternoon rebase of a two-week-old branch. Short-lived pull requests are also easier to review properly, because the diff is small and fresh in everyone's mind, so quality improves along with speed.

  • Authors are not left waiting silently

    A developer who opened a pull request and heard nothing can feel ignored. A visible list gives reviewers a prompt and gives authors confidence that someone will look. Morale improves when contributors see that waiting work is noticed, particularly for newer engineers or outside contributors.

  • A simple measure of review health

    Seeing the same names or repositories appear week after week shows where review capacity is short. A manager can rebalance work using actual evidence. Reviewing that pattern monthly can guide hiring or rotation decisions.

  • Releases ship with fewer surprises

    Pull requests stuck behind the release date are visible days earlier. The team can decide to merge, split or drop them instead of finding out at deploy time. Planning is calmer when blocked work is known early.

How it works

What happens, step by step

  1. Every weekday at 9, ClickRuntime looks at the open pull requests in your Bitbucket repositories.

  2. It keeps the ones that have been open for more than three days.

  3. You get an email listing each one with its repository, title, author and how many days it has been waiting.

Before it runs live

  • Connect Bitbucket

What you get

RunsOn a schedule
Get a morning list of pull requests waiting too longtoday, 9:00Succeeded
Email · Stale PRsweb-app #81 Migrate auth to OAuth2 by Alex Kim (9 days) api #137 Add CSV export by Sam Patel (4 days)

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 Bitbucket 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.
get_a_daily_digest_of_stale_open_prs.pyexample
from datetime import datetime, timedelta, timezone
from clickruntime import on_trigger, credentials, http, notify

BB = "https://api.bitbucket.org/2.0"

def bb(path, **params):
    resp = http.get(f"{BB}{path}", headers={"Authorization": f"Bearer {credentials.secret('BITBUCKET_TOKEN')}"}, params=params)
    resp.raise_for_status()
    return resp.json()

@on_trigger
def run(event):
    cutoff = datetime.now(timezone.utc) - timedelta(days=3)
    stale = []
    for repo in bb("/repositories/acme", pagelen=100)["values"]:
        for p in bb(f"/repositories/acme/{repo['slug']}/pullrequests", state="OPEN", pagelen=50)["values"]:
            opened = datetime.fromisoformat(p["created_on"])
            if opened < cutoff:
                stale.append((opened, f"{repo['slug']} #{p['id']} {p['title']} by {p['author']['display_name']} "
                                      f"({(datetime.now(timezone.utc) - opened).days} days)"))
    if stale:
        notify.email_me(f"{len(stale)} pull requests open over 3 days", "\n".join(line for _, line in sorted(stale)))
    return {"stale": len(stale)}

FAQ

Common questions

How does it decide a pull request is stale?
It compares each open pull request's created_on timestamp with the current time and keeps those older than three days. Activity is not considered, so a pull request with recent comments still appears if it was opened long ago.
Can I change the threshold from three days?
Yes. The three days is just a number in the filter, and a different value such as five days or one week works the same way. Tell your AI assistant the number and approve the updated workflow.
Does it cover every repository in my Bitbucket workspace?
It checks the repository you configure. You can add several repositories so one email covers them all. Access depends on the Bitbucket credential, which needs permission to read pull requests in those repositories. Private repositories need that read access granted.
What permissions does it need?
read:pullrequest. 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.

Set up “Get a morning list of pull requests waiting too long” from your assistant

Copy the prompt above, or connect your assistant first. Free plan, no credit card.