Integration with Jira

This integration turns Mugnsoft monitor status changes into Jira issues. When a monitor breaches, the Integrator opens an issue; when the monitor recovers, the same issue is resolved automatically.

As a result, your delivery team sees Mugnsoft outages as first-class Jira issues, with no manual creation or closure.

Note:

This integration is configured on the Integrator component, alongside the other push targets. It targets Jira Cloud (REST API v3) over HTTPS, so no Jira app is required.

We assume there are no firewall rules preventing the Mugnsoft Integrator from reaching your Jira site, and that you have an account with permission to create and transition issues in the target project.

How it works

The Integrator reacts only to a confirmed status change:

Breach (monitor goes to a non-OK status): a new issue is created with a summary, the monitor detail in the description, priority derived from the severity, and a dedup label.
Recovery (monitor returns to OK): the open issue is found again and moved through the configured resolve transition.

Jira has no correlation field, so each issue carries a sanitized label mugnsoft-<type>-<name>-<probe> and the open issue is located through an exact JQL query (labels = "<key>" AND statusCategory != Done). Because the lookup is server-side, resolve still works after an Integrator restart, and repeated non-OK checks never open duplicate issues.

Jira also has no direct “set status”: resolving is a workflow transition, looked up by name (default Done) from the issue’s available transitions, then applied.

Mugnsoft status	Jira priority
`CRITICAL` / `ERROR`	`Highest`
`MAJOR`	`High`
`MINOR`	`Medium`

Priority names are instance-defined; the above are the Jira defaults.

Acknowledgement and issue ownership

Mugnsoft itself has no acknowledgement concept — alerting is purely status-driven. To avoid auto-resolve closing an issue your team is actively working, the integration treats the Jira assignee and status as the acknowledgement signal:

If, on recovery, the issue is still unassigned and in the To Do status category, it is auto-resolved.
If a human has taken it (assigned, or moved to In Progress), the issue is left open and a recovery comment is posted instead — closure stays with the operator.

Set Auto-resolve off to disable automated transitions entirely (a recovery comment is always posted).

Flap dampening (grace period)

Because alerting is status-driven and has no dampening of its own, a flapping monitor could open and resolve a stream of issues. The Grace period delays opening an issue after a breach: if the monitor recovers within the window, the flap is suppressed and no issue is created. A genuinely sustained breach still opens an issue once the window elapses. Set it to 0 (default) to open immediately.

Prepare Jira

Create an API token at id.atlassian.com > Security > API tokens. The token is used as the password; your account email is the user.
Choose the project key (for example OPS) where issues should be created, and confirm the account can create and transition issues there.
Note the resolve transition name in that project’s workflow (default Done). It must match a transition available on the issue when it is open.

Configure the Integrator

Navigate to the Integrator component settings and open the external services panel.
Select the Jira tile and enable it.

Jira integration configuration on the Integrator

Fill in the connection fields:

Field	Value
IP/FQDN	Jira Cloud host (e.g. `your-domain.atlassian.net`)
Port	`443`
SSL	on
User (email)	the account email
API token	the account’s API token
Project key	the target project key (e.g. `OPS`)
Issue type	issue type for created issues (default `Bug`)
Resolve transition	transition used to auto-resolve (default `Done`)
Auto-resolve	on (default). When a human has taken the issue, it is left open and a recovery comment is posted instead of transitioning
Grace period (s)	flap-dampening delay before opening on breach; recovery within the window creates no issue (default `0` = immediate)

Click the test button to verify connectivity and credentials, then save.

Verify

Force a monitor failure (for example, run a URL monitor against an unreachable target). A new issue should appear in the project with the monitor name in the summary and a mugnsoft-… label.
Restore the target so the monitor returns to OK. The same issue should move through the resolve transition — no duplicate, and no second issue on subsequent OK checks.