What Bitbucket automation does, and exactly where it stops
Bitbucket never set out to be an automation platform, and understanding that saves you a week of looking for features that were never there. What it does have is enforcement at the merge, and that is the part worth using properly.
You want the repository to do something on its own. Move a ticket, nag a reviewer, block a merge that has not been tested, tell you on Friday what has been sitting open all week. You have been through the settings twice and there is no automation section, so you are now wondering whether you missed a plan upgrade.
You did not. Bitbucket does not have a rules engine and never claimed one. It has three surfaces and a relationship with a tracker, and once you know which is which, the product stops being confusing. It also stops being the answer to about half your questions, which is useful information on its own.
First: which Bitbucket
This trips people up more than anything else in this article. Bitbucket Cloud and Bitbucket Data Center are different products with different automation stories, and most of what you find online does not say which one it is describing. Cloud has an integrated CI system. Data Center does not, and pairs instead with a separate build tool and a server side hook and app ecosystem that Cloud has no equivalent for.
Before you follow any instruction, including the ones below, work out which you are on. If you are self hosting it, you are on Data Center. If you sign in at a bitbucket.org address, you are on Cloud.
The three surfaces
Merge checks and branch permissions. This is the only surface that can actually stop something happening, and it is the one worth the most attention. Restrict who can push to protected branches. Require a minimum number of approvals. Require a successful build before merge. Require that review comments are resolved. Prevent merges from branches that have fallen behind.
The build requirement deserves a specific note, because it works through the commit build status mechanism rather than through any particular CI tool. Anything that can post a status against a commit can satisfy that check. That is what makes the check useful on Data Center, where the build is happening somewhere else entirely, and it is why you should not accept anybody telling you that requiring a green build needs a specific vendor’s CI.
Pipelines, on Cloud. A YAML defined build and deploy system living in the repository. This is your general purpose compute: anything you can express as a script can run on a push, on a pull request, on a schedule, or against a deployment environment with its own permissions. As with every CI system, the moment you realise it can also do non build work, a large amount of your automation backlog becomes solvable.
Webhooks. Outbound events for pushes, pull request activity and build results. This is how Bitbucket talks to anything that is not Bitbucket. It is a good, boring, reliable mechanism, and it is the correct answer whenever you catch yourself about to write a script that polls.
The tracker link, which is where the automation actually lives
If your tracker is Jira, the missing rules engine is not missing, it is on the other side of the connection. Connect the two and Jira’s automation can react to development events: a branch appearing, a commit landing, a pull request opening or merging. Bitbucket emits, Jira decides. Once you internalise that, you stop looking for rules in the wrong product.
The commit message convention that drives this is generally called smart commits: put the issue key in the message, followed by commands that act on the issue. The available commands and their exact syntax have changed across versions and between Cloud and Data Center, so read the current documentation for your deployment rather than copying a format from a blog post. The part that is stable, and the part that matters, is the issue key itself. Get the key into the branch name and the commit message and everything downstream becomes possible. Skip it and nothing does.
No conditional logic, anywhere
No conditional logic anywhere in Bitbucket. Merge checks are thresholds, not conditions. You cannot say “require two approvals if this touches the payments directory, one otherwise” through the settings. Path aware review requirements are a code owners style feature whose availability differs by deployment and version, so check yours before designing around it.
No time based anything on the source control side. Nothing native notices that a pull request has been open for six days. Cloud can approximate this with a scheduled pipeline that queries the API. Data Center users need an external job or an app.
No cross repository state. Every setting is per repository, or at best applied across a project by an administrator. A change spanning four repositories is four unrelated pull requests as far as Bitbucket is concerned, and there is no native view that treats them as one thing.
The automation depends on a tracker you may not have. This is the sharpest limit and the least discussed. All the rules engine capability described above lives in Jira. If your team uses Bitbucket with Linear, Azure Boards or Asana, that half of the story simply is not there, and you are left with webhooks and code.
Turn the merge checks on properly this week
1. Turn the merge checks on, properly, this week. Protected branches, a minimum approval count, and a required green build. This is the highest return configuration change available to you and it takes an hour. Everything else in this article is optional; this is not.
2. Make the issue key a habit, then measure it. Branch names and commit messages. Then count your linking rate: the share of merged pull requests that reference an issue at all. Below roughly nine in ten, every report you build afterwards is computed over a subset while presenting itself as the whole, which is a more expensive problem than having no report.
3. On Cloud, put your recurring logic in a scheduled pipeline. One job, one owner, narrow credentials, loud failures. Stale pull request reports, weekly digests, anything with a clock in it.
4. On Data Center, use webhooks into something small rather than polling the API. And be conservative about apps: every one you install is a thing that must be compatible before you can upgrade.
If your tracker is not Jira, and particularly if you are running several repositories against several trackers, the gap above is structural rather than a configuration you have missed. That is the case a cross tool layer covers, and since we build one it is only fair to be plain about it: GroundTruth reads Bitbucket, GitHub and GitLab on the source control side, syncs fully with Jira, Linear and Azure DevOps, and supports Asana with read plus coarse write. If you are on Bitbucket and Jira together, you already have most of what you need and should exhaust Jira automation first.
Where this breaks down
Cloud and Data Center diverge, and this article generalises. Anything specific here should be confirmed against your own deployment and version. That is not a disclaimer, it is the single most common way people waste an afternoon on this topic.
Strict merge checks slow small changes down. A one line configuration fix now needs an approval and a build. Some teams handle this with a documented exception path; others decide the friction is the point. Either is defensible, but decide it openly rather than letting people quietly discover the workaround.
A scheduled pipeline is a service. Tokens, a base image, error handling, and an owner who will eventually leave. For a lot of teams a manual Friday review is genuinely the better trade, and it is fine to choose that.
Relying on Jira for your rules couples two products. It works well until someone migrates the tracker, at which point the automation you thought lived in your repository turns out to have lived somewhere else entirely.
The strongest objection: perhaps nothing here needs automating. Bitbucket’s narrow scope irritates people who wanted a platform. It also means there is very little to misconfigure, and teams on it tend to spend their time on review quality instead of on rule graphs. That is not obviously the worse outcome.