Skip to content

The moment it happens

Turn monitoring alerts into Jira bugs, one per problem

Each new problem from your monitoring becomes a Jira bug, and repeat alerts are added as comments on the open issue.

Runs
The moment it happens
Apps
Jira
AI
Not needed
Access
read+write (Browse, Create issues, Add comments)

Send this to your assistant

Create a ClickRuntime automation: give me a link my monitoring can send alerts to. For each alert, create a bug in project OPS, or add a comment if there's already an open issue for the same alert.

Paste it into your assistant. It tells you what it will send or change before it runs live.

First time? Adding ClickRuntime to your assistant takes about two minutes.

Why use it

Why teams use this automation

A monitoring tool detects that the payments API is failing and fires an alert every minute until someone fixes it. If each alert opens a Jira ticket, the project fills with two hundred copies of the same problem, the real work is buried, and engineers waste their morning merging duplicates. The opposite mistake, ignoring alerts, leaves real problems without any ticket.

When an alert arrives, ClickRuntime builds a fingerprint from it, such as the service and the error type, and searches Jira for an open issue carrying that label. If one exists, it adds a comment recording that the problem happened again. If none exists, it creates a new issue, so each problem has exactly one ticket.

It is useful for teams that connect monitoring, error tracking or customer reports to Jira.

What you get out of it

  • One ticket per problem

    Engineers see a single issue for each real failure instead of a flood. They can focus on solving it, not on sorting through repeats to find out what is actually broken.

  • Recurrence is still recorded

    Each repeat alert adds a comment to the existing issue. The ticket shows how often and when the problem returned, which helps judge its severity and spot flapping or intermittent failures.

  • Noisy monitors do not bury the backlog

    A misconfigured alert that fires constantly would otherwise create hundreds of tickets overnight. Deduplication contains the damage to a single issue, so the backlog stays usable while the alert is fixed.

  • Closed problems can reopen as new ones

    Once an issue is resolved, the search finds no open ticket, so a later recurrence creates a fresh one. That makes regressions visible instead of hiding them in an old, closed ticket.

  • Alerts get an owner and a history

    A ticket can be assigned, prioritized and discussed, which an alert in a chat channel cannot. The fix, the cause and the timing are recorded in one place for the later review.

How it works

What happens, step by step

  1. When your monitoring tool sends an alert, ClickRuntime receives it straight away.

  2. It gives the alert a fingerprint based on what failed and where, so repeat alerts can be recognised.

  3. It searches Jira for an open issue with that fingerprint.

  4. If one exists, a comment is added saying the alert fired again; if not, a new Jira bug is created.

Before it runs live

  • Connect Jira
  • Paste your automation's link into the other app's webhook settings

What you get

RunsThe moment it happens
Turn monitoring alerts into Jira bugs, one per problemjust nowSucceeded
Jira · OPS-412[Alert] HighErrorRate on checkout-api · comment added: Fired again at 2026-10-19T08:14:02Z

Build your own

Need it to work differently?

This template is a starting point. Copy the prompt and change it, or describe a different automation from scratch, with your own conditions, more apps or an AI step. Your assistant writes it, tests it and runs it on ClickRuntime.
  • Your own rules

    Conditions, thresholds, filters and exceptions, written the way you'd explain them to a colleague.

  • Any number of apps

    One automation can read from one app and update several others. Over 248 apps are ready, and anything with an API works too.

  • AI where it helps

    Summaries, classification, extraction and drafts use ClickRuntime's built-in AI, with no extra key.

  • On a schedule or on each event

    Runs as often as every 5 minutes, or the moment an app sends an event, and keeps track of what it already handled.

Changes you can ask for

  • Act only on the items that match your own rules, and skip the rest
  • Add an AI step, for example to summarize, sort or draft a reply
  • Add another app, for example also send it to Slack
  • Combine it with other Jira steps into one automation

Under the hood

The code that runs this automation

This is the Python script that runs each time the automation starts. Your AI assistant writes it for you when you send the prompt, and you allow each step in your assistant. To change how the automation works, describe the change to your assistant and it updates the script for you. For every function it can use, see the script reference.
create_jira_issues_from_alerts_without_duplicates.pyexample
import hashlib
from clickruntime import on_event, credentials, http

JIRA = "https://api.atlassian.com/ex/jira/your-cloud-id"

def jira(method, path, **kw):
    resp = http.request(method, JIRA + path, headers={
        "Authorization": f"Bearer {credentials.connection('jira', 'work')}", "Accept": "application/json"}, **kw)
    resp.raise_for_status()
    return resp.json() if resp.content else None

def search(jql, fields, limit=100):
    return jira("POST", "/rest/api/3/search/jql", json={"jql": jql, "fields": fields, "maxResults": limit})["issues"]

def adf(text):
    return {"type": "doc", "version": 1, "content": [{"type": "paragraph", "content": [{"type": "text", "text": text}]}]}


@on_event
def handle(event):
    alert = event.json or {}
    fingerprint = "alert-" + hashlib.sha1(f"{alert.get('service')}|{alert.get('name')}".encode()).hexdigest()[:10]
    text = f"{alert.get('name')} on {alert.get('service')}: {alert.get('message', '')}"
    existing = search(f'project = OPS AND labels = "{fingerprint}" AND statusCategory != Done', ["key"], 1)
    if existing:
        key = existing[0]["key"]
        jira("POST", f"/rest/api/3/issue/{key}/comment", json={"body": adf(f"Fired again at {event.received_at}: {text}")})
        return {"issue": key, "created": False}
    issue = jira("POST", "/rest/api/3/issue", json={"fields": {
        "project": {"key": "OPS"}, "issuetype": {"name": "Bug"}, "labels": [fingerprint],
        "summary": f"[Alert] {alert.get('name')} on {alert.get('service')}"[:250], "description": adf(text)}})
    return {"issue": issue["key"], "created": True}

FAQ

Common questions

How does the fingerprint decide two alerts are the same?
It is built from fields in the alert that identify the problem, such as the service name, check name and error message. You choose which fields to use. Including too much, like timestamps, would make every alert look unique.
Can I limit tickets to high severity alerts?
Yes. You can set a condition so that only alerts above a given severity create issues, with lower ones ignored or only commented on when a ticket exists. Say what severity values your monitoring tool sends and what counts as high.
Which tools can send alerts to it?
Any tool that can send a webhook to a link, including most monitoring, error tracking, and uptime services, can be connected. The fields differ per tool, so share a sample alert and the fingerprint can be built from its actual structure.
What permissions does it need?
read+write (Browse, Create issues, Add comments). Nothing else in your accounts is used.
Does it need AI?
No. It runs without AI, so it doesn't use your plan's AI allowance.
How many runs does it use?
One run for each event the app sends.
Can I change how it works?
Yes. Describe the change to your AI assistant, for example a different schedule, channel or filter. It updates the automation, tests it and tells you what changed.

Set up “Turn monitoring alerts into Jira bugs, one per problem” from your assistant

Copy the prompt above, or connect your assistant first. Free plan, no credit card.