Investigating error 500 from Stride API after some time of app running


Hi there,

lately (for about 2-3 weeks), my apps Joint Rooms (client ID ORX3qke3kOFy9XZa1aFduL7z0TnsL0xf) and Unified Webhooks (client ID t772SB72EJ7AyIu8gsS2SuxMLLsT9677) have sometimes (once or twice a week) gone into this behavioral pattern, where they would send a message to a room or retrieve a user profile via the Stride API and get back an error 500. And this would happen to all or almost all calls to the API from that point on.

Normally I would say the API not working with error 500 is probably something the Atlassians have to worry about, but the strange thing is that after restarting the app, everything works fine again. Now, restarting the app every time this happens is obviously not a good solution, so I’ve been wondering what could cause this.

Maybe it’s a problem with the JWT? That’s really the only thing that changes at a restart (aside from the message content, obviously).

Anyway, could one of the Atlassians here please investigate this and see if there’s anything wrong on your side? I’ll improve logging on this error and see if I run into it again in the meantime.

Last timeframe that this happened: from 2018-06-27T13:22:54Z until 2018-06-28T09:26:14Z (yes, I also need to work on my monitoring…)



Getting this error message back btw:

  "error":"Internal Server Error",


I’ve reported this to our API team and will follow up with you after I have more information.


This issue has been tracked down to a single timeout for a call and an implementation in the application that was caching the failed response.

If anybody else is experiencing 500 errors from us, one of the fastest ways for us to track down what’s happening is to provide the x-trace-id header on the response.

I’m glad we were able to assist you @tobitheo