Prometheus exporter for Dexcom G6 blood sugar data + prometheus rules
  • Smarty 67.6%
  • Makefile 32.4%
Find a file
2026-01-25 11:46:23 +00:00
templates Helm chart admin: Add license & icon 2026-01-24 23:49:52 +00:00
.gitignore First cut 2026-01-09 22:41:01 +00:00
.helmignore First cut 2026-01-09 22:41:01 +00:00
Chart.yaml Bump version in preparation for next release 2026-01-25 11:46:23 +00:00
icon.svg Helm chart admin: Add license & icon 2026-01-24 23:49:52 +00:00
LICENSE Helm chart admin: Add license & icon 2026-01-24 23:49:52 +00:00
Makefile Implement a "Friendly name" of the dexcom user 2026-01-24 13:20:09 +00:00
README.md Implement a "Friendly name" of the dexcom user 2026-01-24 13:20:09 +00:00
values.yaml Implement a "Friendly name" of the dexcom user 2026-01-24 13:20:09 +00:00

Dexcom Exporter

This helm chart provides a Prometheus exporter for Dexcom data - a blood sugar monitor.

It uses the Dexcom API to retrieve data, and thus needs suitable credentials. Using the same credentials as you would use for the Dexcom Follow App should work.

This also includes:

  • a ServiceMonitor: will cause Prometheus to automatically scrape the exporter for data.

  • a few PrometheusRules to create alerts for when the blood sugar level is too high or too low.

The k8s cluster must already have Prometheus installed as this provides the Custom Resource Definitions for ServiceMonitors and PrometheusRules.

Note that this helm chart only installs the prometheus exporter for a single Dexcom user. If you need to monitor multiple Dexcom users, you need to install multiple instances, each with their own set of credentials.

Values

Most values for the helm chart are pretty vanilla and uninteresting enough to only be documented as comments in values.yaml.

For a working installation, you probably only need to set these values:

dexcom:
  username: "YourDexcomUserName"
  password: "YourDexcomPassword"
  region: ous
  friendlyName: "Little Red Riding Hood"

dexcom.username

Username for the Dexcom Share user (not the follower)

dexcom.password

password for the Dexcom Share user

dexcom.region

Regions: Dexcom seems to split the world into 3 regions:

  • us: the USA
  • jp: Japan
  • ous: Everthing else ("outside the US"?, but Japan is neither inside nor outside the US?)

I.e. their naming is not consistent and does not follow commonly used standards.

Note that specifying the wrong region will cause authentication to fail.

dexcom.friendlyName (optional)

The human-readable human name of the person whose blood sugar is being monitored.

This is used in alerts in preference over dexcom.username as usernames are not really "human" enough. E.g. your dexcom username may be something like joebloggs76; setting dexcom.friendlyName to Joe Bloggs makes for nicer alerts.

Alerts

The installation includes PrometheusRules which create alerts for high/low blood sugar levels.

By default there 2 main types of alerts:

  • BloodSugarLevelLow (with a label: action: needsGlucose)
  • BloodSugarLevelHigh (with a label: action: needsInsulin)

Each alert comes in 2 varieties with different severity labels: warning and critical.

At the moment the alerts levels are only expressed in units of mmol/ltr. (US: Users: Sorry: you have to convert from mg/dl)

The defaults are:

Glucose Level Alert
x < 3.1 alertname=BloodSugarLevelLow severity=critical action=needsGlucose
x < 4 alertname=BloodSugarLevelLow severity=warning action=needsGlucose
4 <= x < 11 No alert
11 <= x alertname=BloodSugarLevelHigh severity=warning action=needsInsulin
20 <= x alertname=BloodSugarLevelHigh severity=critical action=needsInsulin
no data alertname=NoBloodSugarData severity=warning

The levels can be customised in the rules section (see values.yaml for details).

As a design choice: alerts are specific to a dexcom user; customising the alert levels for one user will not affect other users.

In addition, all alerts will have these labels:

  • dexcom_username=xxxx : the username the alert pertains to, as given in .Values.dexcom.username
  • category=bloodsugar: an easy way to identify blood sugar related alerts, regardless of which user it pertains to.

AlertManager

Note that when blood sugar level is very high (e.g. > 20), prometheus will fire both alerts for BloodSugarLevelHigh - i.e. both the one with severity=warning and the one with severity=critical (same thing happens with the BloodSugarLevelLow alerts with levels < 3.1).

This is not a problem as the default AlertManager configuration inhibits warning alerts when a critical alert with the same name is firing. This is due to Alertmanager's default configuration which contains:

inhibit_rules:
- source_matchers:
  - severity="critical"
  target_matchers:
  - severity=~"warning|info"
  equal:
  - namespace
  - alertname

However: This default configuration is a problem if you monitor multiple dexcom users: If:

  • Dexcom user Alice has a blood sugar level of 12: Prometheus will an alert with dexcom_username=Alice, alertname=BloodSugarLevelHigh & severity=warning
  • and dexcom user Bob has a blood sugar level of 22: Prometheus will fire an alert with dexcom_username=Bob, alertname=BloodSugarLevelHigh & severity=critical
  • and the two dexcom exporters are installed in the same kubernetes namespace

Then Alertmanager will inhibit the alert for Alice ! (a similar scenario exists for alertname=BloodSugarLevelLow)

To fix this problem, do one (or more) of:

  • Install the dexcom exporters in separate namespaces
  • Tweak the Alertmanager configuration to include dexcom_username in the list under equal

Metrics Exposed

The metric names and descriptions are documented in the README.md of the container (adjust URL for the exact container version in use).

The metrics will be decorated with a few labels:

  • dexcom_username : The user name of the dexcom user

  • dexcom_eu_username: (deprecated) The user name of the dexcom user. This label only exists for backward compatability; it will be removed in a later release.

  • job: Usually dexcom-exporter, as it is derived from the helm release name chosen at installation time, unless nameOverride or fullnameOverride is set.

Prometheus will also add other (standard) labels like endpoint, instance, namespace, pod, and service.