[Bug]: T3 Connect link returns 504 Gateway Timeout from relay, client shows bare "failed"

Steps to reproduce

T3 Code desktop 0.0.45 (Electron 44.4.2), macOS.
Settings → Connections → enable T3 Connect for the local environment.
The link challenge and the local link proof succeed; the final link request fails.

Actual behavior

Toast: "Could not update T3 Connect - https://relay.t3.codes/v1/client/environment-links failed", with no reason.

DevTools shows the relay itself answered the POST with 504 Gateway Timeout (application/json, 43 bytes), roughly 9-10 s after the request was sent. 504 is not in RelayEnvironmentLinkErrors, so the client drops the reason.

Trace ID (traceparent): 4684d7d140f34f0393d42744d240e207
cf-ray: a46cb3018961253d-JNB
Time: Wed, 07 Oct 2026 11:52:31 GMT
Three earlier attempts the same day, within about 5 minutes starting 10:55 UTC, failed the same way.

Expected behavior

The environment links, or the client shows the relay's reason.

Related: #14070, #14580

Note

Grok responding on behalf of Julius.

Thanks for the trace ID and timestamps. I confirmed two separate problems here.

1. The 504 comes from the relay's own request deadline. The relay cuts off any API request after 9s and returns 504 {"error":"relay_request_deadline_exceeded"}. That body is exactly 43 bytes, which matches what you saw in DevTools.

infra/relay/src/http/Api.ts:174 sets RELAY_REQUEST_DEADLINE_MS = 9_000.
infra/relay/src/http/Api.ts:189-208 is the relayRequestDeadline wrapper that returns the 504.

Something inside linker.link (Api.ts:863) is stalling. That's most likely managed-endpoint provisioning or persistence, but I can't tell which from the client. Someone with relay access needs to look up trace 4684d7d140f34f0393d42744d240e207, whose span tree will show which child span stalled. The same applies to your three earlier attempts around 10:55 UTC.

2. The client drops the reason and the trace ID. This is the bug we can fix in the client.

linkEnvironment declares RelayEnvironmentLinkErrors (packages/contracts/src/relay.ts:613-621, used at :1074). That list has no 504 member, and the deadline body ({error: ...}) doesn't match any tagged error schema.
Because of that, relayRequestError (packages/client-runtime/src/relay/managedRelay.ts:309-318) only sets relayError and traceId when the cause is a RelayProtectedError. Here both are left unset.
decodedRelayClientError (apps/web/src/cloud/linkEnvironment.ts:116-128, with the same code in apps/mobile/src/features/cloud/linkEnvironment.ts:90) then shows only ".../environment-links failed". The traceparent the relay sent back is lost as well.

Proposed fix:

Add a tagged RelayRequestDeadlineExceededError (httpApiStatus: 504, traceId) to the contracts.
Have relayRequestDeadline return that error with the span's traceId, and add it to RelayProtectedError and the endpoint error lists.
As a fallback for status codes the contract doesn't declare, have the client keep the HTTP status and the traceparent response header so the toast reads something like "relay timed out (504), trace …".
Retrying a link that timed out should also be safe. It's worth checking that a half-finished link doesn't leave a stale tunnel or record behind.

Relation to #14581 / #14580: #14581 only adds provisioningStage to the existing 503 ManagedEndpointProvisioningFailed error. It would not show anything for this 504, because the deadline fires before any tagged error is produced. If provisioning turns out to be the slow step, this is probably closely related to #14155 (provisioning plus HTTP 504) and #14070. #5729 is the same class of client problem, an undeclared status whose body gets dropped.

Workaround: Retry later. The stall is on the relay side, and nothing changed on your machine will fix it.

Same issue on macOS, and I captured it in DevTools. Every T3 Connect link attempt fails, and "retry later" hasn't helped for over 2 hours.

Relay response: POST https://relay.t3.codes/v1/client/environment-links returns 504 with body {"error":"relay_request_deadline_exceeded"}. DevTools shows 9.14s spent waiting for the server response. Before it, environment-link-challenges returns 200 in 117ms and the local link-proof returns 200 in 24ms. The request had managedTunnelsEnabled: true, so managed-endpoint provisioning is a likely place for the stall.

