A process supervisor can tell you that a process exists. It cannot, by itself, tell you that a Minecraft player can join. I work on ChunkCraft, a Minecraft hosting project. Here is a small state model that helps keep operational status separate from player-facing guidance. ## Separate three questions 1. Is the process alive? The container or service manager owns this signal. 2. Has the game finished starting? Startup logs or a game-level probe provide this evidence. 3. Can this player join? Client version, edition, whitelist and network reachability still matter. A useful state model is stopped → starting → ready, with failure and unknown states represented explicitly. Avoid converting a failed probe into “stopped”: a timeout means the observation failed, not necessarily that the server died. ## Tie each state to a next action | Observed state | Useful guidance | | — | — | | Starting | Wait for world loading; show recent startup progress | | Ready | Show the complete connection address and expected version | | Unreachable or unknown | Show when the last successful observation happened and offer diagnostics | | Player rejected | Read the actual join error; check version and whitelist | The same principle applies to control buttons. A copy-address action is helpful when the address exists and startup has completed. Showing it as the only instruction during startup invites repeated failed joins. ## Do not confuse observation with proof Even a successful game-level probe does not prove every player can reach the server. Likewise, a positive player-count sample proves someone was connected at that sample time; it does not identify that person or establish uninterrupted availability. Store observation timestamps alongside values. When a collector fails, preserve historical observations but mark them stale. A freshly rendered dashboard is not evidence of fresh underlying data. ## A small review checklist – Does every status describe an observation we actually have? – Is an unknown state distinguishable from a confirmed failure? – Does the interface tell the player the next useful action? – Are the address and expected Minecraft version shown together? – Do old observations carry their timestamps? This is a design pattern, not a claim that readiness alone solves networking or authentication. For the player-facing side, our ChunkCraft getting-started guide walks through a first connection. Which misleading “healthy” signal have you had to redesign in your own application?