Hand a cost anomaly to the team that owns it, as a Jira, Linear or GitHub issue

Cloud Intelligence™ Threads now start from cost anomalies: open an issue with the evidence attached, follow its status from the anomaly page, and close the loop when engineering is done.

Anomaly detection has never been the hard part of anomalies. The detector fires, the FinOps team sees a project's BigQuery spend tripled overnight, and then the finding enters the gray zone between teams. FinOps can see it but cannot fix it. The engineers who can fix it do not spend too much time in Cloud Intelligence™; they live in Jira, Linear or GitHub.

So someone writes a Slack message, or a ticket with numbers pasted in by hand. From that moment two versions of the truth drift apart. The ticket has no idea whether the spend came back down. The anomaly has no idea whether anyone is working on it. A month later nobody can say what happened to the $2,800, and the same misconfigured schedule is quietly running again.

Starting today, the anomaly and the work are the same record. From an anomaly occurrence you open a Thread, backed by a Jira, Linear or GitHub issue. The issue arrives prefilled with the evidence: what was detected, where, on which service, how much was observed versus expected, and a link back to the exact spike in Cloud Intelligence™. It lands in the backlog of the team that owns the project, in the tool they already plan in. Its status flows back to the anomaly page. This is the same thread model you may already use from Insights and CloudFlow, now pointed at the moment when accountability matters most.

Why file a thread instead of a Slack message

An anomaly is a question addressed to a specific team: did you mean to spend this? A thread makes that question durable. It has an owner, a status, and a place in someone's sprint, so it competes fairly with the rest of their work instead of depending on who happened to read the channel. The engineer picking it up gets the numbers, the timestamp and the console link inside the ticket. Nobody has to come find FinOps to ask what the fuss was about. When the fix lands and the issue closes, FinOps sees "Done" on the anomaly page without polling anyone, then records the outcome on the anomaly itself.

That last step is deliberate. The anomaly's review status and the issue's state stay independent. Engineering owns the issue: To Do, In Progress, Done. FinOps owns the verdict: Under review, Anomaly confirmed, Not an anomaly. A closed ticket does not silently mark an anomaly as reviewed, and a "Not an anomaly" verdict does not close a ticket someone is still working. Each team sees the other's state; neither can overwrite it. Over time, the anomalies list becomes a record of decisions with the work attached, not a list of spikes that someone probably looked at.

For teams building a FinOps practice, this is what accountability looks like in practice: a named owner, a visible status, and a recorded outcome. Detection is central; remediation is distributed. Threads are how you hand a finding to the team that owns the resource, keep visibility while they act, and show the organization that anomalies get resolved rather than acknowledged.

Get started

1. Connect your Jira, Linear or GitHub if you have not already: Jira, Linear or GitHub Issues.
2. Open an anomaly from Cost anomalies and choose Create thread.
3. Follow the work from the anomaly page or from Threads.