troubleshooting guide

Lost Connection and Reconnect Guide

Separate a local network break, a party-state failure, and a wider server incident before repeatedly rejoining.

Game: 1.0.3.1 Armageddon
Updated: 2026-08-21

Lost Connection and Reconnect Guide: direct answer

When a session breaks, first capture the exact message, time with timezone, map stage, platform, region, and who was affected. Confirm the platform network and installed game version, compare the newest official issue post, then attempt only the reconnect or one clean party rebuild that the current interface offers. One affected player and a whole-squad failure suggest different diagnostic scopes, but neither pattern proves the underlying cause or guarantees that mission state can be restored.

Lost Connection and Reconnect Guide: troubleshooting checks

One player disconnects while the rest of the squad remains in the match.
Likely boundary: As a diagnostic inference, the narrow scope points first to that platform, account session, network path, or party state rather than proving a full outage.
Checkable action: Confirm that player's platform network, record the message, restart the game session if required, and attempt one party rebuild before queueing again.
Every squad member is removed at approximately the same time.
Likely boundary: As a diagnostic inference, shared timing makes a server, region, platform, or match-instance boundary more useful to check than several unrelated local changes.
Checkable action: Record the time, region, map, and squad platforms, check the official issue channel, and avoid repeated queues if a wider incident is posted.
Reconnect returns the player but the party or match state is wrong.
Likely boundary: The client and party state may not have synchronized after the interruption.
Checkable action: Return to the party surface, verify the full roster and mode, then create a fresh queue rather than relying on the stale group state.

Preserve the disconnect before retrying

Record the message exactly as displayed, the local time with timezone, platform, installed version, selected map and mode, current mission stage, party size, and whether the application remained open. Ask each squad member whether they stayed in the match, returned to a menu, or also received a message. This creates a timeline without inventing a root cause or an error-code meaning.

Do not begin by restarting every router, deleting settings, or repeatedly queueing. First confirm whether the platform network and account session still show online access. If another unrelated online function also fails, preserve that platform result; if it works, the result only narrows the observation and does not clear the entire network path.

Classify one-player and shared failures

When one player is removed and the rest continue, checking that player's platform session, route, and party membership first is a diagnostic inference. When the whole squad leaves at approximately the same time, comparing the shared region, platform mix, and official post is a different diagnostic inference. Neither pattern identifies the actual cause by itself.

Keep the party leader's result separate. A leader leaving and the group changing state may look different from one non-leader losing the session, but the current source does not publish a party-hosting model that authorizes a host-cause claim. Report who was affected and what each screen showed rather than labeling one device as the server.

Separate confirmed reconnect support from a diagnosis

The official 1.0 notes added a Reconnect option after a map-loading crash. That confirmed interface boundary is narrower than a promise to restore every disconnect. If the current client offers Reconnect after the recorded failure, use it once and note whether the player returns to the party, the map, or a different state. The presence or absence of the option does not identify the actual cause.

The August 20 developer blog says the team was working on improving the odds of character preservation through disconnects and hoped to release improvements in waves as they are ready. That is staged, planned work, not evidence that character preservation is fully shipped or that a current disconnect is fixed. Record the actual result instead of promising that an interrupted Responder will be restored.

If no reconnect path is displayed, preserve that fact and move to the current party surface. Do not state that reconnect is unsupported, because this page cannot derive a universal feature absence from one failed session. It also cannot promise restoration of inventory, objective progress, assignment progress, or a Responder after an interrupted run.

Rebuild party state once before another queue

Return all available players to the party screen and verify the visible roster, game version, mode, and crossplay choice. Cancel a stale invite, disband once if the roster remains inconsistent, and let one leader create one fresh party. A clean roster before queueing tests whether the visible group state can be re-established; it does not prove the original interruption is repaired.

Use the matchmaking and invite guide if an invited player never appears or the complete party cannot enter a queue. Keep the test controlled by leaving unrelated graphics, controller, and router settings unchanged. Repeating many queues at once adds attempts but does not isolate a boundary.

Compare the dated server-stability boundary

The August 17 1.0.3.1 hotfix reported server-stability work. That dated change is relevant context, not evidence that every later connection is stable or that each disconnect shares a server cause. Open the newest official feed, compare its version and publication time with the installed client, and record any notice that actually matches the region, platform, or symptom.

If the newest available post says nothing about the event, current wider service status remains unknown to this page. Continue with the observed scope and timeline. A missing announcement does not prove a local fault, and an old incident does not prove a current outage.

Escalate without promising state recovery

Provide time with timezone, platform, region, version, map, mode, party size, exact message, affected squad members, reconnect result, and one clean party-rebuild result. Do not include account tokens or private network details. The report should show what changed and what stayed constant.

Use the server-status guide to distinguish dated notes from live telemetry, and the network requirements guide for platform-specific online boundaries. This manual cannot observe the match instance, restore a lost run, or determine compensation; those outcomes remain unknown until a current official channel addresses them.