Pulumi and Cloud Provider APIs: How to Diagnose Deployment Failures from Logs

Diagnosing Deployment Failures with Pulumi Logs

When a pulumi up fails, operators rely on Pulumi’s structured logs to determine whether the error originates from the provider or from Pulumi’s internal retry logic. The logs include provider‑specific error codes, raw payloads, and status fields, but Pulumi does not translate these into higher‑level, user‑friendly messages. Consequently, the failure context may be obscured by the lack of explicit retry configuration.

Current documentation does not specify the number of retry attempts, back‑off strategy, or whether a failure after a retry should abort the entire stack update or allow the remaining resources to proceed. This ambiguity makes it difficult to diagnose whether a failure is transient or persistent, and to plan deterministic failure handling.

What is the default retry policy for transient provider errors in Pulumi 4.x? Should Pulumi expose configuration options for retry attempts and back‑off? When a retry fails on the second attempt, does Pulumi abort the stack update or continue with remaining resources?