Opsphere
← All articles

Bitbucket: What It Is, How It Works and How to Investigate Incidents

Bitbucket: What It Is, How It Works and How to Investigate Incidents

Abstract code-to-production incident investigation illustration

Bitbucket is Atlassian’s Git-based platform for hosting code, reviewing changes, running CI/CD and connecting that work to Jira. This guide covers how it is organized, how Pipelines behaves, what the Cloud and Data Center options mean for operations, and how to connect Bitbucket activity to production evidence when something breaks.

Opsphere
Connect Bitbucket Changes to Operations
Opsphere brings Bitbucket activity alongside cloud, Kubernetes and observability context to help teams investigate incidents from one interface.
Explore Opsphere

TL;DR

  • What it is: Bitbucket is Atlassian’s Git code-hosting and collaboration platform. Teams use it to store code, review changes, run automated tests and deploy.
  • How it is structured: workspaces contain projects, projects contain repositories, and pull requests are where review happens.
  • The operational gap: Bitbucket knows what changed. It does not know what your clusters, cloud accounts and observability tools saw afterward. During an incident, you have to bridge that gap yourself.
  • Next step: keep Bitbucket as your source of truth for code, and add a read-only operational layer such as Opsphere’s Bitbucket integration so commits and pull requests can be investigated next to deployments, Kubernetes and telemetry.

Table of Contents

What Bitbucket is and what teams use it for

Bitbucket is a hosted Git service owned by Atlassian. According to Atlassian’s overview, teams use it to store and manage source code, review changes, run automated tests and deploy software. Its integrations with Jira and Trello expose branches, commits and build status on the issue or card that the work belongs to.

In practice, most teams pick Bitbucket for three reasons:

  • Jira alignment. If planning already happens in Jira, linking branches and pull requests to issues is a default behavior rather than a project.
  • Built-in CI/CD. Pipelines ships inside Bitbucket Cloud, so a small team can build and test without standing up a separate CI server.
  • A choice of hosting model. Cloud is hosted by Atlassian, and Data Center is self-managed.

None of that makes Bitbucket an operations tool. It is a system of record for code and review. That distinction matters later in this article, when production is on fire and the question is no longer “what did we merge?” but “which of the things we merged is hurting us?”

How workspaces, projects, repositories and pull requests fit together

The hierarchy is simple once you see it laid out.

Level What it is Why it matters
Workspace The place where users create repositories, collaborate on code and organize streams of work Access, billing and team structure hang off it
Project A group of related repositories Lets you organize services by product or team
Repository Each repository belongs to a user account or a workspace, and a project can hold one or many The unit of code, branches and history
Pull request The place where review happens The record of why a change was made and who approved it

The pull request workflow

Atlassian describes the typical flow as creating a feature branch, pushing it to Bitbucket, opening a pull request, discussing and changing the code, then merging it. A pull request compares changes from a branch or fork, lets authors request reviews, and shows build status before merging.

For incident work, the pull request is the most valuable artifact Bitbucket produces. It holds the diff, the discussion, the reviewers and the build result in one place. When a regression shows up, the pull request is usually where the explanation lives.

The pull request workflow — overview diagram

Getting started: workspace, repository and first clone

If you are new to the platform, the setup path is short.

  1. Create the account and workspace. Create or join an individual Bitbucket account, then go to admin.atlassian.com, add Bitbucket, name the workspace and agree to the terms, as described in Atlassian’s workspace guide.
  2. Create a repository. Choose Create, then Repository, set the access level, select Git as the version-control system and create it, following the repository guide.
  3. Clone it. Copy the HTTPS or SSH clone command, run it locally and authenticate when prompted, per the clone guide.
  4. Open a branch and a pull request. Make the first change on a feature branch so the review path is in place before the team grows.

One habit pays off later: name branches and write pull request titles so they reference the ticket or service. That metadata is what lets anyone, human or tool, connect a change to its operational effect months afterward.

Bitbucket Pipelines: the CI/CD layer

Pipelines is Bitbucket Cloud’s integrated CI/CD service. It is configured in a bitbucket-pipelines.yml file and supports Docker-based build environments, variables, caches, artifacts, parallel steps, deployments and runners.

What triggers a pipeline

Pipelines can start on pushes to any branch, selected branches, pull request creation or updates, Git tags, or manual triggers. Scheduled runs are supported too.

