# Cloud Waste Doesn't Die in a Dashboard. It Dies in the Backlog. > Detecting cloud waste is the easy half. Every cost tool produces a list of idle instances, oversized volumes, and forgotten load balancers. The list is not the problem. The problem is that the fix… Source: https://zop.dev/resources/blogs/jira-tickets-from-cost-recommendations Published: 2026-06-26 · Author: riya-mittal · Tags: finops, jira, integrations, cost-management, remediation --- Detecting cloud waste is the [easy half](https://zop.dev/resources/blogs/auto-remediation-rightsizing-config-rule-class). Every cost tool produces a list of idle instances, oversized volumes, and forgotten load balancers. The list is not the problem. The problem is that the fix lives somewhere the cost tool cannot reach: an engineer's backlog. A recommendation nobody schedules is just a number that ages. The gap is structural. The person who sees the recommendation, often finance or a platform lead, is rarely the person who can action it, the engineer [who owns](https://zop.dev/resources/blogs/resource-ownership-from-activity-logs) the resource. Between them sits a copy-paste ritual: screenshot the recommendation, open Jira, write a ticket, retype the savings, lose the link back. Most recommendations never survive that trip. ZopNight now files the Jira ticket for you, straight from the recommendation. ## A recommendation is only worth the action it triggers Connect Jira once in Settings under Integrations, with either a classic or a scoped token. From there, a recommendation becomes a ticket in one step. Each ticket carries the resource, the estimated savings, and the suggested fix, with a link back to ZopNight, so the engineer gets full context instead of a vague "reduce costs" task. Architecture diagram Status stays in two-way sync. When the engineer closes the ticket, ZopNight knows. When the resource is fixed, the loop is closed on both sides, so your cost view and your issue tracker never drift into two versions of the truth. ## File by hand, or by policy One-off ticketing helps. Policy-driven ticketing scales. Set a rule once, for example a ticket for every idle resource over 50 dollars a month, and ZopNight files them as the recommendations appear. Re-running never files a duplicate, so the policy does not bury a team under [repeat tickets](https://zop.dev/resources/blogs/self-service-terraform-8-modules-60-percent-platform-tickets) for the same resource. | Approach | Carries context | Savings attached | Duplicate guard | Status sync | |---|---|---|---|---| | Recommendation only | No | No | n/a | No | | Manual copy-paste | Partial | Retyped, often wrong | No | No | | ZopNight to Jira | Yes | Yes | Yes | Two-way | That duplicate guard matters more than it sounds. The fastest way to kill a cost program is to flood engineers with noise. The second-fastest is to file the same ticket on every scan. Both make the team mute the tool. ## When ticketing works, and when it does not This works when there is a real owner to route to. A ticket with a resource, a dollar figure, and a fix is hard to ignore and easy to prioritize. It turns a passive dashboard into work that shows up where work is already tracked. It does not fix an absent owner. If a resource belongs to no team, the ticket has no assignee and the recommendation still rots, just in Jira instead of a dashboard. Routing assumes ownership exists, so resolve that first, then let the tickets flow. Waste is rarely an intelligence problem. Everyone can see it. It is a follow-through problem, and follow-through happens in the backlog. Put the recommendation there, with the savings attached, and it finally gets done.