traceparent: 00-a8c1832f40f900cb029407d9666b9b3c-0baf648c44f4bce6-01
Trace ID: a8c1832f40f900cb029407d9666b9b3c
Date: 2026-10-07 13:53:19 GMT

Environment

T3 Code (Nightly) desktop app 0.0.46-nightly.20261007.2774, macOS 27.0 arm64
The desktop app hosts the local server and the UI is in the desktop app
DNS and the network to relay.t3.codes are fine, with no proxy

Repeated failures (local server trace). Each local link-proof was followed by the UI giving up about 9s later. relay-config is never reached.

link-proof (UTC, 2026-10-07)	gap to failure
11:27:12	9.2s
11:27:23	9.2s
11:29:31	9.4s
11:30:04	9.4s
11:31:01	9.2s
11:32:45	9.1s
13:42:30	9.6s
13:53:10 (DevTools capture)	9.16s

The 11:27–11:32 attempts overlap the window in the original report. Separately, the Connections page shows this host as "Relay offline", and the client's relay discovery reports "Managed endpoint health request failed" for this host's previously linked managed environments.

Update: JNB appears in 3 of ~5 ray-ID'd reports of this 504 (#14155, the original report here, mine), but it has also been seen via DAR (#14070), FRA (#14070) and SIN (#7458). Since the relay runs as a Worker with Postgres behind Hyperdrive (per #15411), this may be round-trip latency from locations far from the database, multiplied across the link transaction, rather than a JNB-specific fault. Worth checking where the time goes in trace a8c1832f40f900cb029407d9666b9b3c.

Triaged via t3 triage by Claude Code (Opus 5.5).

Same failure on Windows 11 with T3 Code (Nightly) desktop 0.0.46-nightly.20261008.2801 on 2026-10-08. This adds another location: every Ray ID here is from ACC (Accra). That fits the far-from-database theory above, alongside JNB and DAR.

What happens

In Settings → Connections, enabling T3 Connect shows the "Could not update T3 Connect" toast and the inline error https://relay.t3.codes/v1/client/environment-links failed. UI trace: 0b6e749c068de20ccd71e665bd6cd7c8.
Authorizing with t3 connect link --headless succeeds. After restarting the app, the server's reconcileDesiredLink retries every 10 to 40 s. Each attempt waits about 9 s, then fails.

Local server trace, 2026-10-08 UTC. From 03:19:45 to 03:34:30 there were 29 attempts: 28 returned HTTP 504 and 1 returned managed_endpoint_provisioning_failed. A sample:

Time	Result	Ray ID
03:19:45	HTTP 504	a472017dcd9eee08-ACC
03:21:41	HTTP 504	a4720450d8a06903-ACC
03:22:20	HTTP 504	a47205450b796903-ACC
03:28:42	HTTP 504	a4720e9dafe4ee08-ACC
03:29:17	`environment_link_unavailable: managed_endpoint_provisioning_failed`	none
03:29:55	HTTP 504	a47210617b73ee04-ACC
03:34:30	HTTP 504	a472171989a56903-ACC

One attempt finished before the 9 s deadline and returned managed_endpoint_provisioning_failed. That points to managed-endpoint provisioning as the slow step.

Ruled out on the client: There is no proxy, either system or WinHTTP. The local clock matches the relay's Date header to within 1 s. relay.t3.codes answers in about 0.1 s, and an unauthenticated POST gets the expected 401. The relay client, cloudflared 2026.5.2, is installed. Installing it first required working around the #16945 EBUSY bug.

Follow-up to my comment above: turning on a VPN made the link succeed right away. This fits the theory that the relay times out because of location.

Without a VPN, my requests were routed through Cloudflare's ACC (Accra) location. Every link attempt hit the relay's 9 s deadline. The last 504 was at 03:39:04 UTC, after 36 failed attempts from 03:19 onward.
With a VPN on, re-enabling T3 Connect worked on the first try. activateManagedTunnel succeeded at 03:44:53 UTC and cloudflared started.
After I turned the VPN off, the managed tunnel stayed up. Requests to relay.t3.codes/cdn-cgi/trace showed colo=ACC again, and activateManagedTunnel succeeded again at 03:47:59. The VPN was only needed for the POST /v1/client/environment-links step.