That flexibility is useful, and it has an operational side effect: the trigger you choose determines what your release history looks like. A pipeline that deploys on a merge to main produces a clean, one-to-one mapping between merges and deployments. A pipeline that deploys on tags or manual triggers breaks that mapping, and you will need to reconstruct which commit went out when.

Build minutes and plan limits

Atlassian’s limits page lists, for the plans it cites, 50 build minutes per month on Free, 2,500 on Standard and 3,500 on Premium, with Git LFS allowances of 1 GB, 5 GB and 10 GB respectively. Check that page for current figures before you plan capacity, because plan terms change.

Bitbucket plan limits for minutes and LFS

If you are extending pipelines beyond build and test, for example to gate releases of AI-driven features, a walkthrough of CI/CD eval gates for AI shows how a prompt change can be treated like any other change that must pass a check before it ships.

Cloud, Data Center and what to plan for

Atlassian’s overview states that Bitbucket Cloud is hosted on Atlassian’s servers and includes built-in Pipelines, while Data Center is self-managed on a single server or a cluster for scale and high availability. Atlassian’s pricing page frames the tradeoff this way: Cloud is a managed SaaS offering with built-in security, compliance and ongoing updates, and Data Center gives you control over infrastructure, data, upgrade timing, availability and performance.

Is Bitbucket being deprecated?

No. Bitbucket Cloud is an active product. The lifecycle dates that matter apply to self-managed deployments:

  • Atlassian says its Data Center products reach end of life on March 28, 2029, and that Bitbucket Data Center customers can keep their footprint and access Cloud innovations with the Bitbucket Hybrid license.
  • Bitbucket Server licenses ended support on February 15, 2024, and the final Server-compatible feature release was Bitbucket 8.14.

If you still run Server, that is a migration planning item today. If you run Data Center, treat the 2029 date as the horizon for deciding between Cloud and the hybrid path.

From an operations view, migration changes more than hosting. Webhooks, service accounts, deployment variables and any tooling that reads from Bitbucket must be re-pointed. Inventory those integrations early, because they are the pieces that fail quietly after a cutover.

How Bitbucket connects to the rest of your toolchain

Out of the box, Bitbucket’s strongest connection is to Jira and Trello. Beyond that, Atlassian’s developer documentation says Cloud integrations can use Forge apps, REST APIs and Pipelines pipes, and that the REST APIs can read and update entities such as commits and pull requests. Atlassian recommends Forge for secure, scalable apps, with OAuth 2.0 and API or access tokens as authentication options.

Those building blocks make it possible to push events out of Bitbucket. What they do not provide is a view that combines a pull request with the Kubernetes rollout, the cloud change and the alert that followed. That view is an operational problem, not a source control problem.

The blind spot: code activity without operational context

Consider a familiar scenario. Latency rises on a checkout service at 2:10 p.m. The on-call engineer has several questions, and each lives in a different tool:

  • Which deployments happened in the last few hours? (CI/CD and the cluster)
  • Which pull requests were merged into those releases? (Bitbucket)
  • Did the infrastructure change, such as a scaling event or a config update? (cloud console, Terraform state)
  • Which alerts fired, and in what order? (observability)
  • Who owns the service and the change? (repository, ticketing)

Answering them means opening five tabs and holding a timeline in your head. Under pressure, teams anchor on the first plausible suspect, usually the most recent merge, and a correct-looking answer gets accepted before the alternatives are tested.

Investigating production regressions with Bitbucket as evidence

The repository is the best source for “what changed,” provided you use it in a structured way. A reliable sequence looks like this:

  1. Fix the time window. Mark when the symptom started, using telemetry rather than the first human report.
  2. List deployments inside and just before the window. Include application releases, infrastructure changes and configuration changes, not only code.
  3. Map each deployment to commits and pull requests. This is where Bitbucket history and release records are joined.
  4. Read the pull requests, not only the diffs. Review discussion often records known risks, skipped tests or follow-up work.
  5. Test more than one hypothesis. A code change, a dependency update, a traffic shift and an infrastructure change can all explain the same graph.
  6. Confirm with runtime evidence. Check whether the suspect change touched the component that is actually misbehaving, using pod events, logs and metrics.
  7. Record the finding. Link the pull request, the deployment and the evidence in the incident record so the next responder starts ahead.

Steps 2, 3 and 6 are where time disappears, because they cross system boundaries.

What to look for in pull requests

  • Changes to configuration, feature flags or environment variables, which often cause regressions without touching application logic.
  • Dependency and base image updates bundled into otherwise small changes.
  • Merges that skipped or overrode a failing build status.
  • Changes to infrastructure code that live in the same repository as application code.
  • Large pull requests with thin review discussion.

