Telemetry¶
Sentrik sends one anonymous usage ping per machine per day. This page is the complete disclosure: every field, when it's sent, and how to turn it off.
Exactly what is sent¶
| Field | Example | Purpose |
|---|---|---|
id |
3f9a… (random 32-char hex) |
Counting unique installs. Generated once per machine (~/.sentrik/telemetry_id); contains no machine, user, or hardware information |
event |
usage |
Event type |
command |
scan |
Which CLI command triggered the day's ping — command name only, never arguments |
version |
1.6.0 |
Sentrik version, for upgrade tracking |
os |
linux |
Operating system name only |
python |
3.12 |
Python major.minor |
That is the entire payload. Never sent: file names, file contents, findings, rule ids, repo names, paths, git data, environment variables, IP-derived identifiers, email addresses, license keys.
The server additionally does not record your IP address for telemetry pings, and pings are deduplicated to one row per machine per day.
When it's sent¶
At most once per calendar day, on the first Sentrik command of the day. The request times out after 1 second and every failure is silent — offline and air-gapped machines lose nothing, and a failed attempt is not retried until the next day.
On the very first run, Sentrik prints a notice telling you telemetry exists and how to disable it, before anything is sent.
How to disable it¶
Any one of these:
Disabling is permanent for that environment/config — there is no nagging and no feature difference.
Why it exists¶
Sentrik runs entirely locally, so without this signal we know nothing — not even how many installations exist. The daily ping gives us exactly four numbers: installs, activation, retention, and version spread. Those decide what we build and which platforms we keep supporting.
The implementation is open to inspection in the package you install: guard/core/telemetry.py. If anything on this page ever disagrees with that file, the file wins and we'd consider it a bug — tell us.