Workaround for anyone on a distant Cloudflare edge (Africa reports so far: JNB, DAR, ACC): connect a VPN, enable T3 Connect, and wait for "T3 Connect linked". You can then disconnect the VPN.

This points to the link transaction's round trips from distant locations as the cause, rather than a provisioning fault on any one machine. Raising the deadline for this endpoint, or cutting its database round trips, would probably fix it.

Same failure on Windows 11 with T3 Code (Nightly) desktop 0.0.46-nightly.20261009.2861 on 2026-10-09. My requests to relay.t3.codes go through Cloudflare's JNB location (cf-ray: a47c31c3c8869997-JNB). The VPN workaround above fixed it for me too.

What happened

Settings → Connections → T3 Connect showed https://relay.t3.codes/v1/client/environment-links failed, with no reason.
On each attempt the challenge step and the local link proof succeeded. The UI gave up 9.2 to 9.4 s after the link proof, and relay-config was never reached. This matches the relay's 9 s deadline.

Failed attempts (local server trace, UTC, 2026-10-09)
Link proof at 08:55:52, 08:56:02, 08:56:21, 08:57:01, 08:59:30, 09:04:08, 09:11:57, 09:14:10 and 09:30:57. Each one failed about 9.3 s later.

How it started

Up to 08:52:50 the managed tunnel was healthy, and relay health checks returned 200.
At 08:55:46 a link succeeded in about 4.5 s. applyCloudRelayConfig received endpointRuntime: null, removed cloud-endpoint-runtime-config and stopped cloudflared. Publish agent activity was on, so this looks like the publish-only relink from [Bug]: Connections settings cannot detect or repair a relay link that drifted to publish-only (toggle shows on, relink is a no-op, mobile gets endpoint_provider_not_managed) #11899. The publish-only link was fast and every managed link after it timed out. That fits the theory that managed-endpoint provisioning is the slow step.
Every managed link attempt failed after that, including after I deregistered the environment in Account → T3 Connect and restarted the app.

VPN workaround

With a VPN connected to a server outside Africa, the link worked on the first try. Link proof at 09:49:22 UTC, relay-config applied at 09:49:28 (about 6 s), activateManagedTunnel succeeded at 09:49:30 and cloudflared started.
After I disconnected the VPN, requests went through colo=JNB again and the managed endpoint kept returning 200.

The relay request isn't in the local trace files, so I don't have relay trace IDs for the failed attempts.

Same issue on Windows 11 Pro, T3 Code desktop 0.0.45, from Réunion Island (loc=RE), routed through Cloudflare JNB (colo=JNB on relay.t3.codes/cdn-cgi/trace).

POST /v1/client/environment-links → 504 {"error":"relay_request_deadline_exceeded"} on every attempt.
No proxy and no VPN by default; the firewall and SmartScreen were ruled out.
The VPN workaround worked: I connected to a European server, enabled T3 Connect, and it linked on the first try. The link stayed up after I disconnected the VPN.

That's one more JNB-routed report. +1 for raising the deadline on this endpoint or cutting its database round trips.

Same failure on Linux (CachyOS, x64), T3 Code desktop (server 0.1.0), on 2026-10-16. Cloudflare colo is again JNB (loc=ZA), so this is one more far-from-database report.

What happens

Publishing the environment right after signing in fails with: https://relay.t3.codes/v1/client/environment-links failed: Relay timed out before it finished the request (HTTP 504). Trace: 9dc0b7ab26daa773539f90e7638739d7. The new client message with the trace ID shows up now, which helps.
Turning on T3 Connect in Settings also fails. Trace: 306d0eed63b2c3eaac45016252096b8c.
A full app restart doesn't help. After the restart, the local server creates environment.cloud.linkProof successfully, cloudflared 2026.10.0 resolves fine, and no local spans fail. But no cloudflared process is ever started.
RelayEnvironmentDiscovery.refreshStatus logs "Relay environment health check reported offline / Managed endpoint health request failed" for the previously linked managed endpoint. Traces: c94201623c5cdc2441a681d0f77c43c5 (08:16 UTC) and 1bdaa27b03639665a43522be4ecbb3e7 (08:36 UTC). Requests to that managed endpoint get Cloudflare 530, meaning no tunnel origin is connected.
The network itself is fine: relay.t3.codes answers in about 60 ms from here.

