Bitbucket Cloud pipelines: trigger variables rejected at 10,240 bytes since 2026-07-08 — intended ch

[Misha Kav]

Since ~05:00 UTC on 2026-07-08, triggering a pipeline via POST /2.0/repositories/{workspace}/{repo}/pipelines with custom variables started returning HTTP 400:

"Variables exceed the maximum allowed count or total size. Maximum count: 50, Maximum total size: 10240 bytes."

...for requests that succeeded fine before that time. Nothing changed on our side.

What's confusing:

- The 10,240-byte total-size limit contradicts the documented limits — the Variables and secrets page states 100 KB for shared variables and 120,000 chars per custom value. 10 KB appears nowhere in the docs.

- It's a hard, clean cliff: requests whose combined variable values are 10,240 bytes or less succeed; above 10,240 bytes they fail 100% of the time (verified across hundreds of triggers).

- Onset was sudden and hit many separate workspaces at the same time.

- No matching entry in the developer changelog.

Questions:

1. Was the total-size limit for API-trigger variables intentionally reduced to 10,240 bytes? If so, where is it documented?

2. If not intentional, is this a known regression, and is a fix/rollback planned?

[Gabriela]

Hi Misha, this looks like a regression on Atlassian's side, not anything you changed. The docs put the ceiling for custom pipeline variables at 350 variables and 512 KB combined, with 120,000 characters per value (https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/). The 50 count and 10,240 bytes you're now hitting are well below that. The 50 also happens to match the shared-variable limit, so it reads like the trigger endpoint started applying the wrong cap around July 8.

Whether that's an intentional but undocumented tightening or a bug is something only Atlassian can confirm. I'd open a support ticket quoting that 350 / 512 KB doc against the 400 you're getting, and keep an eye on status.atlassian.com and the Bitbucket changelog. A clean threshold appearing across multiple workspaces at once with no changelog usually points to a rollout or a regression on their end.

To get unblocked now, stop shipping the big payload as trigger variables. Pass a small reference instead, like a commit SHA, an artifact name, or a lookup key, and have the first step pull the real payload from an artifact, a repo file, or wherever it lives. Trigger variables are built for a handful of small values, so anything past a few KB is safer fetched inside the run. That keeps you under the cap wherever Atlassian lands on this.