Island unreachable through every published channel — public release, private versions and playtest codes all fail with Server Connection Error (#5) / FailedToConnectToServer, while UEFN Launch Session works

General Issues and Bug Reporting
, , , ,
1

Summary

My island cannot be joined through ANY published channel. The public island
code, every private version code, and the playtest code all fail with
“SERVER CONNECTION ERROR (#5)”. Other players never get past “Downloading 0%”.

This started on 2026-08-01. From the same account and PC, other Fortnite modes
and other creators’ Creative islands join normally, so it is not a client,
account or network issue.

UEFN “Launch Session” works every single time, and the server-side cook
completes successfully, so the island content itself is valid and Epic’s
content pipeline accepts it. Matchmaking simply never allocates a server
session: the client log ends with “Not Ready (FailedToConnectToServer)” about
75 seconds after registering the ticket.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Matchmaking

Steps to Reproduce

  1. In Fortnite, enter the public island code manually (not from recent history)
  2. Wait ~75 seconds
  3. “SERVER CONNECTION ERROR (#5)” appears and you are returned to the lobby

The exact same result occurs with:

  • any private version code created from UEFN (Project > Publish Project)
  • the playtest code bound to the newest private version

Meanwhile, UEFN > Launch Session loads the same island successfully every time.

Expected Result

The island loads and the player joins the session, as it does through UEFN
Launch Session.

Observed Result

“SERVER CONNECTION ERROR (#5)” after ~75 seconds, on the public release, on
private versions, and on playtest codes alike. Other players never get past
“Downloading 0%”.

Client log (FortniteGame.log, times UTC):
19:40:20 LogMatchmaking: [FMatchmakingClient::Register] TicketId=e2d8f7f1…
19:41:06 LogDiscovery: Private Island Code(Mnemonic=[…] Version=[1])
19:41:37 MatchmakingLog: [3374] SetReadyStatus called but status not changed
Not Ready (FailedToConnectToServer)

An earlier attempt shows the content pipeline itself succeeding:
[ServerTime 19:32:24] Starting cook for linkid … {EConsumerRole::Server - Linux}
[ServerTime 19:32:25] Completed cook for request linkid … {Server - Linux}
[ServerTime 19:32:25] Starting cook for linkid … {EConsumerRole::Client - Windows}
[ServerTime 19:32:26] Completed cook for request linkid … {Client - Windows}
[ServerTime 19:32:26] Request completed … finalstate: Active
Client readiness → ReadyToJoin → AllRequestsComplete

So the island cooks and installs correctly on both the Linux server and the
Windows client, but no server session is ever allocated for it.

Platform(s)

PC (Windows 11), UEFN 41.30

Island Code

7373-2475-5181

Upload an image

MatchMakingErrr.png
MatchMakingErrr.png1004×325 247 KB

Video

Additional Notes

Project: BrainrotHobbyBackflip
Verse Path: /2bblitz@fortnite.com/BrainrotHobbyBackflip

Affected channels (all fail identically):

  • Public island code 7373-2475-5181
  • Every private version code created since 2026-08-01
  • Playtest code bound to the newest private version

Not affected:

  • UEFN Launch Session (works every time)
  • Other Fortnite modes and other creators’ islands, same account and PC

Island settings: minPlayers 1, overtimePlayerTarget 1, maxPlayers 5,
allowJoinInProgress true, islandQueuePrivacy Unrestricted.

Island state: World Partition streaming enabled, HLODs built,
Map Check 0 errors / 0 warnings, memory 43,000 of 100,000.
The island is ~14.5 km along its longest axis.

A release submitted on 2026-08-02 was rejected at content review for rule 1.14
(“does not function as intended”), which is consistent with reviewers being
unable to join it either.

Matchmaking region: Europe (47ms ping)

Server IPs seen in the client log during failed attempts:
18.156.251.85:15022 and 18.157.12.17:15030 (AWS eu-central-1, Frankfurt)

3

UPDATE — the diagnosis in my original post was wrong. The island content is not
the cause. The failure is in cold session creation.

WHAT ACTUALLY HAPPENS

Joining an EXISTING session works perfectly. My brother managed to create a
session on the public code, I joined it immediately after, and the client log
shows this:

LinkCode [7373-2475-5181]
Successfully Found Session [686734b3…]
JoinSession - 207 ms - Completed
DownloadContent - 1s 658 ms - Completed
Starting Download
In the progress of mounting the content
Client is up to date with server content.
Map load started: /VKPlay/Maps/VKPlay_EmptyOcean_VolumeSupport
Server entry confirmed

The content mounts in 1.66 seconds. For comparison, a brand new empty UEFN
project mounts in 1.5-1.7 seconds. The island content is fine.

The failure only occurs when NO session exists yet and one has to be created
from cold. In that case DownloadContent hangs and dies:

DownloadContent - 44s 648ms - Started (never completed)
DownloadContent - 55s 242ms - Started
DownloadContent - 1m 3s 963ms - Started
DownloadContent - 1m 5s 184ms - Started
DownloadContent - 1m 10s 458ms - Started
DownloadContent - 1m 11s 395ms - Started
DownloadContent - 2m 1s 869ms - Started

There is no middle ground. Either the content mounts in about 1.5 seconds, or
it never mounts at all. That is not consistent with an island being too heavy
or too slow — a size problem would produce progressively longer times, not a
binary outcome.

TWO DISTINCT FAILURE MODES, both when creating a session

Mode A — the server responds, then the connection is severed:

15:42:48 Starting Download
15:42:49 Content Beacon Readiness: Awaiting for a response from the server
15:42:49 Content Beacon Readiness: Server is generating manifests for consumption by the client
15:42:52 Content Beacon Readiness: In the progress of mounting the content
… 67 seconds of silence …
15:43:59 LogProperty: Error: Replicated TMaps are not supported.
15:43:59 LogNet: Result=ControlChannelClose, ErrorContext=“ControlChannelClose”
15:43:59 LogBeacon: Online Beacon Failure: TransportError. beacon_client_connection_closed_remotely
15:43:59 Content Beacon Encountered Fatal Error: FailedToConnect

  • ContentBeaconV2.FailedToConnect.Client Server stopped responding to connection

Mode B — the server never responds at all:

15:46:26 Starting Download
… no readiness lines whatsoever …
15:47:38 Content Beacon Encountered Fatal Error: InitialConnectionFailed

  • ContentBeaconV2.InitialConnectionFailed.Client

Ping is reported as 9999ms on every found session, including the successful one,
so that value appears to be a sentinel rather than a real measurement.

REPRODUCTION NOTE for whoever picks up FORT-1134142

This is intermittent. A single attempt is not a valid test. Roughly 1 attempt in
10 to 15 succeeds in creating a session. Please test by joining when no session
is currently running, and retry from a cold start several times before
concluding it cannot be reproduced.

Once a session exists it is completely stable: other players join instantly and
the island runs at 30 TPS. The error only returns when a NEW session has to be
created, for example when the previous one fills up (maxPlayers = 5).

This has occurred intermittently on playtests for several weeks and became
near-permanent on 1 August 2026.

WHAT I HAVE RULED OUT, each with a test

  • Account: a brand new empty UEFN project published from the same account joins
    in about 3 seconds, on both a private version code and a playtest code.
  • Island registration: I duplicated the entire project into a new UEFN project
    with a new projectId, a new Verse path and a new island code. It fails
    identically, so this is not tied to the original island record.
  • Verse: Creator Portal > Technical > Verse Errors shows no runtime error at any
    of the failure timestamps.
  • Memory: 43,000 against the 100,000 per-zone limit.
  • Content size: 1,092 MB upload / 2,048 MB and 306 MB download / 400 MB, both
    under budget. Another island on this same account has a LARGER download size
    and MORE actors and creates sessions normally.
  • Minimum Players: 1. Island Matchmaking Privacy: tested Public Only.
  • Physics: disabled entirely and republished. No change.
  • World extent: reduced World Partition bounds from 41.06 km to 15.31 km by
    removing stray actors and rebuilding HLODs. No change.

Servers hit were different every time (34.40.68.241:15007, 34.107.122.48:15011,
18.156.251.85:15022, 18.157.12.17:15030), so this is not a single bad host.
Region EU, 47 ms.

UEFN Launch Session works every single time on the same build, which is
consistent with no Content Beacon being involved in that path.

WHAT I AM ASKING

Is there a fixed timeout on the ContentBeaconV2 handshake during server
provisioning, and can you check the server-side logs for these sessions? The
fact that retrying eventually succeeds, and that the session is then perfectly
stable and mounts content in 1.66 seconds, points to a race or a timeout in
session creation rather than invalid content.

This is currently blocking my island and has caused two content review
rejections under rule 1.14 (“This content does not function as intended”),
which I believe happened because the reviewer could not create a session either.

4

The status of FORT-1134142 changed to ‘Needs Triage’. We are routing this to the appropriate team for investigation.

5

UPDATE 2 — root cause is on my side, but I need Epic to explain the metric

Since the last update I ran a controlled bisection. The island is not broken by
Epic infrastructure: my own content pushes the ContentBeaconV2 mount past a hard
timeout. Posting the numbers because the metric that actually governs the budget
is not documented anywhere I can find, and I cannot explain one result.

THE HARD LIMIT

UNetConnection::Tick: Connection TIMED OUT. Closing connection.
Elapsed: 70.01 Threshold: 70.00

If DownloadContent does not complete within 70.00 s, the beacon connection is
closed and the join fails. Errors #2, #5 and #7 are the same failure seen at
different moments (trouble connecting to content beacon service /
FailedToConnect / InitialConnectionFailed). Joining an EXISTING session always
works — no mount, no beacon, no timeout. Only cold session creation is affected.

WHAT DRIVES THE MOUNT TIME

My island uses a Vertex Animation Texture system: 126 creatures, each with one
StaticMesh and three animation textures, all hard-referenced from Verse via
asset reflection. Measurements, each one a separate published version, timing
“DownloadContent” in FortniteGame.log:

files in the VAT folder mount time

0   (system removed)      9.2 s   ok

311 29.1 s ok
391 43.4 s ok
471 FAILED (78 s)
500 FAILED (70 s)
520 FAILED (85 s)
563 FAILED
812 (original) FAILED

The threshold sits between 391 and 471 referenced files.

TWO SINGLE-VARIABLE TESTS

Geometry held constant, only textures added:

63 meshes + 249 textures = 311 files → 29.1 s ok
63 meshes + 378 textures = 500 files → FAILED
83 meshes + 249 textures = 391 files → 43.4 s ok
83 meshes + 378 textures = 520 files → FAILED

The 129 extra textures total 1.3 MB. Byte size cannot explain a swing from
29 s to failure, so the cost appears to scale with the NUMBER of referenced
assets, not their size.

Measured sizes, for completeness: all 378 VAT textures = 3.69 MB. The 126
StaticMeshes = 1,251,204 vertices, roughly 67 MB of vertex and index buffers.
Removing 249 MaterialInstances (3.6 MB) changed nothing.

THE PART I CANNOT EXPLAIN

The same island also hard-references 1,764 icon textures, and they cost
nothing — the 9.2 s run above still had every one of them referenced. Their
settings are not meaningfully different from the VAT textures:

family format mips LOD group never_stream
VAT BoneWeight TC_HDR TMGS_NO_MIPMAPS WORLD False
VAT BonePosition TC_HDR TMGS_NO_MIPMAPS WORLD False
icon (Diamond) TC_DEFAULT TMGS_NO_MIPMAPS UI False
icon (Default) TC_DEFAULT TMGS_NO_MIPMAPS UI False

Both are non-mipmapped, neither is marked never_stream. So “the icons stream
and the VAT textures do not” is not the answer.

WHAT I AM ASKING

  1. What does the mount stage actually cost per asset — package count, resident
    memory, something else? Knowing the real metric decides whether I atlas the
    textures (days of work) or do something cheaper.
  2. Why do 1,764 referenced icon textures cost nothing while 378 VAT textures
    push past 70 s?
  3. Is the 70.00 s beacon timeout configurable or documented anywhere, and is
    there a supported way to measure the mount budget from UEFN before
    publishing, instead of publish-and-time?

Happy to share the project or a stripped repro island privately if useful. I
have both a passing version (391 files) and a failing one (471 files) already
published, which should make a comparison straightforward.

6

RESOLVED — root cause found. It was not the assets.

The island now mounts in 8.1 s with all 126 brainrots and all 13 material styles, on the same published channel that had been failing since 31 July. Nothing was removed: same meshes, same textures, same mipmaps, same HLODs, same World Partition streaming.

The cost is the number of parameterised material-template expressions written literally in Verse — not the number, size or weight of the assets they reference.

Our generated visuals file held one MI_Template{ Param := ... } per (brainrot × style). Measured on published private versions, DownloadContent duration from FortniteGame.log:

construction sites   brainrots   styles     mount
        1638            126        13       FAIL (>70 s)
        1339            103        13       FAIL
        1079             83        13       43.4 s
         819             63        13       29.6 s
         126            126         1       10.5 s
          27            126        13        8.1 s

Threshold between 1079 and 1339 sites. The calls are free — after the refactor there are still 1638 call sites, and it mounts in 8.1 s.

Three single-variable tests ruled out everything else, each published and measured separately:

  • geometry collapsed by 88 % (asset files −81 %) → still failed → not the weight
  • 126 brainrots sharing 63 mesh assets → still failed → not the mesh-asset count
  • 126 brainrots with 1 style instead of 13 → 10.5 s → the construction sites

Fix: a pure Verse refactor — move the template construction into a few shared helpers and pass the per-entity values through a struct. 1638 sites → 27. No asset touched, no rebake, nothing lost.

FORT-1134142 can be closed as resolved on our side. The underlying issue remains for anyone else: a hard 70 s timeout on a cost that is invisible in the Content Browser, undocumented, and reported only as Connection TIMED OUT — Threshold: 70.00 with no attribution. A cost breakdown, or a build-time warning past a known-dangerous count, would have saved six days of bisection here.