Storage Intelligence adds usage findings and batch dry runs

An unexpected rise in archived-data reads could mean a useful new training job is running, or that the same data is being downloaded unnecessarily. The bill shows activity; choosing the remedy requires knowing the job. Google’s Storage Intelligence update connects that investigation with tools for previewing a bulk storage change, making the gap between a finding and an action worth examining.

The announcement, dated September 26, 2026 makes Storage Intelligence advisor generally available and expands batch operations for its customers. Advisor highlights unusual cold-storage operations, rate-limit errors and cross-region egress using daily snapshots. That cadence suits usage investigation, while immediate service monitoring still has its own job.

A repeated read is a clue about a workload

Consider a hypothetical evaluation job that begins reading archived training datasets every day. If it genuinely needs the same subset frequently, another storage class may fit that subset better. If the repeated download is unnecessary, avoiding it may be more useful than moving objects. The same usage finding supports different changes depending on what the pipeline is trying to accomplish.

Narrow the finding to a bucket and period, then compare those with the job schedule and logs. Its maintainer can confirm whether the access is intended. That gives the owner a concrete question about a recognizable workload instead of asking them to account for an entire storage bill.

A dry-run count needs a selection rule behind it

The batch-operations documentation describes dry runs that report object counts and potential errors without making the change; prefix selection also reports total size. Listing costs can still apply. This previews the batch operation, but does not establish why every matched object belongs in it.

Version choice is part of that scope. A CSV manifest may name an object generation, selecting the version to process; without it, the live version is processed. An empty prefix list selects the entire bucket. A plausible total can consequently describe a materially different action unless the reviewer checks both the objects and the versions behind the count.

For the dataset move, approval needs to identify both the operation and the exact object selection. Changing the operation or selection creates a different batch to review. The bounded-action approach to automation makes that pairing the meaningful decision. Save the reviewed manifest and configuration so the submitted job can later be compared with what was actually approved.

In the pipeline example, archive/ might contain obsolete outputs alongside evaluation datasets still read by the new job. A prefix-wide count would include both, even if only the repeatedly used datasets need a different storage class. Review the matched objects and the selection rule with the maintainer so the submitted move addresses the access pattern that prompted it.

Partial batch results and the next operation

After execution, inspect per-job successes and failures before launching another broad batch. Automatic retries are supported, so incomplete progress does not by itself mean nothing happened. The result record should let the next attempt target remaining objects rather than repeat changes already known to have succeeded.

A deletion proposal needs a different check: verify recovery against the bucket’s actual settings, and leave required data in place if it cannot be shown to be restorable. For the dataset move, the first useful result is narrower: the maintainer can identify the repeatedly accessed objects, the reviewed selection matches them, and the job record shows which changes succeeded or still need attention. That connects the usage finding to the workload it was meant to improve.