ITSM Integration with Jira: Turning Cost Findings Into Work

An ITSM integration connects an operations tool to the IT service management system where teams already track work, so that findings become tickets with an owner, a status, and a history. For cloud cost, it solves a specific problem: the people who can act on a recommendation, the service owners, rarely live in the cost tool. They live in Jira.

The integration only works if it avoids two failure modes: duplicate tickets for the same problem, and tickets whose status drifts from the finding they describe. The design choices below are about those two.

Connecting Jira

In ZopNight, an admin connects Jira from Settings, Integrations with a base URL, project key, issue type, a bot account’s email, and an API token. The credential is verified live before it is saved, using Jira’s “get current user” endpoint, so a bad token or an unreachable host fails at connect time with a categorized error. Both kinds of Atlassian API token are accepted. A classic token authenticates against the site URL; a scoped token is verified through the Atlassian API gateway instead. Connecting also registers an inbound webhook in Jira where the token’s user is a Jira admin, and removes it on disconnect. A scoped token connects with outbound ticketing working, but the inbound webhook needs a classic token held by a Jira admin.

Plan for rotation. Atlassian now sets new API tokens to expire in one year by default, with an expiry you can choose from one day up to one year, so the bot’s token needs a renewal date in someone’s calendar.

From recommendation to ticket

There are two ways to open a ticket:

• On demand. A “Create Jira ticket” action on a recommendation opens a real issue carrying the summary, the resource, the savings, and the suggested fix, and returns a badge linking to the issue. Assignee emails are resolved to Jira account IDs; if there is no match the ticket is created unassigned with a warning.
• By policy. A recommendation policy with an open_ticket action opens a ticket automatically when a matching finding is newly surfaced. While you build the policy, a live estimate shows roughly how many open recommendations match, so an overly broad policy is visible before it files hundreds of tickets.

Both paths share one deduplication key: the organization, the resource, and the rule. A repeat request for the same problem does not create a second ticket, even if the recommendation itself has been regenerated with a new ID.

Keeping ticket and finding in agreement

Status syncs in both directions, driven by events rather than polling. When a recommendation is closed, dismissed, or optimised, the issue moves to Done; applied or observing moves it to In Progress; drift adds a comment. When the Jira issue changes status, a signed webhook applies the matching status to the recommendation, and transitions the recommendation’s state machine does not allow are dropped rather than forced. A loop guard stops the two sides from bouncing a change back and forth. Ownership follows the same path: setting an owner on the recommendation reassigns the existing issue, and a Jira assignee change flows back. Deleting the Jira issue unlinks it and leaves the recommendation alone.

Known limits

The policy resolver keeps one most-specific effect per scope, so if you want both a notification and a ticket for the same finding, set the two policies at different scopes. Jira reopening an issue does not yet reopen the recommendation.

Related: FinOps and engineering collaboration, auto-remediation, and the how-to for creating Jira tickets from recommendations.