Run your instance / Operate

Telemetry

The anonymous daily report an instance can send knotel.dev: every field, and how to turn it off.

A knotel instance can send a small anonymous report to knotel.dev once a day, so the people who build knotel know how many installs there are, which versions they run and which bugs they hit. There are two parts, each with its own switch: usage stats and crash reports. This page lists every field either one can contain.

Never sent

Spans, logs, metrics, web events or any other data you ingest. Project, service or member names, email addresses, hostnames, URLs or IP addresses. Error messages. Exact counts.

Turning it on and off

The owner chooses when claiming the instance at /setup. Both switches start on and can be turned off there, before anything is sent.
Admins change either switch at any time under Settings → Telemetry, which also shows the last report sent and the next one, as JSON, exactly as they are sent.
KNOTEL_TELEMETRY=off or DO_NOT_TRACK=1 in the environment turns both off and locks the switches, for configuration kept in files.
An instance claimed before telemetry existed sends nothing until an admin turns it on: nobody there was asked.

Usage stats

Every number is a range, enough to tell a small install from a busy one and not enough to recognise anyone's.

Field	What it is
`id`	A random id made for telemetry alone, so an install is counted once. It is derived from nothing: not the hostname, IP address or any account.
`build`	The knotel build, the image's git commit.
`os, arch, runtime`	Such as linux, arm64 and bun 1.4.2.
`projects, users`	How many projects and members, as one of: 0, 1, 2-5, 6-20, 21-100, 100+.
`spans, logs, metrics, web`	How much of each was stored yesterday, as one of: 0, <10K, 10K-100K, 100K-1M, 1M-10M, 10M-100M, 100M+.
`features`	Which of these are set up: alerts, uptime, ai, sourcemaps, mcp. That one exists, never what it is.

Crash reports

When knotel's own code fails on a bug (a TypeError, RangeError and the like), the instance notes where, and sends what it noted with the next day's report. The errors knotel shows people on purpose, such as a wrong password, aren't crashes and aren't noted.

Field	What it is
`type`	The error's type, such as TypeError.
`frames`	Up to 6 places in knotel's own code, as function (file:line:column). Frames in dependencies are left out, and so is the directory knotel runs from.
`fp`	A hash of the type and frames, so the same bug on different installs is counted together.
`count`	How many times it happened since the last report.

The error message is never sent: it can hold data from a request. At most 50 distinct crashes go in one report. Crash reports sent with usage stats turned off carry no id, so they can't be used to count or follow the install.

An example report

JSON

{
  "schema": 1,
  "build": "3afef17",
  "id": "0b0e3f6a-1c2d-4e5f-8a9b-0c1d2e3f4a5b",
  "usage": {
    "os": "linux", "arch": "arm64", "runtime": "bun 1.4.2",
    "projects": "2-5", "users": "1",
    "spans": "1M-10M", "logs": "<10K", "metrics": "0", "web": "10K-100K",
    "features": ["alerts", "mcp"]
  },
  "errors": [{
    "fp": "a1b2c3d4e5f60718",
    "type": "TypeError",
    "frames": ["listErrors (dist/server/assets/queries-B1x.js:412:17)"],
    "count": 3
  }]
}

What knotel.dev keeps

The report goes to https://knotel.dev/api/telemetry, which checks every field against the list above and drops anything else.
For each install, only its latest report, not a history of them; and how many installs reported each day. Each crash is kept once per build with a running count.
The request's IP address is used to rate-limit and is not stored, and neither is the location it came from.
A failed send isn't retried or logged. An instance with no route to the internet simply never reports.

The rest of what knotel does with your data is in Security and privacy.