Relay-side traces worth checking for the stalled child span inside linker.link: 9dc0b7ab26daa773539f90e7638739d7 and 306d0eed63b2c3eaac45016252096b8c.

Same 504 on macOS 27.0, 2026-10-16 ~12:09–12:10 UTC, with and without "Publish agent activity". Cloudflare edge is VIE (Austria) — so not only distant colos. Trace IDs: 4400af80e0f2a3d0db0f4fcddc0e1ebb, b3e1cbf3120d29ae4898d36d0f4efbe1, d1b87d3eb372fc19005b3b7b4115ac2d.

Same here, 504 on macOS 27.2 Beta, trace ID 283da36af8512fb314dd3a5a0ca5b458. On devices in this network that already had T3 Connect enabled from an earlier time, I can't turn it off. For newly provisioned devices, I can't turn it on.

Additional macOS report on 2026-10-19, with the same provisioning error on a Mac Studio running the T3 Code desktop app (Beta). Settings reports server version 0.1.0 and “Up to date”.

Steps:

Sign in to T3 Connect in the desktop app.
Open Settings → Connections.
Enable T3 Connect for the Mac Studio's local environment.

The toggle remains off and the following inline error appears:

https://relay.t3.codes/v1/client/environment-links failed:
Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).
Trace ID: b79ba94029983b0212b52659647f907f

The Mac Studio does not appear in Account → T3 Connect on another Mac signed into the same account. Two other environments are already listed there, and the existing connections work.

Expected: the Mac Studio is registered and becomes reachable from the other desktop through T3 Connect.

Impact: T3 Connect access to this Mac Studio is blocked. Exact macOS version, relay HTTP status, failing provisioning stage, and request timestamp are not available from the UI screenshot. Please inspect the relay trace above; the screenshot alone does not establish whether this has the same underlying cause as the 504 reports.

Additional Windows desktop report from 2026-10-19. Enabling T3 Connect under Settings → Connections repeatedly fails at POST https://relay.t3.codes/v1/client/environment-links.

Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).

Trace IDs:

19eb6d731b51fc02bf3dc3f6a17f934c — managed Connect attempt after successfully registering an activity-only link.
0cd18bbec7283d77d8c00733d5b7ca3a — provisioning failure after restarting the desktop app.
938749d0dddaf3f761df21b27ff47de8 — earlier relay HTTP 504.

Isolation checks:

Direct LAN access from the Android app works.
With T3 Connect off, enabling Publish agent activity succeeded and the CLI reported the environment link as provisioned with activity enabled. Enabling managed Connect after that still returned the provisioning error above.
Local cloudflared is installed, version 2026.10.0.

These traces were captured on 0.1.1-preview.20261019.3339. I have since moved to the official 0.1.1-nightly.20261019.3348; the traces above are from before that upgrade, not a fresh Nightly reproduction.

Expected: enabling T3 Connect registers the managed endpoint so this PC is reachable outside the LAN. Please inspect the relay spans for these trace IDs to identify the failing provisioning stage or timeout. The client error alone does not establish whether these failures share the same underlying cause as the other 504 reports.

Same 504 on macOS 27.0 (arm64), T3 Code desktop app, server version 0.1.0 (latest stable), on 2026-10-19. Cloudflare edge is VIE (loc=HU), the second VIE report after the one above, so this is not limited to distant colos.

Steps: Settings → Connections → turn on T3 Connect. The toggle fails with:

https://relay.t3.codes/v1/client/environment-links failed: Relay timed out before it finished the request (HTTP 504). Try again in a few minutes. If it keeps failing, copy the trace ID when you report it. Trace ID: 3229b86f8d96a41f54ac9db4d6058501

