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!

[Germán Morales _ Hiera]

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 !