A technical dashboard for making decisions
Collect process availability, game connection success, online, TPS/MSPT, CPU, process/container memory, GC, disk and errors. Separate "exporter responds" and "player can enter": a healthy HTTP endpoint does not confirm the entire game path.
Show when the last successful check ran. An unavailable source means the state is unknown, not that zero players are online. Give an alert a duration and a specific condition, such as MSPT remaining over budget while TPS degrades, rather than reacting to one peak.
These indicators are responsible for different sections of the delay. TPS, MSPT and network.
Determine who you consider to be a player
Suggested example: active for the day - a unique server player ID with a confirmed gaming session in the selected time zone. Separately consider login before authorization, successful authorization and game mode. Repeated reconnections of the same ID should not create a new person.
Exclude bots, test accounts and administrative checks with an explicit rule rather than manually changing the chart. When merging Java/Bedrock identities, record why they are linked: similar nicknames are not sufficient.
An onboarding funnel and retention example
For a beginner, the following chain is useful: connection → successful login → mode selection → first confirmed action. It shows where a corrected screen or command is needed. Count transitions using a single ID and an agreed upon time window.
An exact D1 example: players who first logged in successfully on November 1 in Europe/Moscow and returned on November 2. If the cohort has 40 newcomers and 10 return, D1=25%. Returning “within the next 24 hours” is a different metric; do not mix them. Count only cohorts whose observation day has already ended.
Payment events and clear labels
For donations, separate the created order, confirmed payment, return and the actual privilege issued. ARPPU for a period—revenue according to the selected rule of division by unique payers for the same period. Zero number of people paying means no specific value, not division by zero.
Prometheus labels must have bounded sets of values, such as environment, mode and outcome. Do not put a UUID, nickname, address, order ID or full error message in them: each new label combination creates a separate time series. Keep detailed events in a suitable log or database and send aggregates to charts. See the Prometheus instrumentation guide for labeling and measurement principles.
Write the intended action for each panel: test login, inspect reward delivery errors or compare a specific cohort. Verify the calculation against a small set of known events before trusting the aggregate statistics.
Separate data source, contracts and mapping. Website and game API.
