Bitbucket Pipelines monitoring
Bitbucket Pipelines monitoring across every workspace
Pipeline runs, DORA metrics, and flaky tests across every Bitbucket workspace and repo, plus build-minute burn-down so the 50-min per-user allowance never surprises you. Two-minute setup. Atlassian-stack friendly.
Repos across 3 workspaces · sorted by last pipeline
Works across every major CI/CD provider
Pipelines · DORA · Flaky tests
Beyond the Pipelines tab
Three capabilities every CI/CD Watch tenant uses, each wired into how Bitbucket Pipelines reports data. Same JSON sources Bitbucket uses, lifted into views the Pipelines tab does not offer.
Pipelines, every workspace, one feed
The Pipelines tab works for one repo. Multiple workspaces break it.
Every pipeline run across every workspace, every repository, in one live feed. Filter by status, workspace, repo, branch, or deployment environment. Drill straight back into the Bitbucket pipeline page when you need the raw logs.
- Live via efficient API polling, conditional-request aware against Bitbucket's 1,000/hr per-IP rate limit
- Build-minute spend per workspace shown on every row, including used-vs-allowance against your tier's monthly cap
- Each row links straight to bitbucket.org/<workspace>/<repo>/pipelines/results/<id>
Outcome: one tab replaces fifty, with build-minute spend visible at a glance.
What's needed: OAuth or app password. Nothing in your bitbucket-pipelines.yml changes.
Pipelines across 3 workspaces · live
DORA, from Bitbucket Pipelines data
Deployment environments give the cleanest DORA signal of any provider.
DORA metrics calculated from real pipeline run data, including 2024's Rework Rate. Bitbucket Pipelines is the only provider where deployment environments are a first-class config primitive. Steps declared with deployment: are treated as deploys to that environment, with no extra rules needed.
- deployment: production and similar steps auto-tagged, no detection rules needed
- Custom pipelines (custom:) and PR pipelines distinguished from main
- Trend over 7 / 30 / 90 days, per-repo or aggregated, with period-over-period regression alerts
Outcome: DORA defensible because the deploy signal is unambiguous in YAML.
What's needed: OAuth or app password. If you use Bitbucket's deployment: keyword, auto-detection covers you.
DORA by repo · 30 days · ranked by deploy frequency
Flaky tests, surfaced via the test-reports convention
Bitbucket already parses test-reports/. We surface every flake.
Bitbucket Pipelines automatically discovers JUnit XML in the test-reports/ directory. If your test runner already writes there, no config is needed. Each test gets a flip rate, failure rate, and current status so the most disruptive ones surface first.
Convention-over-config: write to test-reports/
script:
- mkdir test-reports
- npm test -- --reporter junit \
--reporter-options output=test-reports/junit.xml- Per-test flip rate scored across branches over a rolling 30-day window
- Failure rate and current status per test, sortable in the table
- Parallel-step tests merged correctly when parallel: is configured
Outcome: fix the disruptive tests first, with real flip-rate data to triage them.
What's needed: JUnit XML in test-reports/. Bitbucket's native convention, nothing custom.
Flaky tests, last 30 days, sorted by flip rate
Same connect, more depth
How we work with Bitbucket Pipelines
Three more capabilities the same connect unlocks. None of them are Bitbucket-only, but each pays off particularly well on Bitbucket estates where per-user minute allowances, explicit parallel config, and deployment environments all shape the bill.
Cost
Cost-optimization opportunities ranked by potential saving
Right-sizing recommendations, redundant-step detection, and waste categorisation. Each opportunity shows what to change and the annualised saving for taking the action.
Audit
Audit rules catch CI/CD hygiene gaps across the estate
Built-in rules check for missing lint, no unit tests, absent SAST, secrets-in-config patterns, and more. Findings ranked by severity; each one names the repo and the fix.
Strategy
Branching strategy auto-detected per repo
Trunk-based, GitFlow, GitHub-flow detected from your real branch and merge patterns. DORA metrics get a per-strategy lens so trunk-based repos aren't penalised for not having long-lived release branches.
All from one connect
Plus the rest of the toolkit
The three capabilities above are what you'll use most. Same connect also gives you cost tracking, PR health, stability classification, performance ratings, security insights, Slack, CLI, and an MCP server. No extra integrations.
Cost tracking →
Build-minute spend plus developer wait time. Waste auto-categorised by type. Team tier.
PR health →
Per-repo CI failure rates, reviewer wait time, and PR-to-deploy latency. Team tier.
Stability classification →
Every pipeline auto-classified healthy, flaky, or broken. Trend detection on each.
Performance ratings →
Per-pipeline performance scoring across the estate. Spot the slow outliers.
Security insights →
Per-repo security-scan detection rolled up across the estate. Business tier.
Slack notifications →
Pipeline failures, regressions, and degradation alerts in your team channel. Team tier.
CLI →
Query pipeline status, costs, and DORA from your terminal. Pipe it anywhere.
MCP server →
Hook Claude, Cursor, or any AI agent into live pipeline state.
Pricing
Flat per tenant
Start free for one team. Team and Business tiers are flat monthly rates per tenant. Enterprise is custom for organisations needing SSO, audit logging, and security review.
Free
For one team getting started with up to 3 repos.
- 3 repos
- 1 team member
- Pipeline runs, DORA, flaky tests
- Build-minute view (last 30 days)
- Email support
Team
Flat rate per tenant. Up to 20 repos and 10 team members.
- 20 repos
- 10 team members
- Everything in Free
- Cost tracking with full history
- PR health, performance ratings
- Slack notifications, CLI, MCP server
Business
Flat rate per tenant. Up to 100 repos and 50 team members.
- 100 repos
- 50 team members
- Everything in Team
- Audit findings and cost-optimization opportunities
- Priority support
Comparison
How CI/CD Watch compares
A 10-person team running Bitbucket Pipelines across ~20 repos. Headline pricing only; deeper feature comparisons live on the linked pages.
CI/CD Watch$29 / mo flat (Team) | ||||
|---|---|---|---|---|
| Pipeline run monitoring | Live cross-workspace feed | Yes | Limited | Yes |
| Build-minute burn-down tracking | Yes, per workspace | No | No | No |
| DORA metrics from CI data | All five, auto-detected | Add-on | Yes | No |
| Cost tracking (compute + wait time) | Yes, with wait time | Compute only | Wait time only | No |
| Pricing model | Flat per tenant | Per committer + spans | Per contributor | Flat tiers |
| Setup time | ~2 min OAuth | Agent install per repo | OAuth + config | ~5 min |
Competitor pricing reflects each vendor's published headline rate. See the linked comparison pages for fuller feature matrices and verified sources.
~2 min
to connect via OAuth or app password
0
agents to install in your runners
5
DORA metrics from day one
Flat
per-tenant pricing
FAQ
Bitbucket Pipelines specifics
- How is this different from Bitbucket's native Pipelines tab?
- Bitbucket's Pipelines tab is per-repo. CI/CD Watch is the cross-workspace, cross-repo view: one feed across every workspace, DORA aggregated, flaky tests sortable, build-minute burn-down per workspace. Each row links back to the Bitbucket pipeline page.
- Will it eat into our build minutes?
- No. CI/CD Watch reads from Bitbucket's API after pipelines complete. It does not trigger pipelines, install runners, or consume build minutes. The polling is rate-limit-aware and stays comfortably under the 1,000/hr per-IP ceiling using conditional requests.
- How does it handle the per-user build-minute allowance?
- We surface used-vs-allowance per workspace so you see the burn-down before you hit the wall. Bitbucket's Free tier gives 50 build minutes per active user per month; Standard and Premium have larger caps. CI/CD Watch shows the current spend, the projected end-of-month total, and which repos are driving consumption.
- What if we use the deployment: keyword in our pipelines?
- Auto-detection covers you. Bitbucket Pipelines is the only provider with first-class deployment environments in YAML, which means DORA can read the deploy signal directly from your config. No name-matching or branch heuristics needed.
- How does it integrate with Jira and the wider Atlassian stack?
- Jira issue keys are parsed automatically from branch names and commit messages. PR-to-issue and deploy-to-issue traceability work without extra config. You stay inside Atlassian; we just lift the pipeline data into a cross-product view.
- How long does setup take?
- Around two minutes. OAuth into Bitbucket Cloud (or paste an app password if your workspace has OAuth restricted), pick which repos to include, and the first pipeline feed populates within minutes.
- Is pricing tied to build minutes or seats?
- Neither. CI/CD Watch is flat per tenant: $0 Free, $29 Team, $99 Business per month. Repo and team-member caps differ per tier; consumption inside those caps is unmetered.
- Bitbucket Cloud only, or Server too?
- Bitbucket Cloud only. Bitbucket Server / Data Center is end-of-life as of February 2024; new connections target Cloud workspaces. Mixed estates running Server alongside Cloud should connect the Cloud side here and let the Server side wind down.
- Can we get DORA metrics across Bitbucket Pipelines and GitHub Actions?
- Yes. Connect each provider separately; DORA metrics include runs from every connection. Useful for mixed estates mid-migration where part of the team is on Bitbucket Pipelines and part has moved to GitHub Actions.
More on CI/CD monitoring
Read, compare, or get started
Blog
What are DORA metrics and why should you track them?
The four (now five) signals from DORA Research that measure how well a software team delivers. What each one means and how to read them.
Guide
Deployment detection
Auto-detection from the deployment: keyword. Configure named rules for custom pipelines or non-default branches.
Guide
Audit
How CI/CD Watch audits your pipelines for missing tests, missing lint, and other CI/CD hygiene gaps.
Blog
Flaky tests: what they are, why they happen, how to fix them
Practical patterns for catching flaky tests early, ranking them by impact, and clearing them without halting feature work.
Blog
The true cost of CI/CD: compute, wait time, and waste
Compute is half the bill. Developer wait time is usually the bigger half. The taxonomy of CI/CD cost and where the waste lives.
Blog
CI/CD monitoring: beyond watching pipelines go green
What estate-level CI/CD monitoring should actually surface, and where most dashboards stop short.
One tab replaces fifty.
Connect Bitbucket Pipelines in two minutes. Pipeline runs, DORA, and flaky tests across every workspace, with build-minute burn-down.