Telemetry

kguardian’s broker performs a daily anonymous version check-in: it asks version.kguardian.dev for the latest released versions, and that request is also how the project learns an installation exists. It powers the update notice in the UI (and GET /version on the broker), and it is the only usage signal the project collects. It is enabled by default and can be disabled at any time — we’d rather you know exactly what it does and choose, than never notice it.

Exactly what is sent

One HTTPS GET per day to https://version.kguardian.dev/v1/check with these six query parameters — nothing else, ever:

Field	Example	What it is
`install`	`4f7c…-…`	Random UUID generated once at first startup. Contains no cluster or user information — it only lets repeated check-ins from the same install be counted once.
`broker`	`1.11.1`	Broker version.
`chart`	`1.13.2`	Helm chart version (`unknown` outside the chart).
`k8s`	`v1.33.1`	Kubernetes version, captured by the chart at install/upgrade time.
`nodes`	`3`	Count of distinct live nodes the controller has observed — a coarse size signal, not an inventory.
`arch`	`x86_64`	Broker CPU architecture.

The exact field list is pinned by a unit test in the broker (check_params_send_exactly_the_documented_fields) — a change to the wire contract fails the build unless this page changes with it. Not sent: cluster names, namespaces, pod names, IPs, hostnames, labels, traffic data, syscall data, or anything derived from your workloads. Server side: requests are logged with coarse, Cloudflare-provided country-level geo. IP addresses are not persisted.

What you get back

The response lists the latest released component versions. The broker surfaces it at GET /version:

{
  "broker": "1.11.1",
  "chart": "1.13.2",
  "telemetry_enabled": true,
  "latest": { "chart": "1.13.2", "broker": "1.11.1" },
  "checked_at": "2026-07-19T12:00:00",
  "update_available": false
}

The web UI uses this for its update notice, and the AI assistant can answer “am I running the latest version?” from the same data.

Disabling it

helm upgrade kguardian oci://ghcr.io/kguardian-dev/charts/kguardian \
  --reuse-values --set telemetry.enabled=false

Disabled means disabled: the broker spawns no check-in task and makes no request at all — not a suppressed or batched one. GET /version keeps working, but latest/update_available stay empty.

Air-gapped and egress-restricted clusters

Nothing to do. Failures are silent by design — if the endpoint is unreachable, the broker logs at debug level and tries again the next day. There is no retry storm, no startup dependency, and no functional impact.

Self-hosting the endpoint

telemetry.endpoint can point at your own service (the reference implementation lives in cloudflare/version-service):

telemetry:
  endpoint: https://version.internal.example.com/v1/check

Getting Started

Core Concepts

User Guides

Policy Gallery

CLI Reference

Advanced

Roadmap

Exactly what is sent

What you get back

Disabling it

Air-gapped and egress-restricted clusters

Self-hosting the endpoint

​Exactly what is sent

​What you get back

​Disabling it

​Air-gapped and egress-restricted clusters

​Self-hosting the endpoint

Exactly what is sent

What you get back

Disabling it

Air-gapped and egress-restricted clusters

Self-hosting the endpoint