It failed both before and after a full app restart.
Relay trace ID from the error above: 3229b86f8d96a41f54ac9db4d6058501
Local environment.cloud.linkProof succeeded on every attempt (UTC): 11:06:23, 11:06:36, 11:07:48, and 11:49:31 after the restart. No local spans failed.
relay.t3.codes answers in about 60 ms from here, so the network is not the bottleneck.

Please check the relay span tree for the trace above to see which child span of linker.link stalls.

Triaged via t3 triage by Claude Code (Opus 5.5).

Another report from 2026-10-19, on a headless Linux background service (systemd). The link request hits the same 504 on every attempt, and since 12:45 UTC it hasn't succeeded once.

Environment

Server version 0.1.1-nightly.20261019.3360 (background service, t3code.service). The bug happened on this build. The last connection through the relay that worked was at 06:53 UTC, from a desktop client on 0.1.1-nightly.20261019.3348.
Linux x64 (kernel 7.0.14 PVE), Node v26.8.2, managed cloudflared 2026.10.0.
Cloudflare edge: FCO in the morning, MXP from about 12:00 UTC (Italy).

What happens

POST https://relay.t3.codes/v1/client/environment-links takes about 9.2 s, then returns HTTP 504. Building the local link proof (environment.cloud.makeLinkProof) succeeds on every attempt.
The client reports RelayRequestError: T3 Connect relay returned HTTP 504 without a recognized error response, which means the 504 body didn't decode as RelayProtectedError. Other reports here quote the relay's own message ("Relay timed out before it finished the request (HTTP 504)"), so on at least some attempts the 504 is reaching the client without the relay's error body.
t3 connect status: Exposure: enabled · Authorization: stored credential · Environment link: pending server startup · Relay: not provisioned. The app says the relay has no active link to use this device as a T3 service server.
The environment's managed endpoint (prod-1a6f9f0ca3c59e7a.t3coderelay.com) returns 530 / error 1033. That's expected, because the link never provisions and so cloudflared never starts. It could easily be mistaken for the cause.

Timeline (UTC) and Cloudflare Ray IDs

07:08:14, first failure in the trace window: a4cdf34eeff6ea50-FCO
07:26, startup reconcile failure: a4ce0dde5f2fea41-FCO
12:19, startup reconcile failure: a4cfba6d8ac64c6e-MXP
12:37:46: a4cfd607c923d815-MXP
12:43, I unlinked and re-enabled T3 Connect, and the service restarted at 12:45. Every attempt since then has failed. The last was at 12:54:49: a4cfef02dadf59ad-MXP.
About 120 failed attempts between 07:00 and 12:55. None succeeded.

Client-side note. The startup reconcile retries for only 10 minutes (Schedule.upTo({ duration: "10 minutes" }) in apps/server/src/server.ts, unchanged on main). Once that time is up, a headless service stays unlinked even after the relay recovers, until someone runs t3 service restart. For headless installs, a slower retry that keeps going after the first 10 minutes would let them recover on their own.

Same failure on macOS desktop, T3 Code 0.1.0 stable

Hit this on a different platform from the earlier reports: the macOS desktop app, not headless Linux or Windows.

What happened

In the desktop app, enabling T3 Connect fails with https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).
t3 connect from the CLI reports it is connected, but the environment never shows up in the account. Other environments on the same account are visible, so the account is correct.

Evidence (server.trace.ndjson, 2026-10-19 UTC)

40 failed environment.cloud.reconcileDesiredLinkWith spans between about 23:43 and 23:52, retried every ~10–40s.
Each one failed after 8.2–8.9s with RelayRequestError: T3 Connect: Relay environment link is unavailable: managed_endpoint_provisioning_failed. Retry when the relay is available. This is close to the relay's 9s deadline discussed above.
Example trace IDs: be4cf596e554d53d8780d5beab3c5609, 87cf6c075c0762b7f0f58e569336d1fb, f71fb4bd78a1d3fce2576e1567976208, d173b272f8e4367ddfce853aa7cb4b1e.
Environment ID: 824efd82-a456-4ead-8974-9f17c027350c.
boot-service.log shows agent activity publishing standby; waiting for T3 Connect link reconciliation, which never completes.

Environment

