Has anyone else noticed AI usage killing your Jira instances?

[Jeramy]

Our CEO recently told everyone that they must use Claude to do their Jira work. As of now, we have 150+ PATs all being used for Claude AI agents. Well, my Jira instance crashed this morning and that's the only thing I can think was the reason. 

I'm not sure what to do to prevent AI agents from killing the instance. We are running Jira DC, version 10.3.7. Both of our VMs that host Jira only have 32 GB of RAM in them and they both have mid-range (but older - like 8 years) CPUs. 

How do I limit the amount of incoming API calls, so AI doesn't kill Jira?

[Adrian Woods]

Your thinking is absolutely correct - that's a lot of PATs!

The fastest path to stability is likely to enable built-in rate limiting now → add a reverse proxy with connection limits → plan a hardware upgrade into the future, though I understand that may not be something you're in control of for now. The consolidation of PATs through a gateway is the right long-term architecture here!

Just in case it's not already in place, I let Rovo clean up some instruction for me on how to take a peek at rate limits in case the org is not utilizing them already. See below and wishing you the best of luck here!

Jira DC has native rate limiting available. Go to Administration → System → Rate limiting and configure it:

• Enable rate limiting for REST API requests
• Set a max requests per user per interval — for 150+ AI agents, something like 30–50 requests per user per minute is a reasonable starting point
• You can choose to either block requests that exceed the limit or delay them
• Importantly, rate limiting in Jira DC applies per authenticated user (per PAT), so each of those 150+ PATs gets its own quota

[Jeramy]

Adrian,

Thank you for taking the time to respond. I will look into these options when I get back to the office next week. 

[Martin Runge]

Hi @Jeramy

Have you checked your logs to see if your DC Jira encountered an out-of-memory error?
You could also adjust the JVM_MINIMUM_MEMORY and JVM_MAXIMUM_MEMORY if there is free RAM on your VMs. This way, you are not forced to limit the APIs too much.

[Jeramy]

Hi Martin,

Thank you for taking the time to respond.

I checked the logs, extensively, and there was no indication of out of memory or anything like that. The logs on Node 1 were "normal" until Jira stopped working. The logs on Node 2 did have a few errors, but they were the same errors that Atlassian told me not to worry about when I asked them for help resolving them. The only one that "stood" out as odd, but it was related to ScriptRunner and not liking a Jira Assets "Organization". However, that error occurred about two hours before the crash/Jira stopped workikng.

I have adjusted those values in the past, per Atlassian's recommendations. I will revisit them again next week. I think another issue is that our Jira DC does not have the infrastructure to handle AI Agents. This Jira environment is ~8 years old and running on mid-level hardware. 

I'm thinking that I may need to tell my boss to tell the CEO that we need to cut down on AI agents hitting our Jira instance. The dumb thing is, the company I work for now (we got bought out last Jan), hates Jira. They have already said they will not renew it in November or move to the cloud. Instead, they are having me move everything over to Azure DevOps...yeah, yuck is how I feel. haha

I've tried lobbying to stay with Jira, but our CEO is on the AI only bandwagon and that we can't function without using AI. So even though ADO can't do things as well as Jira, their response to me when I try to lobby for Jira and Confluence, "We're going to through this stuff into ADO and Azure Wiki, then let AI figure it out."

Oy vey...2026, am I right? lol