IncidentCloudflaredConfigChanged

Severity: warning · Fires after: 0m · Rule: central/prometheus/rules/edge.yml

What it means

The edge tunnel's applied ingress revision changed. Someone — or something — rewrote the routing outside version control.

Warning, not critical: a change is not inherently bad, it just must not pass unnoticed.

Expression

changes(cloudflared_orchestration_config_version[1h]) > 0

Why this alert exists

The jspwiki tunnel is cloud-managed (config_src: cloudflare). Its ingress table lives in the Cloudflare dashboard, not in this repo. The host's /etc/cloudflared/config.yml is a shadow copy that cloudflared ignores — editing it does nothing.

So the routing that actually serves your traffic can change with no local signal at all. This was the missing signal when a relocation left monitor.jakefear.com pointing at a powered-off host at revision 20.

Alert on the metric, not the log line

cloudflared re-logs Updated to new configuration on every reconnect with the same revision. Alerting on the log line produces false alarms on ordinary connection churn; alerting on the metric's value does not. Keep it that way.

First checks

Read the live table from the journal — this is the authoritative view:

ssh jakefear@cloudflare \
  'journalctl -u cloudflared --since "2 days ago" --no-pager | grep "Updated to new configuration" | tail -3'

Compare the hostnames and origins against what you expect. Look for origins pointing at hosts that are down.

How to clear

The alert self-resolves after an hour without further changes. The real question is whether the change was intended — if not, correct it in the cloud config (Zero Trust → Tunnels → jspwiki → Public Hostnames), not in config.yml.

Notes