Version: T3 Code 0.1.0 stable, desktop app, local server at 127.0.0.1:3773 reporting 0.1.0.
macOS 25.3.0 (Darwin), arm64, Node v26.8.2.

This looks like the same relay-side stall as #16810 and the closed #21586. It also shows the client error still doesn't say which provisioning stage failed (#14580).

Produced by Claude Code (Claude Sonnet 5.5) via t3 triage.

Claude responding on behalf of gcrft123

Another first-time link failing on 2026-10-19, this one from a headless Intel Mac. Cloudflare edge is DFW (loc=US). An older environment on the same account is still connected, so the failure looks limited to creating new endpoints.

Environment

Mac mini 2014 (x86_64), macOS 12.7.6
Server 0.1.1-nightly.20261018.3315, headless t3 serve under launchd. There's no darwin-x64 headless build, so this is the server from the Intel desktop build running under Node 24.
cloudflared 2026.10.1 from PATH, never started by T3
Environment ID (for relay log lookup): be990ad2-b9ed-477b-ab88-36399811e31a

What happens
t3 connect link --headless authorized without trouble. After a server restart, t3 connect status stays at Environment link: pending server startup. The startup reconcile made 20 attempts between 23:58:43 and 00:09:04 UTC, then gave up:

Failed to reconcile T3 Connect desired link on startup
T3 Connect: Relay environment link is unavailable: managed_endpoint_provisioning_failed. Retry when the relay is available. If this continues, include the trace ID when reporting it. Trace ID: 22977c71433face90e1a44df6cfd9a43.

19 attempts returned managed_endpoint_provisioning_failed. One returned HTTP 504 (cf-ray: a4d3bf41c9c8e556-DFW). Most of the provisioning failures came back in 8.5 to 8.7 s, measured by the client span that also covers the challenge request. That's just under the relay's 9 s deadline, which fits jlwbr's diagnosis above that a Cloudflare API call inside provisioning is timing out.

Trace IDs (UTC):

23:58:43 6a0ee8cb187e1a09a28c2ba1c51f56ff
00:01:16 1abe0b249fcdbe13b59952611051da74 (the 504)
00:05:10 2453828d89d9c7ab8bfdd44c5c2da8bc
00:09:04 22977c71433face90e1a44df6cfd9a43

Existing environment on the same account
A Mac Studio desktop environment that was linked before today still works. Its managed tunnel has been up since 2026-10-18 20:16 UTC, and its relay health check passed at 23:38 UTC today.

Another data point from 2026-10-19: an existing, working managed link on macOS lost its endpoint after a restart and can't get it back.

T3 Code (Nightly) desktop, app-hosted server, fork build 0.1.1-nightly.20261017, macOS 27 arm64, bundled cloudflared 2026.10.0. Edge colo=ORD.
The tunnel recovered normally on a restart at 22:39 UTC. The next restart (22:46 UTC) went to reconcileDesiredLink, and POST /v1/client/environment-links has failed since with 503 managed_endpoint_provisioning_failed or a bare 504.
It got through twice (23:14:12 and 23:15:29 UTC; tunnel recovery 200), then failed on every attempt after the next restart.
Since 22:53 UTC the relay returns 403 for this environment's /status and /connect, so other devices can't see it, and deregistering it from the T3 Connect window fails too. Two sibling environments on the same account still connect.

Trace IDs: 7c8eff4cf24ea5d8ec226bd7c5f58db2 (22:46), 3f963581c744261f48b1132ff4d2f705 (23:11), 3a26e635b3f2e8a30eea380e2cef14e3 (latest, after 00:10 Oct 20)
Ray IDs (504s): a4d389bc2ab4e82a-ORD, a4d3d220382cb11c-MAN

Sent by Mike's agent (Claude Opus 5.5 in T3 Code, Claude Code harness)

Same failure on Linux (Arch/Omarchy), systemd user service, fresh install — 2026-10-19/20

Environment

Server 0.1.1-nightly.20261019.3373, running as a systemd user service (t3 serve), bound to 127.0.0.1:3773, linux x64 (Mac mini hardware)
Relay client cloudflared 2026.10.0 (managed install)
Cloudflare edge: DFW
Environment ID: 0717ac04-06b0-4be2-ba90-90d6fdef0a75

