When building reports across large datasets, a partial result is often enough to confirm that your report's configuration is giving you what you need.

You can now run your query against a random sample of roughly 10% of the data matching your report's current scope, so you can quickly validate that your filters and groupings are returning results the way you intend. Once the sample confirms your setup looks right, switch to a full run with confidence.

To get started, create a new report or open an existing one and select the sample option before running. For details on how sampling works, see the documentation.

Cloud Diagrams now surfaces resource cost data and cost heatmap visualizations for Google Cloud-based diagrams, extending the cost visibility already available for AWS.

Tracking down cloud cost drivers typically means cross-referencing billing reports with your infrastructure. A cost report tells you what's expensive, but not what that resource is connected to or why it's driving spend.

Cloud Diagrams brings those two views together, so from any diagram built, you can:

• See cost data per resource: Click any resource node and open the Costs tab to see a cost trend chart, total spend, and week-over-week breakdown for that specific resource.
• Identify high-cost resources visually: Select the Costs chip to enable a cost heatmap, where resource nodes are color-coded by spend so the most expensive resources surface immediately.
• Investigate in context: Click any resource to see its properties, connections, and dependency chain, then use Investigate mode to trace what that spend is actually connected to.

When a FinOps or CloudOps process needs to take action, the last mile often happens outside your tooling: someone opens a terminal, runs a one-off CLI command, pastes output into a ticket, and hopes the next person follows the same steps. That breaks auditability and makes repeatable governance hard, especially when you’re promoting artifacts between environments or responding to an incident under time pressure.

CloudFlow now includes a CLI node, so you can run AWS or GCP commands as a first-class step inside a flow, alongside the rest of your automation. This lets you encode terminal-only procedures as an automated, repeatable workflow with a run history, rather than relying on tribal knowledge and manual execution.

For example, a storage expansion workflow can attach an existing EBS volume to an EC2 instance using the same CLI command you already know, but executed as part of the flow. Under the hood, the CLI action maps to the same API sequence you’d expect (validation, state checks, then the attach call), which makes the operation predictable and easier to reason about when troubleshooting.

Similarly, release or data movement workflows that “S3 sync” become explicit, repeatable building blocks. In S3, “move” is actually a copy-and-delete operation, and encoding that once in a flow reduces accidental deviations between operators and environments.

If you’ve ever tried to automate a real FinOps workflow, you’ve felt the sprawl: thousands of AWS and GCP APIs, inconsistent parameters, and “just one more edge case” before it’s safe to run at scale. The result is usually the same story: a good idea stalls because stitching it together takes longer than the savings it’s meant to unlock.

CloudFlow’s Agent Builder is designed for that moment: when you know the outcome you want (for example, investigate a cost spike and recommend the next action), but you don’t want to build and maintain a custom integration for every system involved.

Agent Builder provides a way to create and manage flows in CloudFlow so you can move from “we should automate this” to a repeatable workflow that can be triggered and governed like any other CloudFlow automation. Instead of designing every branch of logic around individual APIs, you define the flow in natural language once.

In practice, this is meant to shift your work up a level:

• from integrating every AWS/GCP endpoint yourself,
• to packaging a reusable “investigate and act” capability you can drop into multiple flows (alerts, ticket enrichment, scheduled checks, remediation handoffs).

Getting Started with Agent Builder

• Create or open an existing flow and navigate to the Agent Builder page.
• Ask Agent Build to create a new flow (for example: cost anomaly triage, tagging governance checks, owner resolution).
• Run it in a controlled scope first (a single account, a single project, or a narrow set of services), then expand.

In real workflows, cloud APIs often return before the resource is actually usable. For example, your flow might create an instance and immediately try to attach storage or run a configuration step, only to fail because the instance is still booting or the resource state has not converged.

AWS has native waiters for some APIs, but they cover only a small subset of services and operations. In Google Cloud, you generally don’t get an equivalent out of the box, which pushes teams toward brittle sleep steps and custom retry loops.

You can now add a “waiter” to cloud API actions so CloudFlow pauses until the resource reaches the state you need, then continues automatically. This reduces fragile retry logic and makes multi-step automations behave consistently across AWS and Google Cloud.

