Product telemetry - Conduktor Docs

Conduktor Console and Gateway send us a small stream of operational and usage information. This page explains what that information is and what we do with it. Telemetry tells us how your deployment is doing, so we can help you before a problem turns into a support ticket. It never includes the data flowing through your Kafka clusters.

Why we collect it

You run Conduktor on your own infrastructure, so we can’t see your deployment. Without telemetry, every question about your setup has to go through a call or an email: which version are you on, how many clusters, is the pod running out of memory, which features have you switched on. Those conversations take time on both sides and the answers are often incomplete by the time they reach the engineer who needs them. Telemetry gives us those facts without the back-and-forth:

A Console instance that restarts every hour, or a Gateway running close to its memory limit, shows up in our data before anyone on your side has to notice.
We know which version you run and which features you use, so your Conduktor team can warn you when a release fixes a bug that affects your configuration, point out what a new version brings for your setup, or flag that your version is about to leave our support window.
When you open a ticket, our support engineers already know your deployment method, your cluster count and your security setup. You skip the questionnaire.
Which screens people use, which ones they abandon and which Interceptors they combine tells us where to invest next.
License expiry and plan limits are in the data, so renewals and capacity discussions happen on time, with numbers instead of estimates.

A Conduktor deployment is a partnership, and telemetry is how we hold up our end without asking you to fill in forms.

What we collect

The exact fields change from release to release as we add and retire features, so this table describes the kinds of data we collect rather than every field.

Category	Examples	What it lets us do
Deployment facts	Product version, operating system, whether it runs in Docker or Kubernetes, how it was packaged, database version	Reproduce your environment when you report an issue and flag versions that need an upgrade
Health signals	Startup and shutdown events, an hourly heartbeat, memory and CPU limits and current usage	Spot restarts, undersized pods and instances that stopped reporting
Configuration inventory, as counts	Number of clusters, topics, partitions, consumer groups, users, groups, Interceptors, Virtual Clusters, alerts, Self-service applications and policies	Size our recommendations to your scale and notice growth before it becomes a capacity problem
Security setup, as types	Which authentication and encryption mechanisms are in use, single sign-on type, whether TLS is on	Test the connection setups our customers rely on and prioritize fixes that affect them
Feature usage	Which Console screens and actions people use, which Interceptor types run on Gateway, which API operations the CLI and Terraform provider use	See which features people rely on and where the product gets in the way
Who you are	Organization name, license plan and expiry, the work email address and email domain of users signed in to Console	Match a signal to your account and reach the right people when we have something useful to tell you

Where Console reports an identifier for one of your Kafka resources, such as a topic in a usage event, it sends a scrambled version of the name (a one-way hash) rather than the name itself. That lets us tell “the same topic again” from “a different topic” without learning what you called it. The email addresses tell the team that works with you who to contact about your deployment, and nothing else. Signing in to Console never adds anyone to a marketing list.

What we never collect

The content of any Kafka record, whether key, value or headers
Kafka credentials, API keys, usernames or passwords
The contents of your Interceptor configuration, alert definitions or data policies
The addresses of your brokers, Schema Registry or Kafka Connect clusters
The content of requests made to the Console API
Error messages, crash details or log lines
Audit log entries or a record of what individual users did to which resource

Gateway sits in the path of your Kafka traffic. Its telemetry contains configuration counts and deployment facts only. Records pass through Gateway and are never copied anywhere.

Allow telemetry traffic

Telemetry leaves your network over HTTPS on port 443, through your usual egress proxy if you have one, so you can inspect it there. If your firewall or proxy restricts outbound traffic, allow these destinations:

Source	Destination
Console server	`events.eu1.segmentapis.com`
Gateway	`events.eu1.segmentapis.com`
Browsers running the Console web UI	`events.eu1.segmentapis.com` and `cdn.segment.com`

Where the data goes

System	Role
Twilio Segment	Receives the events and routes them to the systems below
Google BigQuery	Stores the events so our product and support teams can analyze them
HubSpot	Keeps deployment facts and contacts next to your account record, so the team that works with you knows the state of your deployment

We use this data to support you and to improve the product. Conduktor is SOC 2 Type 2 compliant and the telemetry pipeline is covered by that certification. Find out more about our security and compliance practices.

For security and privacy reviews

If your security or privacy review raises a question this page doesn’t answer, we’re happy to help. Ask your Conduktor contact or open a support request.

​Why we collect it

​What we collect

​What we never collect

​Allow telemetry traffic

​Where the data goes

​For security and privacy reviews