deployment-operations

Diagnose and operate Helm and Terraform monitoring stack deployments on Kubernetes clusters.

3|Updated May 1, 2026
One-click install
npx skills add https://github.com/MaterializeInc/materialize-monitoring --skill deployment-operations-materializeinc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: deployment-operations
Source: https://github.com/MaterializeInc/materialize-monitoring/tree/main/.claude/skills/deployment-operations
Command: npx skills add https://github.com/MaterializeInc/materialize-monitoring --skill deployment-operations-materializeinc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Standing up or debugging a Materialize monitoring stack often fails in confusing ways: pods that will not start, storage that will not attach, config changes that silently do nothing, and teardowns that hang. This Skill routes you to the right troubleshooting documentation and encodes the operational habits that prevent wrong diagnoses. ## Core Features & Use Cases - Symptom-indexed troubleshooting routing: Points you to docs organized by error strings and failure symptoms rather than by component. - Safe cluster targeting: Enforces explicit kubeconfig context naming so install, restart, and delete operations never hit the wrong cluster. - Diagnostic discipline: Covers timeout misdiagnosis, expired cloud credentials, stale metrics assertions, and ConfigMap versus pod-restart verification. - Use Case: A helm upgrade of the monitoring stack times out in CI. Instead of raising the timeout, you inspect events first, capture diagnostics with test/e2e/dump-diagnostics.sh before the kind cluster dies, and find the real cause in the previous container's logs. ## Quick Start Use the deployment-operations skill to diagnose why the monitoring stack pods are not starting after my Helm install.

Frequently Asked Questions about deployment-operations

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I troubleshoot a Helm install that times out?

A Helm timeout almost never means something was slow; assume something is broken rather than raising the timeout. Inspect Kubernetes events first, then pod status, then the previous container's logs to find the actual failure.

How do I safely tear down a Kubernetes monitoring stack?

Read the uninstalling documentation before tearing anything down, because teardown deadlocks by default. Also delete PVCs deliberately, since volumeClaimTemplates are immutable and persistentVolumeClaimRetentionPolicy defaults to Retain.

Why did my Helm upgrade succeed but the config change did nothing?

A green helm upgrade is not evidence the change took effect. Alloy's config arrives partly through envFrom, and environment variables are fixed at container start, so check both the ConfigMap and whether the pod actually restarted.

Can I test workload identity on a local kind cluster?

No, workload identity cannot be tested on kind because there is no OIDC issuer an IAM provider trusts. IRSA, GKE Workload Identity, and Entra Workload ID are only exercised against real clouds; chart validators assert the config shape at render time instead.

Why did everything in my cluster break at once?

An impossibly broad failure usually means expired cloud credentials, since AWS and GCP sessions commonly last 12 hours and lapse mid-afternoon. Re-authenticate first, then debug individual components.