Roblox Leaderstats Not Updating? Fix Values and Server Logic

Check where the values are created

Leaderstats are simple when the structure is correct. Roblox expects a folder named leaderstats under the player, with value objects inside that folder. If the folder is misspelled, created too late, placed somewhere else or created only on the client, the leaderboard may not show what you expect. Start by confirming that the server creates the folder every time a player joins and that each visible stat has the exact name you want players to see.

Next confirm the value type. Coins, wins and levels are often IntValue objects. Time, rebirths or points may also be numbers. If your script changes a separate variable but never assigns the leaderstats value, the screen will not update. If your saved data loads into a table but the visible value stays at the default, the display path and data path are disconnected. A good fix connects the authoritative server data to the visible stat in one clear place.

player joins:
leaderstats folder created:
visible value name:
server value changes:
data loads before display:
expected result:

Match names across scripts

Many leaderstats bugs are naming bugs. One script creates Cash, another updates Coins and the save system stores Money. All three may be reasonable names, but the game needs one source of truth. Choose the public display name and the internal data key intentionally. Then update earning scripts, shop scripts, save scripts and UI scripts to use the same value or a clear mapping. Avoid changing public names repeatedly if players are already used to them.

When asking AI for help, paste every place the stat appears. Include the player join setup, the reward function, any shop or upgrade code, and the save/load code. Ask Stellar AI to identify mismatched names before rewriting. If the answer jumps straight to a new system without explaining the mismatch, ask for a smaller patch.

Keep rewards server controlled

Leaderstats should reflect trusted server state. If a client button can directly set a visible value, exploiters can fake progress. The client can request a reward, but the server should decide whether the request is valid. For a simulator, the server might validate cooldowns, tool ownership, multiplier state and zone access. For an obby, the server might validate checkpoint order. For a tycoon, the server might validate purchased objects and currency cost.

After validation, update the server value, then let replication update the player display. This keeps leaderstats useful without making them the security boundary. The visible stat is for the player and leaderboard; the server logic remains the authority.

Save and load timing

If a stat appears briefly then resets, inspect load timing. The game may create defaults, show them, then load saved values too late or overwrite loaded values with defaults. If the player earns currency before data finishes loading, the update path may conflict with the later load. Use a clear data-ready flag or sequence: create temporary values, load data, apply loaded values, then allow earning actions. Handle load failure separately so you do not save a default over real progress.

Test by joining with a clean player, earning a small amount, leaving, rejoining and confirming the exact value. Then test an existing player and a failed-load fallback. That gives you confidence that leaderstats, saving and gameplay updates are all reading the same source.