Skip to main content
Install is Day 1. This is everything after: how to know it’s healthy, how to upgrade it, how to handle the API key, and what to do when something looks off. Every command uses read-only checks or standard Helm operations.

​
Daily health check

A single glance tells you ChangeGuard is doing its job.
Operator and collector are Running / 1/1, and recent collector logs show successful pushes with no repeated 401 or egress errors.
In the product, the dashboard’s connection indicators (“Agent connected”, “Workloads detected”, “Security scanning”) are the fastest confirmation that data is flowing.

​
Health endpoints

If Kubernetes marks a pod Ready, these probes are passing. You rarely need to hit them directly; use kubectl get pods first.

​
Upgrades

ChangeGuard upgrades are standard Helm upgrades. Analysis and scoring logic live in the control plane and update on the ChangeGuard side — so most improvements reach you without any cluster change. In-cluster upgrades are for the operator, collector, and scanners.
Check for version skew. Keep the operator and collector on the same chart family. If you installed long ago from a pinned manifest or an old install.sh, confirm you’re on the current chart before assuming a feature is present. When in doubt, re-run the current install command over the existing release — Helm reconciles it in place.

​
API key handling

The collector authenticates with a single API key, stored in the changeguard-credentials Secret (key api-key) in changeguard-agent. To move to a new key:
1

Create the new key

In app.changeguard.ai → API keys, create a new key and copy it once.
2

Update the in-cluster Secret

3

Confirm the collector reconnects

Watch the logs for a clean push with the new key, then retire the old key in-app.
Know the current limitation. Key revocation behavior and its durability across control-plane restarts are not fully documented, and there is no self-serve key-rotation API today. For high-assurance rotation (for example, after a suspected key exposure), rotate the key and contact support to confirm the old key is fully invalidated. Treat any exposed key as compromised until confirmed.

​
Notifications

ChangeGuard can notify your team when it detects a change or an incident. Configure destinations in-app. Wire notifications to the channels your on-call already watches so signal lands where people look. See Integrations for the supported destinations and what each one carries.

​
Scaling & footprint

The collector is intentionally small (~50m CPU / 64Mi memory requested; 200m / 128Mi limits) and stateless — no PersistentVolumeClaims. On very large clusters, if you see the collector hitting its memory limit, raise the limit via Helm values rather than running multiple collectors:
After any resource change, confirm the collector returns to Ready and resumes pushing.

​
Security scanners

The optional scanners (CIS via KubeBench, CVE via Grype, deprecated-APIs via Pluto, SBOM via Syft, runtime via Falco) run as jobs in changeguard-agent. They are plan-gated — availability depends on your plan. Their findings are sent to the control plane; the scanned images and manifests are not.

​
Troubleshooting quick reference

​
When to contact support

Reach support@changeguard.ai for: confirming full key invalidation after exposure, full-tenant data erasure (in-app removal is per-cluster), proxy-only network environments, and anything where the docs don’t give you a confident answer. We would rather you ask than guess.