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.







