What conditions can trigger lifecycle actions?

Lifecycle rules support multiple conditions including age (days since creation or noncurrent), createdBefore (absolute date), numNewerVersions (for versioned objects), isLive (live vs. noncurrent), matchesStorageClass (current class), matchesPrefix and matchesSuffix (object name filters), and daysSinceCustomTime (custom metadata timestamp). Multiple conditions in a single rule use AND logic — all conditions must be true for the action to execute.

What storage class transitions are allowed?

Objects can transition from Standard to Nearline, Coldline, or Archive; from Nearline to Coldline or Archive; and from Coldline to Archive. You cannot transition to a higher-performance class using lifecycle rules — for example, you cannot move an object from Archive back to Standard via lifecycle. To move objects to a higher class, you must rewrite the object using gsutil, the API, or Storage Transfer Service.

How do lifecycle rules interact with object versioning?

When versioning is enabled, lifecycle rules can target live (current) versions using isLive: true and noncurrent (previous) versions using isLive: false. The numNewerVersions condition counts how many newer versions exist, letting you keep only the N most recent versions. A delete action on a live versioned object creates a noncurrent version rather than permanently deleting it. To permanently delete noncurrent versions, create a separate rule targeting isLive: false with an age condition.

GCP Cloud Storage Lifecycle Builder

StorageGCP

Build Cloud Storage lifecycle management rules for storage class transitions and deletion.

Cloud Storage Lifecycle Rules

Rule 1

Action

Age (days)

Is Live

Newer Versions

Matches Storage Class

StandardNearlineColdlineArchive

Created Before (YYYY-MM-DD)

Generated Lifecycle Configuration JSON

{
  "rule": [
    {
      "action": {
        "type": "Delete"
      },
      "condition": {
        "age": 365
      }
    }
  ]
}

About This Tool

Google Cloud Storage lifecycle management automatically transitions objects between storage classes or deletes them based on configurable rules. Rules evaluate conditions like object age, creation date, number of newer versions, storage class, and whether the object is live or a noncurrent version. Properly configured lifecycle rules can dramatically reduce storage costs by moving infrequently accessed data to Nearline, Coldline, or Archive classes and cleaning up old versions. This builder helps you define lifecycle rules with correct condition combinations, action types, and storage class transition sequences.

When to Use This Tool

•Building lifecycle rules that transition objects from Standard to Nearline after 30 days and to Coldline after 90 days for a tiered archival strategy
•Creating rules that delete noncurrent object versions older than 7 days in versioned buckets to control storage costs from accumulated versions
•Configuring lifecycle rules that abort incomplete multipart uploads after 7 days to reclaim storage from failed large file uploads
•Generating lifecycle configurations that combine age-based transitions with storage class conditions to avoid redundant transitions

Frequently Asked Questions

What conditions can trigger lifecycle actions?: Lifecycle rules support multiple conditions including age (days since creation or noncurrent), createdBefore (absolute date), numNewerVersions (for versioned objects), isLive (live vs. noncurrent), matchesStorageClass (current class), matchesPrefix and matchesSuffix (object name filters), and daysSinceCustomTime (custom metadata timestamp). Multiple conditions in a single rule use AND logic — all conditions must be true for the action to execute.
What storage class transitions are allowed?: Objects can transition from Standard to Nearline, Coldline, or Archive; from Nearline to Coldline or Archive; and from Coldline to Archive. You cannot transition to a higher-performance class using lifecycle rules — for example, you cannot move an object from Archive back to Standard via lifecycle. To move objects to a higher class, you must rewrite the object using gsutil, the API, or Storage Transfer Service.
How do lifecycle rules interact with object versioning?: When versioning is enabled, lifecycle rules can target live (current) versions using isLive: true and noncurrent (previous) versions using isLive: false. The numNewerVersions condition counts how many newer versions exist, letting you keep only the N most recent versions. A delete action on a live versioned object creates a noncurrent version rather than permanently deleting it. To permanently delete noncurrent versions, create a separate rule targeting isLive: false with an age condition.

Related Learning Guides

GCS Storage Classes & Lifecycle22 min read

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.