Telemetry
What devglow sends, when, and how to stop it.
Diagnostics are off by default. On a fresh install devglow sends no usage data and no error reports. It does check your license, because that is what keeps the app working.
This page is the engineering detail. The privacy policy is the binding document and covers all three Glow Suite apps.
The three levels
Settings has a three-way choice rather than a single switch, because error reports and usage events differ in what they carry and who they help. An error report is more sensitive: a failure message can contain a command or a port. It is also the only telemetry whose benefit comes back to you, since a reported crash is a crash we can fix. Collapsing both into one toggle would erase a reasonable position, which is roughly: don't track what I do, but do tell them when it breaks.
off
The default. Nothing on this page is sent, apart from the license check.
errors
Crashes and failures only. No record of which features you use.
all
Errors, plus the usage events listed below.
Events are dropped at the moment they occur, not queued. Turning the setting on later sends nothing about what happened while it was off.
Sent regardless of the setting
One event runs at every level, including off. Verifying a license is how the app delivers what you paid for, so it is not something the diagnostics setting governs. It carries no usage data.
| event | When it fires, and what it adds |
|---|---|
| license_check | When the app verifies your license or trial, at launch and periodically after.Whether the check hit the cache or the server, and the resulting status. |
The app also checks for updates. That request goes to the update feed rather than to our analytics endpoint, and is not recorded as an event.
Sent on errors and above
Each of these carries a failure message alongside the common fields below.
| event | When it fires, and what it adds |
|---|---|
| crash:* | On the next launch after the app terminated unexpectedly.The crash type, the version that crashed, and when the crashed session began. |
| project_start_failed | A process you started failed to launch.The command with its directories removed, leaving the binary and flags. |
| project_restart_failed | A restart failed.The same trimmed command, when the failure came from the launch itself. |
| project_toggle_failed | Starting or stopping threw before it got as far as the command. |
| port_operation_failed | Checking or freeing a port failed.The port number. |
| kill_process_failed | Stopping a process by PID failed.The PID and the port. |
Sent only on all
These record that something happened, not what it was. A project_start says a process started; it does not say which one, from where, or with what command.
| event | When it fires, and what it adds |
|---|---|
| app_open | The app starts. |
| project_start | A process starts. |
| project_stop | A process stops. |
| project_restart | A process restarts. |
| mcp_connect | An AI tool connects over MCP. |
| log_view | You open a log viewer. |
| settings_open | You open settings. |
| layout_save | You save a workspace layout. |
| layout_restore | You restore a saved layout. |
| paywall_shown | The purchase screen appears. |
| purchase_clicked | You click through to buy. |
| find_license_clicked | You use the "find my license" link. |
Attached to every event
- App version
- Platform (macOS or Windows)
- Your system locale, such as en-US
- Your timezone, such as America/New_York
- An installation identifier, described below
Timezone deserves a note. In a small user base an unusual one narrows the field considerably, and combined with a timestamp it is more identifying than it looks. We keep it because version and platform adoption are read regionally, but it is the reason the retention window below exists, and the reason analytics carries an identifier that cannot be linked to your purchase.
Two identifiers, kept apart
Your license is bound to a hardware identifier, because binding a purchase to a machine is the entire point of it. Analytics uses something else: a random value generated on first use and stored in the app's own data. It has no relationship to your hardware.
These are deliberately kept separate. If analytics used the hardware identifier, analytics rows could be joined to license records, license records to orders, and orders carry an email address. That chain is what the split breaks. Analytics only needs enough resolution to avoid counting one machine twice.
Setting diagnostics back to off discards the analytics identifier. Turning it on again generates a new one, so records either side of an off period do not join into one history. Clearing the app's data erases it too.
What never leaves your machine
- Process log output, in whole or in part
- Project names and working directories
- Environment variables
- Repository names, branches, and git state
- File contents
- Your email address or license key, in any analytics event
Two qualifications, since a list like this is worth less than the exceptions to it.
Failure messages are written by other programs. When a process fails to start, the message comes from your shell or the tool you ran, and we cannot know in advance what it says. Before sending, devglow removes the user name from home directory paths, on macOS, Windows, and Linux alike, so /Users/alice/code/api becomes /Users/***/code/api. The rest of the path survives, because it is what makes the failure legible and it is far less identifying than your name.
Failed commands are trimmed, not removed. When a start or restart fails, the command has its directories stripped and the binary and its flags are kept: /Users/alice/.nvm/versions/node/v20/bin/npm run dev is sent as npm run dev. Commands are not attached to any event at the all level, only to the two failure events above.
Where it goes
To our own servers, over HTTPS. There is no third-party analytics SDK in the app: no PostHog, no Segment, no Google Analytics, no advertising or attribution SDK of any kind. Nothing is shared with or sold to anyone.
POST https://devglow.app/api/analyticsPOST https://devglow.app/api/devglow/errorSending is fire-and-forget. If a request fails it is discarded rather than retried, and the app carries on. Blocking these two endpoints at your firewall breaks nothing.
Events are kept for 90 days with their installation identifier. After that the identifier is dropped and only aggregate counts remain, such as how many installs are on which version. The website uses Umami, which is cookieless and separate from everything described here.
Turning it off
It is already off unless you turned it on. To check or change it, open settings → privacy and set send diagnostics to off. That also discards the analytics identifier.
We do not ask you to opt in on first launch. A prompt in front of an app you have already paid for is not a real choice, and defaulting to off makes the question unnecessary.
Questions about any of this?
privacy@devglow.app