Minecraft server status: Online, Offline, and Unknown
Status is a narrow observation, not a full health certificate: Online, Offline, and Unknown are different claims, and Unknown is not Offline.
- Last verified
- Evidence cutoff
Direct answer: For a Java server list ping (status) check, Online means a valid status response arrived inside the evidence window. Offline means the admitted resolved target explicitly refused that status connection. Unknown means the check did not produce enough evidence for either claim—timeout, reset, malformed data, DNS ambiguity, rate limits, and monitor failures all land here. Unknown is not Offline.
For shared status updates and continued troubleshooting, see the MinecraftStatus community on Discord.
A multiplayer entry can look “down” in a checker while players still join, or look “up” while login fails for other reasons. Status is a narrow observation, not a full health certificate.
What a status check actually does
On modern Java Edition, Server List Ping (SLP) is a short TCP exchange separate from gameplay login:
Client opens a connection and sends a Handshake with next state status (1).
Client sends a Status Request.
Server replies with a Status Response JSON object (version, players, description/MOTD, optional favicon, and related fields).
Optionally, client and server exchange Ping / Pong for a round-trip timing sample.
That sequence answers: “Did this target answer a status probe?” It does not prove you can complete online-mode authentication, pass a whitelist, finish resource-pack negotiation, or stay connected under load.
When a client is only probing to learn which protocol to use, the handshake’s protocol version is conventionally set to -1. Some proxies and reverse setups also echo version.protocol: -1 in the response. That value is a documented convention, not automatic proof of a broken server.
The three result states
| Result | What the evidence supports | What it does not mean |
|---|---|---|
| Online | A parseable, edition-appropriate status response was received within the evidence window (status_response). | Everyone can join; your account works; Realms is fine; the game feels lag-free. |
| Offline | The admitted resolved target refused the status connection (connection_refused). | Every path to the world is dead; players elsewhere cannot join; the process is not running behind a proxy. |
| Unknown | Evidence is incomplete or ambiguous (see codes below). | “Treat as Offline.” That collapse hides real causes. |
A careful evidence model uses this mapping:
| Evidence class | Typical result | Practical reading |
|---|---|---|
status_response | Online | Target answered SLP with accepted framing/payload. |
connection_refused | Offline | Explicit refuse from the admitted target. |
timeout | Unknown | No answer in time—could be filtering, overload, wrong path, or packet loss. |
closed_without_status | Unknown | TCP opened/closed without a valid status body. |
connection_reset | Unknown | Mid-exchange reset; not a clean refuse. |
dns_unresolved | Unknown | Name did not resolve cleanly enough to probe. |
invalid_frame / invalid_payload | Unknown | Bytes arrived but failed protocol or schema checks. |
outbound_capacity / rate_limited / internal_error | Unknown | Checker-side limits or errors—not proof about the game server. |
Diagnostic flow
If a checker exposes a state and evidence code, read both first. Online, Offline, and Unknown are different claims. Do not rewrite Unknown as Offline to make a binary decision.
Confirm address and edition. Java status (TCP SLP, default port 25565 unless SRV redirects) is not the same observation as a Bedrock UDP/RakNet path. A wrong edition or host string produces noise, not a platform outage.
If Online: Treat MOTD, sample player lists, and advertised version strings as self-reported fields from that response. They can be wrong, spoofed, or stale relative to gameplay. If you still cannot join, move to connection troubleshooting—status already succeeded.
If Offline (
connection_refused): Check whether the process is listening, whether the public address points at the right host/port, and whether a proxy/firewall is refusing status while another path still works. Refusal is strong for that target and method, not a global “Minecraft is down.”If Unknown: Branch on the code. Timeout/reset → network path, host firewall, or capacity. DNS → name and SRV resolution. Invalid frame/payload → proxy or non-Minecraft responder. Rate limit/internal error → retry later from the same tool or another vantage; do not announce an outage.
Compare paths before concluding. If friends are in-game while a remote checker is Unknown or Offline, you may be looking at a path or timing mismatch (status port vs play port, SRV, firewall/geo/vantage, or long-lived sessions observed in different windows). See Why a Minecraft server can look offline while players still join.
Separate status RTT from gameplay lag. A ping/pong sample is not tick performance. For latency language, see Minecraft server ping, latency, and timeout explained.
Evidence limits
One vantage, one method, one evidence window. Results expire; an old Online is not a live promise.
Status can be disabled or answered by a different layer than the play path.
Player counts and samples in the JSON are whatever the target chose to return; they are not audited census data.
Bedrock silence after a UDP probe cannot be mapped to Offline the same way a TCP refuse can; silence stays Unknown without stronger proof.
Checker rate limits and capacity failures describe the observer, not the server.
Live check
Use the Minecraft server status checker for a current Java or Bedrock observation on an address you control or are allowed to probe. For how the status JSON fields are shaped, see Minecraft MOTD and the Java status response explained.
Last verified
Evidence cutoff: 2026-07-20
Sources rechecked: Minecraft Wiki Server List Ping / protocol notes; Minecraft Help network troubleshooting; product Online/Offline/Unknown evidence mapping.