Duplicate issues being created in Jira Service Management and Jira

[Nena Kruljac]

Hi,

incident Jira Status - Duplicate issues being created in Jira Service Management and Jira from yesterday made me ask this:

Is it possible to prevent such cases anyhow? Or at least successfully monitor and react faster? For example: 1000 tickets created in 1 hour (numbers might differ in various instances, but we would set our own numbers).

I suppose this was one-time off, but it can happen again in some other case. Automatic creation of issues, especially when existing issues are also updated might be quite a dangerous activity and should be carefully treated + monitored.

Thank you, Nena

[Nena Kruljac]

Hi @Staffan Redelius and @Jack Brickey ,

Yes, we can't prevent Atlassian to make such mistakes. 

Yes, our automation rules didn't do that (although in issue history is written that automation rules did it.)

But we could perhaps establish monitoring to inform us when too many tickets are created in a defined timeslot in order to react faster in the future. 

This could happen again in the future due to some other reason, not exactly this. And it will be painful again. And it won't be possible to quickly fix it again.

This was our timeline:

- 4:07 The cloning issues started

- 8:10 users reported it to me

- 9:10 I reported it to Atlassian

- 11:40 Atlassian published the status incident

If we were notified earlier, I could have earlier reported it to Atlassian and they could have earlier fixed it or at least published the incident.

Atlassian AI chatbot gave me this suggestion (that I haven't yet time to try):

You can set up monitoring for high issue creation rates in Jira Software (Cloud Enterprise) using Jira Automation. Here’s how you can approach this:

Using Scheduled Automation Rules
Scheduled Trigger: Set up a rule that runs on a schedule (e.g., every 10 minutes, hourly, etc.).

JQL Query: Within the rule, use a JQL query to find issues created within your defined timeslot (for example, created >= -10m for the last 10 minutes).

Condition: Add a condition to check if the number of issues returned by the JQL exceeds your threshold.

Action: If the threshold is exceeded, configure the rule to send an email, Slack message, or other notification to your team.

You can fully customize the schedule, JQL, and notification method to fit your needs[^01^].

Example Rule Outline
Trigger: Scheduled (e.g., every 10 minutes)

JQL: created >= -10m

Condition: If the number of issues found is greater than your set limit

Action: Send notification (email, Slack, etc.)

This approach allows you to be automatically informed if too many issues are created in a defined timeslot, helping you monitor for unusual activity or potential incidents[^01^].

Sorry for the confusion, I was trying to be fast :-( Thank you both.

[Staffan Redelius]

Hi @Nena Kruljac 

From the linked issue I understand this was a Incident caused by Atlassian an has nothing to do with automations in your own instance?

Interesting question, I have never heard of anything like this occurring before. I can not really see how it could be prevented from a user admin point of view. It might be a rare case that "shouldn't be possible" but it need to be caught by Atlassian in my opinion.

Best regards,
/Staffan

[Jack Brickey]

Hi @Nena Kruljac , there is nothing we as users/admins can do short of building good automations to prevent any looping.