Hi, we are using Jira Cloud and are currently facing an intermittent issue with the Jira REST API when trying to update an existing issue from an SAP IS IFlow. The integration calls the following endpoint: https:// .atlassian.net/rest/api/3/issue/ The request sometimes fails with the following error: org.apache.camel.component.ahc.AhcOperationFailedException: HTTP operation failed invoking ... with statusCode: 500 The response contains the following relevant headers: * HTTP status: 500 Internal Server Error * Atl-Request-Id: available, can be provided privately to Atlassian Support * Atl-Traceid: available, can be provided privately to Atlassian Support * Date: Wed, 27 May 2026 around 12:07 UTC * X-Cache: Error from cloudfront * Server: AtlassianEdge The response body seems to be very short and does not provide a meaningful error message. It is also strange that the call does not fail consistently, but only once or twice per day. Both the request body and the HTTP call have been checked, and neither seems to be different in the failed calls compared to successful calls. Has anyone seen similar intermittent HTTP 500 responses from Jira Cloud when updating an issue via: /rest/api/3/issue/{issueIdOrKey} Any hints on how to identify the exact problem or how to further troubleshoot this? Thanks!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Api Call 500 Error

Dominik Zöbl

Hi,

we are using Jira Cloud and are currently facing an intermittent issue with the Jira REST API when trying to update an existing issue from an SAP IS IFlow.

The integration calls the following endpoint:

https://<our-site>.atlassian.net/rest/api/3/issue/<issue-key>

The request sometimes fails with the following error:

org.apache.camel.component.ahc.AhcOperationFailedException: HTTP operation failed invoking ... with statusCode: 500

The response contains the following relevant headers:

HTTP status: 500 Internal Server Error
Atl-Request-Id: available, can be provided privately to Atlassian Support
Atl-Traceid: available, can be provided privately to Atlassian Support
Date: Wed, 27 May 2026 around 12:07 UTC
X-Cache: Error from cloudfront
Server: AtlassianEdge

The response body seems to be very short and does not provide a meaningful error message.

It is also strange that the call does not fail consistently, but only once or twice per day. Both the request body and the HTTP call have been checked, and neither seems to be different in the failed calls compared to successful calls.

Has anyone seen similar intermittent HTTP 500 responses from Jira Cloud when updating an issue via:

/rest/api/3/issue/{issueIdOrKey}

Any hints on how to identify the exact problem or how to further troubleshoot this?

Thanks!

Accepted answers

Dominik Zöbl

I found the problem ->

The issue was most likely caused by using * for Request Headers and Response Headers in the SAP Integration Suite HTTP adapter. This allowed old response headers from a previous Jira call to be forwarded into the next Jira request.

We changed the configuration to use an explicit header whitelist instead.

After this change, only the required headers are passed to Jira and old response headers like Content-Length, Transfer-Encoding, Set-Cookie, or Location are no longer forwarded.

All comments

Germán Morales

Hi @Dominik Zöbl, the combination of Server: AtlassianEdge and X-Cache: Error from cloudfront tells you this 500 is coming from the CDN/edge layer, not from the Jira application itself. If the Jira backend had returned the error, you would see a structured JSON body with an error message. A short, empty-ish body from the edge layer usually means the origin didn't respond in time and CloudFront returned a 500 on its behalf.

Since it happens once or twice a day and the same request succeeds at other times, this is most likely a transient backend timeout on Atlassian's side. The fact that you already have Atl-Request-Id and Atl-Traceid from the failing calls is exactly what Atlassian Support needs to trace it through their infrastructure.

Two practical steps:

On your SAP IS IFlow side, add a retry with a short delay (5-10 seconds) for 500 responses. If the issue is a transient origin timeout, the retry will succeed. This won't fix the root cause but it keeps your integration running without manual intervention.
Open a Support ticket and include the Atl-Request-Id, Atl-Traceid, and the exact timestamp from a failing call. The edge layer logs are not visible to customers, only Atlassian Support can correlate those IDs to what happened on their end.

Dominik Zöbl

I already added a retry with your suggested values and it didnt prevent the error.

So ill try to create an Support Ticket for that case

Thanks for the help and the fast answer !

Dominik Zöbl

I found the problem ->

We changed the configuration to use an explicit header whitelist instead.

After this change, only the required headers are passed to Jira and old response headers like Content-Length, Transfer-Encoding, Set-Cookie, or Location are no longer forwarded.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud