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 AI 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 AI upgrades are standard Helm upgrades. Analysis and scoring logic live in the control plane and update on the ChangeGuard AI 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 AI 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 (a single lightweight pod, a ~13MB image) and stateless — no PersistentVolumeClaims. As of chart 5.3.6 / operator v5.3.5 it runs with default resources of 25m CPU / 64Mi memory requested and 500m CPU / 512Mi memory limits (grounded in measured usage of ~9m CPU / 21Mi on a small cluster). On very large fleets, raise the limits 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.