Adding telemetry to a game¶
Ten minutes, twice: once in the Creator Hub, once in Studio. You never write any code — you set two values and publish.
What it does¶
It records who played, for how long, and on which team. That is all, and that is deliberate: everything else (attendance, activity leaderboards, division scores) is worked out later from those records, so the thing running inside your game stays small and stays boring.
It does not read chat, track positions, run anything on players' machines, or touch gameplay in any way. There is no LocalScript in this model and there never will be one.
What you need before you start¶
Ask for two things. They are per-game, so a second game gets its own pair:
- a game key — a short name like
genesius - an ingest key — a long secret string
1. Turn on HTTP requests¶
Studio → Home → Game Settings → Security → Allow HTTP Requests: On.
Without this every request fails silently and the log will say so on start-up.
2. Store the ingest key as a secret¶
On the Creator Hub, open your experience → Settings → Secrets → Add Secret.
| Field | Value |
|---|---|
| Name | titan_telemetry |
| Value | the ingest key you were given |
The name must match exactly.
Why not just put it in the script? Anyone who can open the place file can read a key that lives in a script, and with it they could write any activity they liked into the records — including for people who never played. A secret is not in the place file, and rotating it does not need a republish.
3. Put the model in¶
Drag the model into ServerScriptService. You should have:
If TelemetryConfig is not a child of TitanTelemetry, the script will not
find it and will stop on the first line.
4. Set the game key¶
Open TelemetryConfig and set one line:
Leave everything else alone.
5. Publish and check¶
Publish, join your own game, then open View → Output (or the live server log) and look for:
That is it. Sessions are sent about once a minute and when the server shuts down.
When it does not work¶
The script tells you which of these it is. It never fails quietly.
| Log line | What to do |
|---|---|
GAME_KEY is not set |
Step 4. |
no secret named "titan_telemetry" |
Step 2 — check the spelling, then republish. |
could not reach telemetry |
Step 1, then check BASE_URL is unchanged. |
refused (403) |
The game key is not registered yet. Ask for it to be added. |
refused (400) |
A bug on our side, not yours. Send us the line. |
| Nothing at all in the log | The model is not in ServerScriptService, or DEBUG is off. |
Studio session — telemetry is off |
Expected. Playtests are not recorded, so testing does not file fake activity. |
Things worth knowing¶
- Restarting the server does not lose sessions. Everyone still in the game is closed out and sent on shutdown.
- If our endpoint goes down, nothing breaks. Sessions queue in memory and go when it comes back. If it stays down long enough to fill the queue, the oldest are dropped — never the game.
- A batch sent twice counts once. Each batch carries an id that the server remembers, so a request that timed out can safely be sent again.
- Team changes split a session. Someone who plays an hour on two teams produces two segments of thirty minutes, not one hour on whichever team they happened to end on.
- Playtests are not recorded, so testing never files fake activity.
Removing it¶
Delete the script. Nothing else in your game depends on it, and records already sent are unaffected.