Automated Incident Creation: Monitoring to Jira Service Management

Night alerts, manual ticket creation, and lost minutes on critical incidents — a familiar pain for any operations team. We automate incident handling in Jira Service Management, setting up integrations with monitoring and alert deduplication. Our team delivers the project turnkey — from process audit to implementation and ongoing support, ensuring reliable operation and scalability.

Our competencies:

Frequently Asked Questions

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1365
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1330
  • B2B Advance company logo design
    B2B Advance company logo design
    776
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1077
  • AIDER company logo development
    AIDER company logo development
    1022
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1113

Imagine: a production service goes down at night. Alertmanager sends an alert to PagerDuty, but the on-call engineer manually creates a ticket in Jira Service Management. While they search for a template, fill in severity, and assign SLA, minutes pass — each alert turns into dozens of messages. We faced this challenge while maintaining an infrastructure with 200+ microservices for a client in the fintech sector. The result of automation: response time reduced by 60%, and operational costs for incidents cut in half by eliminating routine. With over 5 years of experience in ITSM and monitoring (30+ implementations), we've developed optimal integration schemes.

Experience shows there is no one-size-fits-all solution — the method must be chosen based on the specific stack and flexibility requirements. Below is a comparison of approaches by key parameters.

Method Flexibility Setup Complexity Deduplication Bidirectional Sync Implementation Time
Alertmanager webhook High Medium Configurable Partial (resolve) 2-3 days
Grafana OnCall Medium Low Built-in Full 1-2 days
Grafana Alerting → JSM Low Low Basic No 1 day

How the Alertmanager Webhook Integration with JSM Works

The most flexible path is a webhook receiver in Alertmanager that calls the Jira REST API:

# alertmanager.yml
receivers:
  - name: jira-incidents
    webhook_configs:
      - url: http://jsm-bridge:8080/alert
        send_resolved: true
        http_config:
          bearer_token_file: /etc/alertmanager/jsm_token
route:
  group_by: ['alertname', 'namespace', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 6h
  routes:
    - match:
        severity: critical
      receiver: jira-incidents
    - match:
        severity: warning
      receiver: jira-incidents
      continue: false

The webhook service creates an issue via POST /rest/api/3/issue with fields: summary, description, priority, labels. When send_resolved: true, Alertmanager sends a second request with status resolved — the service finds the open issue by JQL and closes it. According to Atlassian documentation, this method allows control over every incident field.

Dealing with Alert Deduplication

Without deduplication, a single failure generates dozens of tickets. Two layers of protection:

At the Alertmanager level: group_by: ['alertname','namespace','service'] groups related alerts into one webhook. group_wait: 30s collects repeated firings before the first call.

At the webhook service level: before creating an issue, the service executes a JQL query: project = INFRA AND issuetype = Incident AND status != Done AND labels = "alert:HighCPU" AND labels = "host:prod-01". If a ticket is found, a comment is added; no new ticket is created. This ensures one event = one incident.

Native Integration via Grafana OnCall

If your stack includes Grafana OnCall, the JSM connector can be set up in an hour. OnCall supports creating a JSM incident when an escalation is activated, automatically closing it on resolve, and bidirectional status synchronization. This is simpler than a custom webhook, but flexibility is lower: you cannot customize field mapping for complex scenarios. Grafana OnCall is 50% faster to implement than the webhook approach.

Direct Grafana Alerting Integration

In recent versions of Grafana, a Contact Point of type Jira is available. Setup: Jira URL, username, API token, project, issue type, summary. The limitation is no conditional creation (only routing rules) and no custom fields.

Configuring JSM for Monitoring Incidents

In JSM, you need:

  • A Service Project with SLA policies and an on-call queue.
  • A Request Type "Monitoring Alert" with fields: severity, affected_service, alert_link.
  • Automation Rules to automatically assign to the on-call engineer (via JSM on-call rotation) and transition statuses based on priority.

Example Automation Rule: when an issue is created with request type "Monitoring Alert" and priority Critical, assign to the on-call engineer via rotation and move to "In Progress" status.

const express = require('express');
const axios = require('axios');
const app = express();
app.use(express.json());
app.post('/alert', async (req, res) => {
  const { alerts } = req.body;
  for (const alert of alerts) {
    // search for existing issue by JQL
    const existing = await jira.search(`project = INFRA AND status != Done AND labels = "alert:${alert.labels.alertname}"`);
    if (existing.length === 0) {
      // create new issue
      await jira.createIssue({
        summary: alert.annotations.description,
        issueType: 'Incident',
        priority: alert.severity === 'critical' ? 'Highest' : 'High',
        labels: [`alert:${alert.labels.alertname}`]
      });
    } else {
      // add comment
      await jira.addComment(existing[0].id, 'Repeat alert');
    }
  }
  res.send('ok');
});
app.listen(8080);

Implementation Method Comparison

Method Speed of Implementation Flexibility
Webhook service 2-3 days High
Grafana OnCall 1-2 days Medium
Direct connector 1 day Low

What's Included in the Work

Implementation of automation includes:

  • Audit of current monitoring scheme and ITSM processes.
  • Selection of integration method with justification.
  • Setup of webhook/connector with deduplication and field mapping.
  • Testing of the full cycle: from alert to ticket closure.
  • Documentation of configuration and instructions for on-call engineers.
  • Post-release support for 2 weeks.

Process and Timelines

We start with alignment: project, issue type, custom fields, SLA policies. This takes 1 day. Technical implementation takes 1 to 2 days, including deployment and testing. Timelines range from 2 to 3 days. Cost is calculated individually, depending on scope complexity.

When to Choose Webhook vs Grafana OnCall?

  • Webhook — if you need full customization, non-standard deduplication rules, or integration with legacy systems.
  • Grafana OnCall — if your stack already includes Grafana and your team wants minimal entry barrier and bidirectional sync.
  • Direct connector — for simple scenarios without complex fields and conditional logic.

Why This Is Beneficial?

Automating incident creation from monitoring saves up to 10 hours per week for the on-call engineer and reduces MTTR by 50% (real numbers from one of our implementations). Average budget savings on incidents is 40% after deployment. We guarantee quality: all configurations are tested on a staging environment before production deployment.

To eliminate manual ticket creation, contact us for automation implementation. Order the integration today — your alerts will turn into incidents without delays.