Telemetry

Telemetry literally means “remote measurement”. A device or a program continuously measures what happens to it and sends these measured values over the internet to the manufacturer. Typical measured values are: How long did startup take? Did the program crash? Which version is running on which operating system? The user normally doesn’t notice any of this, because the sending happens in the background. Originally, the term comes from engineering: weather probes and rockets radioed temperature and pressure to ground stations decades ago.

Why manufacturers are left in the dark without measurement data

A developer only has one computer. But their software runs on millions of very different devices. Without feedback, they only learn about a bug once someone writes a complaint. Most people never do that – they simply quit the program and stop using it. Telemetry closes this gap: the crash reports itself.

Product decisions also depend on it. If measurement data shows that hardly anyone clicks a button, it disappears in the next version. Conversely, a heavily used feature gets more development time. Companies call this data-driven development. The downside: whatever is hard to measure is easily overlooked.

With AI services, a cost argument comes into play as well. Every request to a large language model consumes computing time on expensive specialized chips. Operators therefore precisely measure how many requests come in, how long the responses are, and how long the computation takes. Only this way can they estimate how many servers will be needed next month.

From measurement point to dashboard

At important points in the program code, there are small commands that record an event. Developers call these events. Such an event usually consists of a name, a timestamp, and a few additional details. Example: “File saved”, 2:03 pm, file size 2 megabytes, version 11.4.

These events are not sent individually. The program first collects them in a buffer and then sends a package, for instance every five minutes. This keeps network load low. On the server side, the packages end up in a database built for huge amounts of similar time series.

The whole thing is evaluated in a dashboard, i.e. an overview page with charts. There, a team can see at a glance whether the crash rate has risen since the last update. Automatic alerts are often attached to this: if a value exceeds a threshold, a phone rings at night. It’s important to distinguish this from a log file: a log records individual cases in detail for debugging purposes, while telemetry provides aggregated figures about the mass.

The catch with data protection

The line between technical measurement and surveillance is thin. The fact that a program has crashed reveals little about a person. Which documents were opened and when reveals a great deal. That’s why telemetry data is usually pseudonymized: instead of a name, a random number is attached to the data. This is not truly anonymous, though, because many individual pieces of information together can make a person identifiable again.

In Europe, the General Data Protection Regulation, GDPR for short, applies. It requires consent for data collection that is not strictly necessary. This is exactly why there was years of dispute over Windows 10's telemetry, with authorities in several countries examining the case. Cars, fitness watches, and TVs also now continuously send operating data.

In practice, you mostly encounter the term in settings menus. There you’ll find a toggle with text like “Send diagnostic data” or “Share usage to improve the product”. For programming tools and browsers, this can almost always be turned off. In companies, the IT department often decides this centrally for all devices.