Probe target should be operator-configurable: us.proxy flaps because the probe hairpins through Cloudflare back to the origin host (3.5ms service, 136-1502ms measured)

[emooreatx]

us.proxy is flapping operational → degraded → outage on the public status page while the proxy answers in 3.5 ms. The proxy is not the problem; the probe route is.

What is actually being measured

The status node probes the US proxy at proxy1.ciris-services-1.ai. That record is Cloudflare-proxied:

Cloudflare:  A  proxy1.ciris-services-1.ai -> 108.61.242.236   proxied=True
resolves to: 104.21.42.160, 172.67.163.135      (CF edge)

So a probe originating on the origin host leaves the machine, reaches Cloudflare's edge, and comes back to the same machine. Measured from that host, three ways:

direct to the container            3.4 – 4.3 ms      stable
via proxy1.ciris-services-1.ai   136 – 1502 ms      ~10x spread   <- what you measure
via proxy1.ciris-services-2.ai   515 –  594 ms      stable        (EU)

Any threshold inside that 136–1502 ms band will flap, and the recorded transitions show exactly that — operational -> outage at 15:04:21, outage -> degraded 62 seconds later, with upstream_status: operational throughout and every LLM provider sourced from cirisproxy.us reading healthy in the same payload.

Confirmed from the status container's live sockets that this is the route in use — connections to 172.67.163.135:443 and 104.21.42.160:443, i.e. CF edge, not an origin or a docker name.

EU is only healthy by accident

proxy1.ciris-services-2.ai is grey-clouded — it resolves straight to 46.224.81.217. So the EU probe already does the right thing: it reaches the service. US and EU latency figures are therefore not comparable and never have been; one includes a CDN round trip and the other does not.

A direct route now exists

Bridge-side, ciris-proxy has been added to the lens_cirislens network, which ciris-status is already on. Verified after the change, from inside the status node's network namespace:

docker DNS:  ciris-proxy -> 172.20.0.5      (also resolves as `proxy`)
probe:       http=200  3.2 ms / 3.8 ms / 5.0 ms

So http://ciris-proxy:4000/health/liveliness is available and is ~400x faster and far more stable than the current target. This did not change what the adapter probes — that is the ask here.

The ask

Make the probe target operator-configurable, so the deployment can point a component at the service rather than at whatever public route happens to exist.

On mechanism, one thing worth stating plainly rather than assuming: the operator's preference is environment variables set by the bridge. That conflicts with DEPLOY.md §2's zero-env contract, which we have been careful to keep — it is why --diagnostics was built as a CLI flag rather than accepting CIRIS_DIAGNOSTICS. So the requirement is operator control of probe targets; the mechanism is yours. A CLI flag or a config:* CEG object both satisfy it without breaking the contract, and if env vars are genuinely the right answer for this class of setting, that is a deliberate change to §2 rather than something to slip in.

Worth noting the general principle too: a status page that probes its own service through a CDN is measuring the CDN, and from the origin host it is measuring a hairpin no real user ever traverses. Whatever the mechanism, targeting the service is the correct measurement.

Bridge-side note

Adding the network required recreating the proxy container. Caddy's active health checker marked the upstream down for ~30 s during that window and returned no upstreams available (503) to a handful of requests before logging host is up. Public path is back to 200. Flagging it because it was a real, if brief, user-visible cost of creating this route.

[emooreatx]

The measurement analysis is right, and the mechanism you're asking for already exists — status.region.<r>.proxy_url is a signed config:* object and has been since the zero-env cut-over. The probe target was never hardcoded. It was configured, to the public route:

status.region.us.proxy_url   = "https://proxy1.ciris-services-1.ai"
status.region.us.billing_url = "https://billing1.ciris-services-1.ai"
status.region.us.infra_url   = "https://billing1.ciris-services-1.ai/health"
status.region.eu.proxy_url   = "https://proxy1.ciris-services-2.ai"

(read live from the box just now). So this needs no code change and no §2 amendment — config:* is exactly the "operator control without env vars" answer §2 was written to enable.

Retargeting it

docker exec ciris-status ciris-status config set \
  status.region.us.proxy_url '"http://ciris-proxy:4000"' \
  --home /data --key-id ciris-status-1

Three things I'd have gotten wrong without checking, so they're worth writing down:

--key-id must be ciris-status-1. That is what the container boots with (docker inspect → ["--home","/data","--key-id","ciris-status-1"]). I first ran the read with --key-id ciris-status and got (no config for key "status.region.us.proxy_url") for every key — not an error, just silence, which reads exactly like "unset" and would have sent me off writing a feature that already existed. A config set under the wrong key-id would be worse: it would appear to succeed and change nothing the adapter reads.

The path is /v1/status, not /health/liveliness. fetch_service_status appends /v1/status to the configured base, so the value is a base URL with no path. Verified from inside the status container:

http://ciris-proxy:4000/v1/status -> 200
{"service":"cirisproxy","status":"operational","providers":[{"provider":"deepinfra",...

Identical payload shape to the public route, which matters: the providers[] array is what feeds the LLM-provider components sourced from cirisproxy.us. Retargeting loses the path measurement and nothing else.

No restart. The poll loop re-resolves config:* from the node's own corpus each cycle, so it takes effect within ~60 s.

Why it flaps, exactly

fetch_service_status judges on excess over the path's floor: Probe::ok(latency, 1000, baseline_ms) with a 5 s client timeout. status.region.us.latency_baseline_ms is unset — so the floor is 0, the threshold is a flat 1000 ms, and your measured 136–1502 ms band straddles it. Over 1000 ms → degraded; a transport failure or >5 s → outage, which is the operational -> outage at 15:04:21.

The margin is as thin as you'd expect. Probing the public route from the box a few minutes ago: 978 ms — 22 ms of headroom.

The one thing to decide deliberately

This trades one measurement for another, and I'd rather say so than let it happen quietly. After retargeting, us.proxy measures the service and nothing measures the public path to it. Your own bridge-side note is the case in point: during the container recreation, Caddy returned no upstreams available (503) for ~30 s. A public-path probe catches that. http://ciris-proxy:4000 does not — it would have reported the service healthy through the entire user-visible outage.

That is not an argument against the change. "A status page that probes its own service through a CDN is measuring the CDN" is correct, and from the origin host it is measuring a hairpin no user traverses. It is an argument that the right end state is both, which is FSD/MULTI_VANTAGE.md: one vantage cannot measure the service and the path at the same time, because the two are distinguished only by where you stand. Same-host = service health; off-host = path health. This is attesting_key_id as the vantage axis, and it is why observation:reachability:v1 carries via rather than asserting a global truth.

Also worth noting the asymmetry doesn't disappear — it inverts. Post-change US measures the service (3.4 ms) while EU still measures a transatlantic path (515–594 ms), and both baselines are unset, so EU spends half its 1000 ms budget on physics. latency_baseline_ms is the knob built for that (D4 / FSD §3.4); it should be set alongside — US 0, EU ~500 — or EU inherits the flap US just shed.

Happy to apply both (us.proxy_url → the docker name, eu.latency_baseline_ms → 500) and watch a few cycles. Say the word.