Reviewing release history

Release history is the join table between code and production. If your pipeline deploys on merge, each deployment maps to a merge commit. If you deploy on tags or manual triggers, record the commit SHA in the deployment metadata, so a responder can go from a running version to a pull request without guessing. This is a cheap practice with a large payoff, and it works regardless of tooling.

Where Opsphere fits

Opsphere does not replace Bitbucket and does not ask you to move repositories, reviews or pipelines. It acts as the operational intelligence layer that connects Bitbucket repositories, commits, pull requests and code changes with deployments, cloud infrastructure, Kubernetes and observability signals, so an investigation can follow a symptom to a change and back.

The design principles matter for enterprise teams:

  • Read-only by default. Opsphere reads operational context. It is not a path for changing your repositories or your clusters unless you deliberately enable that.
  • Your tools stay the source of truth. Opsphere connects to existing tools without requiring replacement and without duplicating telemetry.
  • Evidence-backed investigation. Findings are tied to the underlying data, and hypotheses can be tested in parallel instead of one at a time.
  • Governed access. The security model is a first-class part of the platform, which matters when an AI agent is reading across AWS, Kubernetes and source control.

The same approach is described for another source control system in tracing incidents to code changes in GitHub, and the Bitbucket workflow follows the same logic: start from the production symptom, find the change, and verify with runtime evidence.

Workflows teams run with Bitbucket context

  • Production regression triage. Start from an alert, list recent changes across code and infrastructure, and rank suspects against the evidence.
  • Pull request to incident correlation. Check whether a merged pull request touched the service that is failing, and who reviewed it.
  • Release review. Compare what was merged against what was deployed, to spot changes that shipped unintentionally or did not ship at all.
  • Repository activity and operational impact. See whether a burst of commits to a service lines up with instability, to guide where to invest in tests.

For teams that want to query this from where they work, Opsphere exposes its tools through the MCP operational gateway, and the platform engineering use case shows how it applies to shared infrastructure.

Try the Bitbucket integration

If your team already runs code review and CI/CD in Bitbucket, the fastest way to shorten investigations is to give responders one place to see code changes beside operational evidence. Opsphere offers a Community plan at €0 per month and a Developer plan at €19 per month, and a Team plan at €500 per month. See the pricing page for what each includes, or start with the Bitbucket integration.

Opsphere

START FREE TRIAL from the pricing page, or BOOK A 20-MIN DEMO to walk through a Bitbucket-to-incident investigation on your own stack.

Decision criteria: do you need more than Bitbucket alone?

Bitbucket by itself is enough when your system is small, deployments are infrequent and one or two people know every service. Add an operational layer when you see these signs:

  • Incident timelines are reconstructed manually from several tools.
  • Responders ask “what changed?” before they ask “what is broken?”
  • Postmortems repeatedly cite missing context across repositories, clusters and alerts.
  • You are adopting AI agents or MCP and need governed, read-only access to operational data.
  • Several teams own services in different repositories, and nobody sees the combined release picture.

A useful measure is time to first credible hypothesis during an incident. If it depends on who is on call, the context is stored in people instead of systems.

FAQ

What is Bitbucket used for?

Bitbucket hosts Git repositories and supports code review through pull requests, CI/CD through Pipelines and work tracking through Jira and Trello. Teams use it to manage source code from first commit to deployment.

How do I create a workspace in Bitbucket?

Create or join an individual Bitbucket account, then go to admin.atlassian.com and add Bitbucket. Name the workspace and agree to the terms. After that you can create repositories inside it.

Is Bitbucket being deprecated?

No. Bitbucket Cloud remains an active product. Self-managed options have dates to track: Bitbucket Server support ended on February 15, 2024, and Atlassian lists March 28, 2029 as the end-of-life date for its Data Center products.

Can Opsphere replace Bitbucket?

No, and it is not meant to. Bitbucket remains where code, reviews and pipelines live. Opsphere connects that activity with deployments, cloud infrastructure, Kubernetes and observability signals, and is read-only by default.

Sources

Opsphere
Discuss Your Bitbucket Operations
Contact Opsphere to discuss bringing Bitbucket activity together with cloud, Kubernetes and observability context for incident investigation.

This article is provided for general informational purposes only and does not constitute professional, legal, security, or compliance advice. Please evaluate recommendations against your organization’s specific environment and requirements.