Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Bitbucket Server build status API returning 500 for commits(worked earlier without any Jenkins chang

Amulya Kota
May 5, 2026

Hi everyone,

We are using the Bitbucket Server REST API to post build statuses to commits from our Jenkins pipelines:

Endpoint:
POST /rest/api/latest/projects/{projectKey}/repos/{repoSlug}/commits/{commitId}/builds

This has been working fine earlier, but recently we started getting 500 Internal Server Error consistently, even though there were no changes on the Jenkins side.

Verified:

  • Authentication (Bearer token) is valid
  • Request payload is correct (state, key, name, url)
  • Commit exists and is accessible via GET /commits API
  • Same issue occurs from Jenkins and manual API calls (PowerShell/Postman)

Example:

POST https://<bitbucket>/rest/api/latest/projects/C/repos/code/commits/<commitId>/builds
Body: state=INPROGRESS, key=TEST-123, name=TEST, url=https://test

Response:
500 Internal Server Error with message: “An error occurred while processing the request”

Additional notes:

  • Issue is more frequent on feature branch / new commits
  • Older commits sometimes still work
  • Retry attempts do not resolve the issue

Questions:

  1. Are there known conditions where Bitbucket cannot attach build status to certain commits (e.g., indexing delay or commit reachability)?
  2. Has there been any recent change in this API behavior?
  3. Which server logs should we check to diagnose this?

Environment: Bitbucket Server (self-hosted), Jenkins pipelines.

1 answer

0 votes
Aron Gombas _Midori_
Community Champion
May 7, 2026

A 500 error on the build status API with no changes on the Jenkins side almost always points to something changing on the Bitbucket Server side.

As the very first thing to do, check the Bitbucket Server logs. The most important log is "BITBUCKET_HOME/log/atlassian-bitbucket.log". The 500 response you see is a generic internal server error, but the server log will contain the full stack trace with the actual root cause. Look for entries around the timestamps of your failed requests.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events