Telemetry

StewBeet counts successful builds, anonymously, so the project knows whether anyone is using it, and the tools on this site are counted the same way. Here are the numbers, the exact contents of what is sent, and how to switch it off.

Loading the public numbers...

What do we collect?

Three fields, sent once a build has finished. The versions say which releases still need supporting, and the duration says whether builds are getting slower between releases.

Sent after a successful build

  • The StewBeet version, ex: 3.6.3
  • The Python version, ex: 3.14.7
  • How long the build took, in seconds
  • The day it arrived, kept as a date and never as a time

Never sent, never stored

  • Your project, its name or its contents
  • Your source code
  • Your file paths
  • Your username
  • Your hostname
  • Your environment variables
  • Your repository or its remotes
  • Your IP address, which the server uses to rate limit and then drops
  • Any installation or user identifier, one-off or persistent

The server keeps one row per day per counter: how many events, their total duration, and the distributions that counter declares. Two public endpoints read it back. GET /api/telemetry/builds?days=30 is the build counter, unchanged, and GET /api/telemetry/streams?days=30 is all of them at once.

What about the tools on this site?

The playground and Auto Headers are counted by the server that runs them, which is how the outcome and duration breakdowns exist without your browser sending anything at all. The converter runs in your browser instead, so it sends one short ping when you press Copy or Convert. None of the three records what you uploaded, typed or built, and none of them sets a cookie or an identifier of any kind.

How can I disable telemetry?

Set STEWBEET_TELEMETRY=0 before running StewBeet. Nothing is sent, and nothing else about the build changes.

# Linux / macOS
export STEWBEET_TELEMETRY=0
stewbeet build

# Windows PowerShell
$env:STEWBEET_TELEMETRY = "0"
stewbeet build

Telemetry is not required for anything: it runs after the build is already finished, on its own thread, with a three second timeout, and a failure is swallowed. An unreachable server can never fail or delay a build.

Telemetry implementation

The whole client side lives in one file, so you do not have to take any of the above on trust:

python_package/stewbeet/telemetry.py

The server side is in docs/web/src/api/telemetry/ in the same repository: streams.ts is the list of what gets counted, storage.ts keeps the daily totals, and handlers.ts is the endpoints. Adding a counter is an entry in that list, which is why nothing here is bespoke to one of them.

Back to the home page