Public name cache freshness and origin reachability are different clocks. In Workers you can correlate Request.cf hints with origin logs and weekly audits to ensure GeoDNS answers still match where users actually land. For pattern-level DNS trade-offs (GeoDNS vs Anycast, regional matrices), use 2026 Halo-style global entry: GeoDNS, SSH latency & node matrix. For split-horizon catalogs, resolver stickiness, and artifact p95 on the data plane, see Split-horizon vs GeoDNS TTL, cache stickiness & cross-region SSH. This article narrows the lens to Worker-layer thresholds, origin session stickiness, and a practical acceptance sheet for US West versus Hong Kong / Singapore when your control plane is SSH to a remote Mac fleet.
Why add Workers when managed DNS already does health checks? DNS health moves answers on the order of TTL; Workers can steer individual requests in seconds, attach cookies or signed headers for sticky sessions, and gate origins with composite predicates (for example HTTPS 200 from a canary path and a lightweight TCP open toward an admin port). That does not replace DNS—it compresses the gap between “resolver thinks you are healthy” and “this browser tab should not bounce continents mid-session.” Pair the table below with the public connectivity notes in the Help center so on-call and developers share one vocabulary.
| Mode | Public DNS TTL | Health probe interval | Failover gate (examples) |
|---|---|---|---|
| Steady state (public A/AAAA) | 300–900 s | Worker composite 5–15 s | 3 consecutive failures or >50% failures in a 30 s window |
| Pre-maintenance | 60–120 s (start ≥ one full prior TTL before the window) | Same as steady | Human ack + paste a signed dig snippet into the change ticket |
| Direct origin liveness | — | 10–30 s | 5 min sustained dead → steer to secondary origin or serve a graceful degradation page |
| SSH batch probe (BatchMode) | — | 1–5 min | p95 > weekly baseline ×1.4 for 15 min → open a path ticket (attach traceroute) |
| Layer | What it optimises | Typical failure symptom | Who owns the knob |
|---|---|---|---|
| GeoDNS only | First connection geography from resolver hints | Sticky resolver + long TTL hides a sick PoP | DNS / platform team |
| Worker in front of HTTPS | Per-request routing, A/B, auth at edge | Logic bug sends APAC users to US-West origin | App + edge SRE |
| Regional SSH alias | Deterministic control plane for CI and humans | Marketing hostname drift vs what SSH actually uses | Infra + developer experience |
time ssh -o BatchMode=yes … exit using a read-only account so pager noise separates SSH handshakes from application errors.DNS / Worker routing
DNS decides which set of edges a name points at; Workers decide, per request, which origin pool should answer when those edges are already hot. Blindly cutting TTL to sixty seconds everywhere usually increases resolver churn without buying you better SSH—because SSH often bypasses the same hostname your marketing site uses. Instead, validate a stickiness key at the Worker (cookie or stable header) and keep the admissible origin set narrow so distributed teams do not hop continents mid-session when one pool flaps.
Log enough to reconcile disputes: edge colo, chosen origin id, health snapshot version, and (for internal tools) the DNS answer the client would have seen from a corporate resolver. Weekly, compare Worker-selected geography with GeoDNS intent; if large deltas appear, fix data before you chase “mysterious latency.” For HTTPS, prefer explicit cache keys and short-lived signed URLs at the edge; for automation, publish deterministic regional SSH hostnames even when the brand stays unified.
Origin path: HTTPS vs SSH
Treat the origin path as two lanes. Lane one is HTTPS (dashboards, webhooks, artifact downloads through a CDN or Worker). Lane two is SSH (jump hosts, git over SSH, remote shells on your remote Mac builders). Anycast is seductive for HTTPS; it is a poor stand-in for predictable SSH unless you validate the actual TCP path engineers use. Keep a regional fixed alias per PoP for SSH and document which hostname marketing promises versus which hostname CI must use.
Session stickiness is cheaper to reason about at the Worker than by hammering DNS: verify the stickiness token, cap concurrent origin connections, and shed load to a warm secondary before you poison user trust with random continent jumps. On the origin, align connection limits with Worker concurrency so you do not create a thundering herd when health flips. For artifacts, co-locate registry replicas and pull-through caches with the runner region so acceptance on SSH does not mask miserable docker pull times—otherwise you pass the handshake test and still ship slow builds.
Cross-region collaboration & SSH handshake p95
Teams spanning US West and Hong Kong / Singapore should sample first full SSH establishment (TCP plus key exchange through first authenticated channel) weekly and track p95 against a written baseline. If p95 exceeds baseline by roughly forty percent for fifteen minutes, treat it as a network incident until traceroute and submarine-cable NOTAMs say otherwise—not as “SSH is slow today.” Record small artifact HEAD/GET TTFB p95 on the same dashboard: if only SSH degrades, suspect auth, MTU, or jump-host saturation; if both degrade, suspect wide-area loss.
Operationalise collaboration: designate a single “golden hour” overlap window, freeze non-urgent DNS changes outside that window, and require two independent observers (for example edge synthetic plus office VLAN probe) before automatic trans-Pacific failover. Human acknowledgement for ocean-spanning flips still beats chasing BGP flaps that your users feel as mysterious disconnects.
| Acceptance item | US West ↔ HK / SG (guidance) | Ops note |
|---|---|---|
| First SSH establish p95 | Weekly baseline per environment; alert if > 1.4× baseline for 15 min | Fix key type, ProxyJump, and MTU across samples so weeks compare fairly |
| Artifact HEAD/GET | Log TTFB p95 beside SSH on one sheet | Split-brain symptom: HTTPS fine, SSH bad → check jump path and auth; both bad → WAN |
| Failover drill | Canary resolver or bench /etc/hosts; never experiment on prod zones unannounced |
Attach signed dig + mtr to the ticket for auditability |
# Scripted SSH handshake probe (read-only account; no secrets in tickets)
time ssh -o BatchMode=yes -o StrictHostKeyChecking=accept-new \
-o ConnectTimeout=12 user@ssh.sg.example 'echo ok'When the matrix is green, lock PoP and hostnames for the quarter and let day-to-day operations touch only synthetic health and SSH batch probes—cheaper than renegotiating DNS every sprint. To turn the checklist into hardware, provision or extend Mac capacity early: confirm regions and billing on Pricing, open Purchase when you are ready to commit, and keep measuring for two weeks after cutover so Workers, DNS, and SSH baselines stay aligned.