Summary

Nightly deployment-services-e2e has an intermittent Cloudflare tunnel failure cluster over the last 7 days. The failures are not every run, but when they occur the signature is consistent: cloudflared starts, then either exits before a tunnel URL appears in nemoclaw status, or a trycloudflare.com URL appears but serves repeated 502 responses until the test times out.

Observed failures

Frequency

There were also several incidental cloudflared was not running cleanup/status lines in other failed runs, but those were not counted above unless the tunnel behavior was clearly the root failure.

Expected

nemoclaw tunnel start should either:

1. keep cloudflared running and expose a tunnel URL in nemoclaw status, and
2. only report success once the URL actually serves the OpenClaw dashboard, or
3. fail with actionable diagnostics explaining why cloudflared exited or why Cloudflare returned 502.

Actual

The E2E intermittently observes one of these states:

• cloudflared starts but stops before nemoclaw status exposes a URL.
• A trycloudflare.com URL is exposed, but repeated probes return 502 until the test fails.

Suggested investigation

• Capture and upload cloudflared logs on deployment-services-e2e failure.
• Distinguish Cloudflare service/quick-tunnel instability from local OpenClaw dashboard readiness.
• Add a readiness gate before surfacing or accepting the tunnel URL.
• Consider longer/backoff-based retry for transient 502, but only if local dashboard health is confirmed.
• If this depends on unauthenticated Cloudflare quick tunnels, consider whether nightly should use a more deterministic tunnel mode or mock.