What happens
Fresh install, first-time link. t3 connect status shows Exposure: enabled · Authorization: stored credential · Environment link: pending server startup · Relay: not provisioned. The environment never appears on other devices.

Evidence (server.trace.ndjson, environment.cloud.reconcileDesiredLinkWith, 23:35–00:16 UTC)

137 attempts: 118 × managed_endpoint_provisioning_failed, 18 × HTTP 504, 1 success at 00:13:11 UTC that did not survive the next service restart
Every attempt takes ~8.4–9.1 s, consistent with the 9 s relay deadline
Sample trace IDs: 2d98427b67b508423bba75fbc1959e32, 69b4832c7c454f86f3365e29528c6637, c5425af15f59ebed28cef95f007fdb6e, 72ce0132f67e1a4d84d72df9ea7ce768
504 Cloudflare Ray IDs: a4d3d3679882df28-DFW, a4d3d4656e6d087e-DFW
relay.t3.codes is reachable from this host (HTTP 302 in 0.25 s), so this isn't a local network block.

Gathered via t3 triage by Claude Code (Claude Opus 5.5).

Still happening on T3 Code desktop 0.1.0 (Electron 44.4.5), macOS 27.0.1. The client now surfaces the reason ("Relay timed out before it finished the request (HTTP 504)"), so the bare-"failed" half of this issue looks fixed, but the relay 504 itself persists.

Steps

Settings → Connections → enable T3 Connect for the local environment (Mac Studio).
Toggle flips back off; toast: "Could not update T3 Connect — https://relay.t3.codes/v1/client/environment-links failed: Relay timed out before it finished the request (HTTP 504)."
Retried a few minutes later with the same result.

Attempts

Trace ID: 7bb3e9e5565a7e9eac5d0be0a72ee39a (around 2026-10-19 23:55 UTC)
Trace ID: 0c6cad34724b698dc874f42fa1607e54 (around 2026-10-20 00:02 UTC)

Ruled out locally

relay.t3.codes reachable in about 60 ms; an unauthenticated POST to /v1/client/environment-links returns 401 immediately, so the relay is up and the 504 only happens on the authenticated link path.
System clock matches Cloudflare's Date header exactly, and no proxy is configured.
Bundled cloudflared 2026.10.0 is installed and runs.
Server trace logs: environment.cloud.makeLinkProof, environment.cloud.linkProof, cloud.getRelayClientStatus, and cloud.installRelayClient all succeed. The failing POST goes from the renderer straight to the relay.

Sorry for this. We're currently running into upstream rate limits on some of the tunnel endpoints. Trying to resolve this right now

Should be resolved

Follow-up to my comment above: the Mac mini linked at 01:30:28 UTC (trace 3f71e874ea52bbba77081b4446f503b7), still through DFW. The managed tunnel registered right after. Nothing changed on my side except restarting the server, so a headless server stuck at pending server startup should only need a restart once the relay accepts links again. The stored authorization and desired link from t3 connect link carried over.

What came before the success, in case the timing helps (durations are client-side spans):

Restart at 00:56 UTC: 10 minutes of the same mix as before. Most attempts were managed_endpoint_provisioning_failed in 8.5 to 9.7 s. Two were 504s (797c1a8a51348be3d84bc9e092d28a37, 4a44443633748ffd243932bab38adf49), and one provisioning failure took 66 s (24cbd76765c37d942dc9e2d9701da670).
Restart at 01:27 UTC: the first request took 121 s and failed with The relay returned an unexpected response (bee7f9486b956391f56218406b3d81eb). Three more managed_endpoint_provisioning_failed followed between 01:29:48 and 01:30:11 (last one f341b5563dc551e0f6b89870e6e8185b), and the next attempt at 01:30:28 succeeded.

Should be resolved

Can confirm that everything works again on my end, provisioning went through and everything shows up correctly across all devices! Thanks for the attention and overall pretty quick fix :)

feat(relay): rate-based relay alerts, warnings, and a health dashboard

Yeah! I confirm too that it's now back online :)

Note

Grok responding on behalf of Julius.

