Cost anomalies as tickets, assigned to the right team before anyone reads Slack

Route anomalies to the team that owns the resource, as Jira, Linear or GitHub issues, based on severity, billing scope and how they were detected.

Anomaly detection has a delivery problem, not a detection problem. The detector fires, the Slack channel and the inbox light up, and the notification reaches everyone who subscribed. In a small team that works. In an organization where the checkout team owns one set of billing accounts, the data platform team owns another and platform engineering is on the hook for anything critical, the same notification hits forty people, thirty-eight of whom cannot do anything about it. After a few weeks the channel gets muted. Meanwhile the two people who could have fixed the misconfigured schedule find out about it when finance asks.

Threads now has automation rules: you describe which anomalies (or insights) belong to which team and where their issues should go, and Cloud Intelligence™ opens the thread in that team's backlog the moment a matching anomaly is detected.

What you get

A rule is a set of conditions plus a destination. Conditions are the anomaly's own details: severity, the billing scope it was detected in, whether it came from billing data or real-time usage, its triage status, labels/tags, etc. The destination is a project, team or repository in a tracker (Jira, Linear or GitHub) along with the assignee, labels and issue title you want. So "any critical anomaly" becomes a GitHub issue for platform engineering, "medium anomalies in the checkout billing accounts" becomes a Jira ticket for the checkout team, and "real-time anomalies in the analytics projects" becomes a Linear issue for the data platform team. Nobody else gets paged. The people who receive the thread are the people who can change something.

You can preview a rule against recent anomalies before turning it on, nothing gets created in preview. Rules run top to bottom and the first active one that matches handles the anomaly, so you drag the specific rules above the broad ones. A rule can be paused without deleting it.

The first rule that matches an anomaly creates its primary Thread, with the same evidence a manual thread gets: what was detected, where, how much was observed versus expected, and a link back to the spike. Anomalies are not static. When a later revision of the same anomaly still qualifies, the rule adds a comment to the existing issue rather than opening a second one, even if the issue is already closed, and it leaves the assignee, status and everything else your engineers set alone. Every rule change is kept as an immutable revision, and a Run log shows what fired, what it created and why.

If Jira, Linear or GitHub Issues is already connected for Threads, there is nothing new to install. Automation and manual creation share one record, so if a colleague opens a thread by hand first, the rule sees it and does not create a duplicate. There is also a daily creation limit per account, so a noisy morning cannot flood a backlog.

Get started

1. Connect Jira, Linear or GitHub Issues, if you haven't already.
2. Make sure anomaly detection covers the scope you care about, including any allocations you want rules to match on. Rules only see anomalies the detector produces.
3. Open Threads, select Thread automation, and create your first rule.

Automation rules are available to any account with the Thread Manager permission. What we most want to hear now is how your rules behave against a real month of anomalies: which ones fired when they shouldn't have, and which teams you still couldn't reach with the conditions available.