A waiter is tied to the specific action you’re running and waits on a defined target state before the next step runs. You enable the waiter on the action, choose what to wait for, and optionally tune the polling behavior for faster or more conservative checks. If the waiter needs extra inputs to verify readiness, you provide those parameters as part of the waiter configuration.

To get started, review the "Add a Waiter" article.

If you have a Microsoft Azure Consumption Commitment (MACC), you can track drawdown progress directly in DoiT Cloud Intelligence with the same daily-updated visualizations, service-level breakdowns, and forecasting already available for AWS EDPs and Google Cloud spend commitments.

After adding your Azure MACC in Commitment Manager, you’ll be able to:

• See your spend-to-date, remaining balance, and a forward forecast against your MACC commitment value, updated daily.
• Understand which Azure services are generating eligible spend and contributing to MACC decrement, with month-by-month totals across your full contract period.
• Track Marketplace spend against your contract limit with a month-by-month breakdown and drill down into which Marketplace services contributed.
• View all your cloud commitments in one place if you also have active AWS or Google Cloud spend commitments.

To get started, open Commitment Manager in DoiT Cloud Intelligence. For configuration guidance, see the docs.

Cost anomalies do not always stop after the first notification. In real environments, an anomaly can persist across hours or days, get buried in Slack or Teams, or grow significantly after initial detection. FinOps and CloudOps teams need a follow-up signal when cost risk remains unresolved or escalates.

In DoiT Cloud Intelligence, cost anomaly notifications are no longer limited the initial detection.

You can now configure re-notifications so you’re notified again when:

• An anomaly remains active after a specified period of time (similar to a reminder or snooze), or
• The anomaly impact increases, either by a fixed dollar amount, a percentage, or a combination of amount and percentage.

Previously, notifications were triggered only when a threshold was first crossed. Now, notifications can continue if cost risk persists or escalates, helping teams stay aware of ongoing or worsening spend issues.

Re-notifications can be configured within your existing anomaly notification settings and works with current Slack, Teams, and email delivery options. To learn more about it, consult our Help docs or raise a support ticket to speak to a DoiT expert.

Cloud automations rarely live in isolation. One flow detects an issue, another enriches context, a third notifies the right team. Without a shared source of truth, you end up duplicating logic or hardcoding mappings that drift over time.

The Datastore node provides your CloudFlow automations with a shared, managed place to store and query structured data, enabling multiple flows to reference the same tables for enrichment, routing, and state. Think of Datastore as a lightweight database you can use directly from flows.

A common pattern is a tag ownership table:

• You maintain a table that maps tags (or tag patterns) to an owner, team, cost center, escalation channel, and metadata.
• Any flow can query it to resolve “who owns this?” consistently.

Example: an anomaly flow spots a sudden spike on an untagged workload. It looks up the resource’s tags, queries the ownership table, and then routes the alert to the correct Slack channel. A separate remediation flow uses the same table to decide who can approve a change and where to open a ticket.

In the Datastore node, you can:

• Get records using filters (including values from previous nodes)
• Insert records for new rows, including batch inserts
• Upsert records to keep a table current without duplicates by using a unique key column

Supported column types include Text, Integer, Numeric, Boolean, Date, Timestamp, and JSON.

How to get started

Create a Datastore table for shared mappings (for example, tag-to-owner), then reference it from any flow via a Datastore node query. Use Upsert when you want scheduled flows to keep the table continuously in sync from an authoritative source. 

Some workflows need a deliberate delay to avoid API throttling or to wait for changes to propagate. For example, if you’re looping through cloud resources or applying IAM updates, a short pause can prevent rate-limit errors and reduce noisy retries.

A common operational pattern is also dev environment scheduling: start in the morning, run all day, then shut down in the evening. Sleep lets you build this into a single flow without external schedulers.

What’s new

You can add a Sleep node to pause a CloudFlow run for a configurable duration, then automatically resume execution. This helps you:

• Space out provider API calls to reduce throttling risk
• Add cooldown periods before re-checking or notifying
• Wait for eventual consistency (for example, new resources or IAM changes becoming effective)
• Orchestrate time-based actions in one flow, like dev environment start and end-of-day shutdown

How it works

When a run reaches the Sleep node, CloudFlow marks the run as Sleeping and pauses execution until the configured time elapses. After the duration completes, CloudFlow wakes the run and continues to the next node.

How to get started: https://help.doit.com/docs/operate/cloudflow/nodes/sleep