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.
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
Every weekday at 9, ClickRuntime looks at the open pull requests in your Bitbucket repositories.
It keeps the ones that have been open for more than three days.
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
Build your own
Need it to work differently?
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
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?
Can I change the threshold from three days?
Does it cover every repository in my Bitbucket workspace?
What permissions does it need?
Does it need AI?
How many runs does it use?
Can I change how it works?
Related
You might also like
Get a weekly pull request report per repo
Each Monday you see how many pull requests were opened, merged and declined in every repo last week, and by whom.
See how it worksGet an email when a Bitbucket build fails
As soon as a pipeline or build fails, you get the commit and the pull request it belongs to.
See how it worksPost new Bitbucket pull requests to Slack
Each newly opened pull request shows up in your team channel with its author and reviewers.
See how it worksKeep exploring
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.