Today, we are introducing the CloudFlow SQL node – a way to turn the data you already have into live FinOps and CloudOps automations, using the language your teams already know: SQL.

Instead of exporting data to a BI tool, building a dashboard, and hoping someone remembers to check it, you can now write a SQL query inside CloudFlow and wire the result directly into alerts, workflows, and policies across all of your clouds. The CloudFlow SQL node natively connects to our unified data lake, using the same normalized schema you already use in DoiT Cloud Intelligence™.

While we’re excited to see what you build using the SQL node in CloudFlow, we've helped get you started with several pre-built templates available in the CloudFlow template library (use the Source: Billing Data filter to quickly find them). 

These templates also require no configuration to start running them. Simply click one to open it, and hit publish to start generating meaningful alerts and workflows. Read on for more details about one example you can start implementing:

Example: Time-to-Tag Leakage Analysis (Tag Lag Drift)

Here's a common FinOps problem: even when teams consistently tag resources, tags often appear days after the resource starts incurring costs. The spend generated during that gap shows up as “untagged,” creating leakage that can’t be attributed to the correct owner or workload. Dashboards can display daily untagged spend, but they do not quantify the lag effect or identify services where the lag is worsening.

What the SQL node does:

1. Scans billing data for each resource and computes the first timestamp where a non-system tag is present
2. Compares that timestamp to the resource’s earliest usage cost and calculates leakage per resource, per service, per day
3. Aggregates to daily untagged leakage, total untagged spend, and the percent of spend impacted by tagging delay
4. Computes trend direction (improving or degrading) over a defined window
5. Filters out services that do not support cost allocation tags to avoid noise

In CloudFlow, you can then:

• Trigger an alert only when leakage crosses a threshold or when the trend degrades week over week
• Notify owning teams of the specific services or resources driving the lag (or create a Jira task)
• Feed the data into an CloudFlow's LLM node to generate a human-readable explanation of what caused the degradation and which teams should act

This converts “some of our spend is untagged” into an operational metric with direction and ownership.

What you can build next

This example is only a starting point. With the CloudFlow SQL node, you can also design automations for:

• Budget guardrails and burn rate monitoring at the project, account, or business unit level
• Policy checks for label compliance are tied directly to your own label taxonomy
• Identification of noisy SKUs, high-cost regions, or underutilized data services
• Custom CloudOps SLOs driven by spend and usage patterns, not just uptime

If you already use DoiT Cloud Intelligence, the CloudFlow SQL node is available in your environment as a new node type inside CloudFlow. Start by taking one of your existing FinOps queries and turning it into an automated Flow that runs on a schedule, posts to Slack, opens Jira tickets, or chains into additional nodes such as LLM-based explanations.

Learn more about the SQL Node in DoiT Cloud Intelligence Help Center. We can also help you build your automation free of charge! Just ask at support.doit.com.