Closing this one out. The relay outage behind these 504s and managed_endpoint_provisioning_failed errors was Cloudflare's API rate-limiting the relay, and it's been confirmed working again here. #22059 is now merged so tunnel recovery reuses ready tunnels, fails fast on Cloudflare 429s, and tells hosts when to retry, and #22108 makes hosts back off from a failing relay. Clearer client-side error reasons for T3 Connect failures are tracked in #14580. If linking fails again after updating, please open a new issue with the trace ID.

Shouldn't this issue stay open till #22065 lands? The original issue was about the 9s deadline not the rate limits

Another data point from China (corporate network, egress via Cloudflare HKG) — I believe the first HKG report in this thread.

Environment

T3 Code (Nightly) desktop 0.1.1-nightly.20261019.3348, macOS 15 (x64, Intel)
Managed cloudflared 2026.10.0
Environment ID (for relay log lookup): dcb16015-df72-4bbc-af46-f72c88d479b2
Tunnel: e121701e-8618-499b-8580-cd1ae1dbc672

Failures with zero user activity. My desktop stays on overnight. Between 18:00 UTC Oct 19 and 01:00 UTC Oct 20 (02:00–09:00 local, nobody using the network), the server logged ~165 upstream_unavailable and ~48 HTTP 504 from recoverManagedCloudTunnel / reconcileDesiredLinkWith. The outage continued unattended, which rules out local proxy/firewall interaction: curl https://relay.t3.codes/ returns 302 in ~110 ms from this machine.

Client behavior worth noting. While the relay is failing, the managed relay client restarts aggressively: 139 cloudflared spawns in a ~65-minute window (new PID every 60–90 s), each logging Relay client process started; waiting for tunnel connection and never registering (zero Registered tunnel connection lines). Retries never back off during a relay-side outage. A backoff on repeated upstream_unavailable might be worth considering alongside the relay-side fix.

Sample failed requests (local UTC+8, local trace IDs):

Oct 20 08:59:42 — 1be72c153fe93bbf18dbd182b8a5c37c — recoverManagedCloudTunnel
Oct 20 09:01:42 — e0d6a22c6b87239ea4a180f2ea7bd7b9
Oct 20 09:03:42 — 080b455e38e2c275df6d07136b8f34e2
One 504 with Ray ID a4d87fdbec70ddbd-HKG at 13:51 UTC Oct 20.

Failure mode matches the diagnosis above: ~9 s to failure, local spans (makeLinkProof, version probes) all succeed in milliseconds.

Navigation Menu

Repository navigation

[Bug]: T3 Connect link returns 504 Gateway Timeout from relay, client shows bare "failed" #16810

Steps to reproduce

Actual behavior

Expected behavior

28 remaining items

Steps

Attempts

Ruled out locally

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: T3 Connect link returns 504 Gateway Timeout from relay, client shows bare "failed" #16810

Description

Steps to reproduce

Actual behavior

Expected behavior

Activity

juliusmarminge commented on Oct 7, 2026

Waaiez commented on Oct 7, 2026

steverosky commented on Oct 8, 2026

steverosky commented on Oct 8, 2026

GidianB commented on Oct 9, 2026

emeric-H974 commented on Oct 15, 2026

TapTap21 commented on Oct 16, 2026

LastDude05 commented on Oct 16, 2026

timwedde commented on Oct 19, 2026

D0cBen commented on Oct 19, 2026

ThimoDEV commented on Oct 19, 2026

skaman89 commented on Oct 19, 2026

dancamdev commented on Oct 19, 2026

28 remaining items

gasket-chris commented on Oct 20, 2026

gcrft123 commented on Oct 20, 2026

mwolson commented on Oct 20, 2026

cort-robinson commented on Oct 20, 2026

kimmotamio commented on Oct 20, 2026

Steps

Attempts

Ruled out locally

juliusmarminge commented on Oct 20, 2026

juliusmarminge commented on Oct 20, 2026

gcrft123 commented on Oct 20, 2026

LosFarmosCTL commented on Oct 20, 2026

nicofishman commented on Oct 20, 2026

juliusmarminge commented on Oct 20, 2026

Waaiez commented on Oct 20, 2026

kinpoe-ray commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions