tutorial

Monitoring Pulumi Cloud Infrastructure Deployments with Vigilmon: Stack Health, API Uptime & SSL Alerts

How to monitor Pulumi Cloud infrastructure deployments with Vigilmon — stack update health, Pulumi API uptime, deployment endpoint monitoring, and SSL certificate alerts for IaC pipelines.

Pulumi Cloud is the infrastructure-as-code platform that provisions, updates, and destroys cloud resources — Kubernetes clusters, databases, networking, storage, and compute — through code. When Pulumi Cloud is degraded, infrastructure updates stop: deployments queue, rollbacks fail, and the state backend becomes unavailable, leaving teams unable to see or modify their infrastructure state. Vigilmon gives you external visibility into the Pulumi Cloud API, your self-managed Pulumi state backends, and the cloud provider endpoints your stacks depend on — so you catch deployment infrastructure failures before they block production releases.

What You'll Build

  • A monitor on the Pulumi Cloud API endpoint for deployment and state operations
  • A monitor on your Pulumi state backend if self-hosting (Azure Blob, AWS S3, or local backend)
  • An HTTP check on Pulumi's webhook delivery endpoint for CI/CD integrations
  • SSL certificate monitoring for Pulumi Cloud and any custom backend domains
  • An alerting setup that distinguishes API outages from state lock conflicts

Prerequisites

  • A Pulumi project using Pulumi Cloud (app.pulumi.com) or a self-managed backend
  • One or more Pulumi stacks under active management (dev, staging, production)
  • CI/CD pipelines triggering pulumi up on push or release events
  • A free account at vigilmon.online

Step 1: Verify the Pulumi Cloud API Endpoint

Pulumi Cloud's API is the backend for all state storage, stack updates, policy checks, and deployment history. Every pulumi up, pulumi preview, and pulumi destroy call communicates with this API.

# Test Pulumi Cloud API availability
curl -I https://api.pulumi.com
# Returns 200 when the API is healthy

# Test the specific stack API endpoint
curl -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
  https://api.pulumi.com/api/user
# Returns 200 with user details when authenticated and API is up

The unauthenticated API root returns 200 when Pulumi's API is operational — you don't need credentials to check availability. Use the unauthenticated endpoint for Vigilmon monitoring to avoid storing tokens.

Step 2: Monitor the Pulumi Cloud API with Vigilmon

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://api.pulumi.com.
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Label: Pulumi Cloud API.
  7. Click Save.

This monitor catches:

  • Pulumi Cloud service outages that prevent pulumi up from running
  • API degradation that causes state read/write failures mid-update
  • Authentication service failures that block all CLI commands
  • Database backend failures that prevent state storage

Alert sensitivity: Set to 2 consecutive failures. Pulumi's API occasionally returns transient errors during peak deployment times; two consecutive failures reliably indicate a real outage.

Pulumi Deployments vs. CLI: If you use Pulumi Deployments (Pulumi Cloud runs your pulumi up in Pulumi's cloud infrastructure), an API outage also stops the Deployments runner — you lose both state access AND the ability to trigger deployments. The same API monitor covers both scenarios.

Step 3: Monitor Pulumi's Console UI

Pulumi's web console at app.pulumi.com is where teams review stack history, manage secrets, set up webhooks, and configure OIDC. If the console is down, operators can't inspect deployment history or recover from failures:

curl -I https://app.pulumi.com
# Returns 200 when the Pulumi console is serving requests
  1. Add Monitor → HTTP.
  2. URL: https://app.pulumi.com.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Label: Pulumi Cloud console.
  7. Click Save.

Console vs. API: The Pulumi console and API are separate services. It's possible for the API (and therefore pulumi CLI commands) to be healthy while the console is degraded — or vice versa. Monitor both independently so you can distinguish between "we can't see the dashboard" and "deployments are actually blocked."

Step 4: Monitor a Self-Managed Pulumi State Backend

If you self-host your Pulumi state backend using AWS S3, Azure Blob Storage, or Google Cloud Storage, Pulumi communicates with that backend for every operation. A degraded backend causes pulumi up to fail with state lock errors or incomplete state reads.

AWS S3 backend:

# Test S3 bucket accessibility (returns 403 when unauthenticated but S3 is reachable)
curl -I https://s3.amazonaws.com/your-pulumi-state-bucket/
  1. Add Monitor → HTTP.
  2. URL: https://s3.amazonaws.com/your-pulumi-state-bucket/.
  3. Check interval: 5 minutes.
  4. Expected status: 403 (unauthenticated requests to S3 return 403 when the bucket exists and S3 is healthy; 502/503 mean S3 is degraded).
  5. Label: Pulumi S3 state backend.
  6. Click Save.

Azure Blob Storage backend:

# Test Azure Blob availability for Pulumi state
curl -I "https://your-account.blob.core.windows.net/pulumi-state?restype=container"
  1. URL: https://your-account.blob.core.windows.net/pulumi-state?restype=container.
  2. Expected status: 403.
  3. Label: Pulumi Azure Blob state backend.

Google Cloud Storage backend:

curl -I https://storage.googleapis.com/your-pulumi-state-bucket
  1. URL: https://storage.googleapis.com/your-pulumi-state-bucket.
  2. Expected status: 403.
  3. Label: Pulumi GCS state backend.

State lock conflicts: When pulumi up crashes mid-update, it leaves a state lock. This isn't a backend outage — the backend is healthy but Pulumi blocks future operations until the lock is cleared. Vigilmon can't detect lock conflicts (the backend HTTP endpoint is still healthy). Monitor your CI/CD pipeline failure rate separately; repeated CI failures combined with a healthy backend monitor is the signal for a stuck state lock.

Step 5: Monitor Pulumi Webhook Delivery Endpoints

Pulumi Cloud fires webhooks on stack update events (success, failure, preview). If your webhook consumer (Slack, PagerDuty, custom service) is down, your team stops receiving deployment notifications.

Monitor your webhook consumer endpoint:

# Test your webhook consumer health
curl -I https://hooks.example.com/pulumi
# Or for Slack incoming webhooks
curl -I https://hooks.slack.com
  1. Add Monitor → HTTP.
  2. URL: https://hooks.example.com/pulumi (your webhook consumer).
  3. Check interval: 5 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200 (or 405 if your webhook endpoint only accepts POST).
  6. Label: Pulumi webhook consumer.
  7. Click Save.

One-way failure: If Pulumi Cloud's API is healthy but your webhook consumer is down, deployments still succeed — you just won't receive notifications. This means a production infrastructure update could complete (or fail) silently. The webhook consumer monitor ensures you don't lose visibility into deployment outcomes.

Step 6: Monitor Cloud Provider Endpoints Your Stacks Depend On

Pulumi provisions resources through cloud provider APIs. If AWS, Azure, or GCP APIs are degraded, pulumi up may appear to hang or fail with provider-level errors. Monitor the provider API status endpoints:

AWS:

curl -I https://sts.amazonaws.com
# Returns 200 when AWS STS (authentication) is healthy
  1. URL: https://sts.amazonaws.com.
  2. Expected status: 200.
  3. Label: AWS API health (for Pulumi stacks).

Azure:

curl -I https://management.azure.com
# Returns 200 or 400 (requires auth) when Azure Resource Manager is healthy
  1. URL: https://management.azure.com.
  2. Expected status: 200 or 400.
  3. Label: Azure Resource Manager (for Pulumi stacks).

GCP:

curl -I https://cloudresourcemanager.googleapis.com
  1. URL: https://cloudresourcemanager.googleapis.com.
  2. Expected status: 200.
  3. Label: GCP Resource Manager (for Pulumi stacks).

Step 7: Monitor SSL Certificates

An expired SSL certificate on the Pulumi API or your custom state backend causes the Pulumi CLI to fail with TLS errors — every developer and CI runner running pulumi commands is blocked simultaneously.

  1. Add Monitor → SSL Certificate.
  2. Domain: api.pulumi.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days.
  5. Click Save.

Repeat for app.pulumi.com and any custom domains for self-managed backends.

# Verify certificate expiry manually
openssl s_client -connect api.pulumi.com:443 2>/dev/null | openssl x509 -noout -dates

Pulumi-managed certificates: Pulumi Cloud manages their own TLS certificates, so an expiry there is their incident to handle. But monitoring it means you get alerted before Pulumi does (or at the same time) — giving you a head start on communicating the outage to your team and activating runbook procedures for continuing manual infrastructure operations.

Step 8: Configure Alerting

In Vigilmon under Settings → Notifications, set up your alert routing:

| Monitor | Trigger | Action | |---|---|---| | Pulumi Cloud API | Non-200 | All pulumi up/destroy/preview blocked; check Pulumi status page; halt deployments | | Pulumi console | Non-200 | Dashboard unavailable; CLI may still work; check status.pulumi.com | | S3/Azure/GCS state backend | Non-403/200 | Self-managed state backend degraded; Pulumi state reads/writes will fail | | Webhook consumer | Non-200 or non-405 | Deployment notifications silenced; manually check deployment status via CLI | | AWS/Azure/GCP provider | Non-200 | Cloud provider degraded; Pulumi can read state but resource operations may fail | | SSL certificate | < 30 days to expiry | Renew certificate; alert DevOps team with renewal SLA |

Alert after: 2 consecutive failures for HTTP monitors.

Common Pulumi Cloud Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Pulumi Cloud API outage | API monitor fires; all pulumi CLI commands fail | | Self-managed S3 backend degraded | S3 monitor fires; state reads fail, pulumi up hangs or errors | | Webhook consumer down | Webhook monitor fires; deployment outcomes stop being reported | | AWS STS degraded | AWS provider monitor fires; Pulumi can't authenticate to provision resources | | Pulumi console down (API healthy) | Console monitor fires; CLI works but dashboard is unavailable | | SSL expiry on Pulumi API | SSL monitor at 30 days; TLS errors block all CLI commands | | State lock left by crashed pipeline | Backend monitor stays green; repeated CI failures are the signal (monitor separately) | | Azure Blob backend degraded | Azure Blob monitor fires; Pulumi state writes fail, updates partially applied | | Network partition between CI and Pulumi | All Pulumi monitors fire; CI runners can't reach state backend or API |

Pulumi's power is its ability to manage complex infrastructure declaratively — but that power depends on the state backend and API being reliably reachable. A Pulumi Cloud outage or a degraded self-managed state backend doesn't just pause deployments; it can leave infrastructure in a partially updated state that takes careful manual intervention to resolve. Vigilmon's external monitoring gives your DevOps team early warning before failed deployments cascade into production incidents.

Start monitoring your Pulumi Cloud infrastructure in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles