Cloud Tasks brings per-task retry settings to general availability

A background job that refreshes an incident summary and a job that changes a service configuration should not necessarily keep trying for the same length of time. Google Cloud’s September 30 release notes mark task-level retry settings in Cloud Tasks as generally available, alongside batch creation and deletion. An individual task can now override its queue’s retry configuration when it is created.

Cloud Tasks delivers queued work to a handler, such as an HTTP endpoint that gathers evidence for an incident assistant. The retry configuration determines how the queue tries again after an unsuccessful attempt. Putting that choice on the task is useful when jobs share infrastructure but have different useful lifetimes: a summary requested during an active incident may become stale long before a routine historical export loses its value.

The exception can travel with the job

The configuration guide shows a retryConfig object in the task-creation request. It controls attempts, retry duration and backoff, the waiting period between attempts. maxAttempts includes the initial attempt. This is an override of queue retry behavior, not a replacement for the application’s decision about whether the requested work still makes sense.

One detail deserves attention before translating a business deadline into configuration. Google documents that retrying stops after both the attempt and duration conditions are met, or when the task succeeds; retention limits also apply. Treating those fields as “whichever limit arrives first” would produce the wrong expectation. For a job that must not act after a particular time, the handler needs to inspect an application deadline before doing the work.

For example, consider a hypothetical task asking an assistant to assemble current checkout errors for an incident update. Give the request an incident identifier and an expiry time. If the dependency is temporarily unavailable, another attempt may still deliver a useful summary. If the request has expired by the time the handler runs, it should record that disposition and finish without producing a fresh-looking report from an obsolete request. The expiry check belongs to this proposed application design; it is not a new Cloud Tasks feature.

Check what the previous attempt already did

That distinction becomes more consequential when the job can change a system. A handler might apply a configuration update and lose its response before the queue learns that it finished. Google’s execution limitations explicitly allow duplicate execution, so a shorter retry policy does not make a write happen exactly once.

Before repeating a remediation, reconcile the previous result against the target’s current state. Keep a stable operation identifier across attempts so the handler can find a completed change rather than apply it again. If another executor can perform the same remediation, the duplicate check must cover that executor too. This applies the bounded-action approach in the auto-remediation guide to a specific delivery mechanism.

For a read-only evidence refresh, repeating the query may be acceptable, subject to its cost and freshness. For a write whose prior outcome cannot be established, another automatic attempt can compound the uncertainty. Preserve the unresolved result for investigation instead of treating the queue’s willingness to retry as evidence that repetition is safe.

The release is worth examining if queue-wide settings have forced unlike jobs into the same retry behavior. Start with a replayable, read-only job and check the returned task configuration, expiry handling and recorded outcomes before extending the pattern to changes. Google’s product-specific release page still showed the earlier preview entry at review time, while the current central release notes and task-creation guide reflected the new release. Confirm that the client library you deploy exposes the required fields; this report verifies documentation, not a hands-on rollout.