Repository archiving in Bitbucket Cloud 8.12: evaluating storage‑cost impact for low‑traffic workloads

Answer to the exact question

The precise percentage reduction in storage cost for an archived repository is not published by Atlassian. For the majority of Bitbucket Cloud workspaces (Standard and Premium plans) storage is billed per user seat, not per gigabyte, so archiving a repository does not change the storage charge. Only workspaces that have purchased an Enterprise storage add‑on (or a custom Enterprise agreement) may see a reduced rate, and the exact discount varies by region and the specific contract.

Confirmed facts

• Archiving a repository switches it to read‑only: git pushes, pull‑request creation/merges, and Pipelines execution are blocked.
• Read‑only state suppresses webhook events that are triggered by write actions (push, pull‑request opened, merge, etc.). Read‑only actions such as clone or fetch still fire the appropriate read‑only webhooks if they are configured.
• Merge‑check integrations become ineffective because the merge operation cannot be performed on an archived repo.
• The repository’s history, tags, branches, and metadata remain accessible for reading via the UI, Git, or REST API.

Likely explanation (based on typical billing models)

If your workspace uses a seat‑based plan, the storage component of the invoice is flat; therefore archiving yields no measurable cost saving. If you have an Enterprise storage add‑on, Atlassian applies a lower per‑GB rate for archived data, but the exact percentage is not disclosed publicly and must be derived from your contract or a pricing quote.

Steps to determine the impact for your workspace

1. Open Workspace settings → Billing → Plan and note whether you are on Standard, Premium, or Enterprise.
2. If Enterprise, check if a Storage add‑on is enabled; if not, storage is still seat‑based.
3. For Enterprise with storage add‑on, consult your billing agreement or contact Atlassian sales to obtain the archived‑storage discount percentage for your region.
4. To verify the read‑only behavior, attempt a git push to an archived repo; you should receive a remote: error: GH006: Archived repository (or similar) response.
5. Confirm that a clone or fetch succeeds, showing that read access is preserved.

Missing diagnostic detail that would change the recommendation

Please confirm your current Bitbucket Cloud plan (Standard/Premium/Enterprise) and whether you have a storage add‑on enabled. This information determines whether archiving will affect your storage bill.

Effect on webhook‑driven workflows and merge‑check integrations

• Webhooks that listen for push, pullrequest:opened, pullrequest:merged, or similar write‑related events will no longer receive payloads from an archived repository.
• Webhooks configured for read‑only events (e.g., repository:updated on metadata changes, or repo:refs_changed from a fetch) continue to fire, but they do not convey write activity.
• Merge‑check plugins or APIs that evaluate a pull request before merge become moot because the merge operation cannot be initiated on an archived repo.

Hidden costs or operational overhead when reviewing/unarchiving

• Periodic review requires manual or scripted checks of repository activity (e.g., last push timestamp) to decide when to unarchive.
• Unarchiving restores full write access; any automation that was disabled must be re‑enabled and tested.
• There is no extra storage fee for the archived state itself, but the labor involved in monitoring, ticketing, and executing the archive/unarchive cycle represents an operational overhead.
• If you rely on audit logs for compliance, ensure that the archive/unarchive actions are retained; otherwise you may need to export logs before archiving.