Privacy Policy

Beta telemetry (on by default, opt-out anytime). During the beta, docktor sends four kinds of first-party telemetry to docktor’s own feedback endpoint (a Cloudflare Worker operated for docktor): a minimal usage heartbeat, a redacted summary of any crash macOS recorded for docktor, a redacted snapshot of your settings (which options you have enabled, never anything you typed or named), and a small set of setup-progress events (fixed labels only — how far new installs get through onboarding and first use, and whether docktor had to start in safe mode after failed launches). None of these four is sent until you have seen the disclosure in onboarding, and the single Settings › General › Beta Telemetry toggle (also on the final onboarding step) turns off all four at once.

One thing is sent before you have seen the disclosure, while that toggle is on (it is on by default): an anonymous, count-only onboarding beacon as you reach each onboarding step. It carries only the step name, the app and macOS version, and a Debug-vs-Release flag — no install or session identifier — and it stops as soon as you turn beta telemetry off. See Beta setup-progress events below.

docktor uses no third-party analytics or crash-reporting SDKs — no Sentry, no Google Analytics — and its only first-party server is the feedback endpoint described below; we do not run any analytics or account backend, and we have no way to identify you.

There is exactly one channel that runs back the other way: if you file feedback, the maintainer can write a reply to it, addressed to your install’s random identifier rather than to a name, an account, or an email address, and delivered on the beta usage heartbeat. You can then write back, so a report becomes a conversation — but only messages you type and send yourself are ever transmitted.

The marketing site you are reading uses Cloudflare Web Analytics, a privacy-first, cookieless measurement tool. It records aggregate page views and referrers with no cookies, no cross-site tracking, and no personal data or fingerprinting.

When you click a download button, the site also fires a single cookieless Cloudflare Zaraz “download” event noting which page the click came from, so we can tell which pages lead to downloads. Neither signal identifies you. This applies only to the website; the docktor app itself still uses no third-party analytics SDKs (no Google Analytics, no Sentry).

The following data is read on-device. Most of it never leaves your Mac; the exceptions (looking up song lyrics, fetching weather forecasts, geocoding weather locations, and looking up the name of a Spotify playlist link you paste into the Focus timer) are called out explicitly and listed under third-party services:

• Apple Calendar events — Read-only via EventKit, only after you grant Calendar permission. Used to populate the calendar widget. docktor does not modify, delete, or sync your Apple Calendar events. Never transmitted off your Mac.
• Music playback metadata — Title, artist, artwork, and playback state for supported music apps (Apple Music and Spotify). Lyrics exception: only while the lyrics view is on screen, docktor sends the playing track’s title, artist, album, and duration to LRCLIB over HTTPS to fetch matching lyrics: when the lyrics view is shown (including when hovering the Music widget reveals it in the Dock or the window switcher), and on each track change while it stays shown. Hiding the lyrics view cancels any lookup in progress, and tracks played while lyrics are hidden are never looked up; lyrics fetched earlier may be reused from a local cache. No account or persistent identifier is attached. If you never open lyrics, nothing is sent.
• Focus timer music — The Focus timer’s optional per-phase music control is off until you turn it on, and controls Spotify or Apple Music on your Mac through local Automation, which needs Automation permission. Spotify link exception: when you paste a Spotify playlist link into the Focus music settings, docktor sends that link to Spotify (open.spotify.com/oembed) to look up the playlist name. Nothing else is sent, and it only happens when you paste a link.
• Window contents — Captured via ScreenCaptureKit to render thumbnails for Dock Previews and the Cmd+Tab switcher. docktor may also capture a few on-screen windows ahead of time (for example after you switch Spaces) so the first preview appears instantly. Captures are held briefly in memory (seconds, not saved to disk) and are never transmitted off your Mac.
• Window metadata — The Accessibility API is used to enumerate window positions, sizes, and titles for Dock Previews. Never transmitted off your Mac.
• Coarse location — CoreLocation supplies latitude and longitude when you opt into the Weather widget. Coordinates are sent to the Open-Meteo HTTPS endpoint to look up forecasts, and to Apple’s servers to reverse-geocode a human-readable location name. No persistent identifier accompanies either request.
• Weather locations you add — when you search for a place in the Weather widget, the text you type is sent to Apple (MapKit) to find matching places, and the coordinates of any saved location are sent to Open-Meteo to look up its forecast. No persistent identifier accompanies either request.

docktor includes a beta Feedback pane in Settings. A report you write is sent only when you explicitly tap Send — reports are never sent in the background. (Crash summaries and the reply acknowledgement described below are separate, automatic transmissions.) When you submit feedback, docktor transmits the following to docktor’s feedback endpoint:

• Your typed message — the text you write in the feedback field.
• Screenshots you attach or capture — a preview of every attachment is shown before you send. Screenshots may contain whatever is on your screen, so review the preview before sending.
• Build flavor — whether the build is an Xcode Debug or distributed Release build. It identifies the binary configuration, not you.
• App version — the docktor version and build number the report was sent from. Always included.
• Install identifier — a random identifier (a UUID) generated on your Mac and stored only on your Mac. Always included, because it is the report’s return address: it lets us group the reports from one install and send a reply back. It is not tied to your hardware, and it is not a name, an account, or an email address.
• Country — the two-letter country code (for example US) that Cloudflare resolves from the network connection your report arrives on. It is resolved at Cloudflare’s edge, so docktor never asks your Mac for your location, and it is deliberately no more precise than the country — no city, region, coordinates, or time zone. Your IP address itself is not stored on the report or the heartbeat; it is written only to a short-lived rate-limit log (a sliding window of about ten minutes) and pruned after that.
• Non-personal diagnostics (only when the “Include diagnostics” toggle is on) — macOS version, locale, screen size, and coarse reliability counters. No name, email, account, or other personally identifying information.
• A short tail of docktor’s own logs (controlled by the Feedback pane’s “Attach logs” menu, 5 minutes by default) — the most recent log lines emitted by docktor itself, to help reproduce bugs. Set “Attach logs” to Off to send a report with no logs. These are docktor’s own logs, not a system-wide capture.

What the feedback feature does NOT send: anything before you tap Send, your files, clipboard contents, calendar events, music metadata, browsing activity, keystrokes outside the feedback field, or system-wide logs from other apps.

Feedback is delivered over HTTPS to a Cloudflare Worker operated for docktor, which stores it (Cloudflare D1 and R2) and emails a triage alert to the maintainer via Resend. It is not used for advertising, profiling, sale, or any third-party analytics.

When the beta telemetry option is on, docktor periodically sends a minimal “heartbeat” to the same endpoint. Each heartbeat contains only that the app is running and how long the current session has been up (an uptime in seconds), tagged with:

• the same random, anonymous install identifier generated on-device;
• a random per-launch session identifier (a fresh UUID each time docktor starts, used only to group one run’s heartbeats; it does not persist across launches and does not identify you);
• the app and macOS version, and a Debug-vs-Release build flag; and
• the same edge-resolved two-letter country code described above (the IP address itself is not stored on the heartbeat).

It contains no usage details, feature interactions, message content, screenshots, or personal data. Its sole purpose is to show how many beta testers currently have docktor running. It can be turned off on the final onboarding step or anytime in Settings; when it is off, no heartbeats are sent.

Individual heartbeat records are retained for about 90 days and then automatically deleted; only the most recent heartbeat per install is kept as a running “last seen” summary beyond that.

When you file feedback, the maintainer may write a short reply to that report, and you can write back — so a report becomes a two-way conversation about that one report. Every message is addressed to the random install identifier your report carried — never to a name, an account, or an email address. Replies to you are handed to your install on its next beta usage heartbeat.

• A conversation tells us nothing new about you: messages travel to and from the install that filed the report, with no account, name, or email address involved.
• You control whether a reply can arrive — delivery rides the beta usage heartbeat, so while beta telemetry is off no reply is fetched, and nothing extra is added to the heartbeat request to receive one.
• Nothing you write is sent until you send it. A message carries only your text and which report it belongs to — no diagnostics, logs, or attachments.
• When a reply reaches your Mac, docktor automatically sends a short acknowledgement — the reply’s identifier and your random install identifier, nothing else — so the endpoint stops re-delivering it.
• Opening the conversation list asks the endpoint which reports you filed, identified only by that random install identifier; the reply is your own text coming back to you.
• Messages are short and short-lived: each is capped at 2,000 characters, and every message — in either direction — is deleted from docktor’s endpoint 90 days after it is written, whether or not it was delivered.
• Arrival is announced locally. If you have granted notification permission, the local notification carries a preview of the reply text; if not, the reply is simply marked unread in Settings › Feedback. Nothing about the notification is transmitted.
• Only the maintainer can write to you — no other user or third party can send you a message through docktor.

When the beta telemetry option is on, docktor checks — on launch only — for crash reports that macOS itself wrote for docktor since the previous launch. For each new one, docktor forwards a redacted summary: the exception type and signal, the app and macOS version and the OS-assigned incident identifier, and a size-capped list of the crashed thread’s top stack frames, tagged with the same random install identifier.

Before anything is sent, docktor strips usernames and home-directory paths, caps the summary at 64 KB, and reads only docktor’s own crash reports. The raw .ips file is never transmitted, and nothing is sent at the moment of the crash. This rides the same opt-out toggle as the heartbeat.

When the beta telemetry option is on, docktor sends a settings snapshot to the same endpoint once per launch, so we can see which options beta testers actually use. It is built from a strict allowlist, and every value is sent only in a safe shape:

• On/off and multiple-choice settings are sent as the boolean or the chosen option, and bounded numbers (such as widget width or scroll speed) as the number.
• Which built-in widgets you have enabled is sent as the list of widget type names (for example calendar, music, weather).
• Anything you could have typed, named, or chosen from your own machine is reduced to a count or a yes/no before it leaves your Mac — for example, how many custom Space names you set, never the names; how many apps you excluded from scrolling, never which apps.
• The position of your macOS Dock, whether Dock auto-hide and magnification are on, and how many displays are connected (a number, capped at 16).

It contains no free text, file paths, window or document titles, locations, account or email, or list of installed apps. It carries the same random install identifier, app and macOS version, and Debug-vs-Release flag as the heartbeat — no new identifier. The endpoint keeps only the latest snapshot per install, and one from an install that stops sending is pruned after about 90 days. It rides the same opt-out toggle as the heartbeat.

When the beta telemetry option is on, docktor records a small number of setup-progress events so we can see where new installs drop off: which onboarding step was reached, whether onboarding was finished or dismissed, whether a permission was granted or declined, and whether a first widget was enabled or a first drawer opened, plus whether docktor started in safe mode after repeated failed launches and whether normal mode was restored. Each event is a fixed name from a short predefined list (for example onboarding.step_shown, permission.result, activation.first_widget_enabled) plus labels from fixed vocabularies — the step (welcome, picker, permissions), the permission and its outcome, or which built-in widget or drawer was first used. docktor cannot put your file names, window titles, message content, or any typed input into an event.

Each event is tagged with the same random install identifier, per-launch session identifier, app and macOS version, and Debug-vs-Release flag as the heartbeat. Events that happen before you have seen the telemetry disclosure are held on your Mac and sent only once you have seen it and left the option on; if you turn beta telemetry off, the held events are discarded and none are sent. Each event is deleted from docktor’s endpoint 90 days after it is received.

Safe-mode events. If docktor fails to start several times in a row, it starts in safe mode with its optional system integrations paused. It then records startup.safe_mode_entered once, on the launch that enters safe mode (later launches that stay in safe mode don’t record it again), and startup.safe_mode_restored when you choose Restore normal. Both are held and sent like the events above. The entered event carries only how the previous launch ended (one of crash, unknown_unclean, clean, os_restart, app_updated, first_launch), how many launches in a row ended uncleanly (a number), and the app build number; the restored event carries only the build number, which tells us whether normal mode was restored. To tell how the previous launch ended, docktor keeps a small record on your Mac (in ~/Library/Application Support/docktor) of when the current launch started, the build, the macOS boot session, and the unclean-launch count, and after a launch that didn’t finish cleanly it checks whether macOS wrote a docktor crash report since then. That record and the crash-report check never leave your Mac; only the fixed labels above are sent.

Anonymous onboarding step beacon (respects the toggle). Because those events are held until you have seen the disclosure, they can’t show how many people leave during onboarding. To measure only that, docktor also sends a separate beacon as each onboarding step (welcome, picker, permissions) is reached. It is sent immediately, before you have seen the disclosure, but only while beta telemetry is on (the default): if you turn it off, no beacon is sent at all. The onboarding copy of the toggle sits on the final step, so on a first run the earlier step beacons have already been sent by the time you can switch it off there. Its entire contents are the step name, the app and macOS version, and the Debug-vs-Release flag: no install identifier, no session identifier, nothing else. The endpoint only adds it to a per-day, per-step, per-version counter, so all that is kept is a tally like “N reaches of the permissions step on this day on this version”; Debug builds are not counted. The counter measures reaches, not people. These tallies are pruned after about 400 days.

• Spotify — OAuth tokens are stored in your macOS Keychain and used to call Spotify’s HTTPS API for playback control and metadata. Separately, when you paste a Spotify playlist link into the Focus timer’s music settings, docktor sends that link to Spotify (open.spotify.com/oembed) to look up the playlist name. Nothing else is sent, and it only happens when you paste a link.
• Open-Meteo — the Weather widget calls Open-Meteo over HTTPS with your coordinates (or those of a location you saved); no API key or stable identifier is required.
• LRCLIB — only while the lyrics view is on screen (when it is shown, and on each track change while it stays shown), the playing track’s title, artist, album, and duration are sent over HTTPS to look up lyrics; nothing is sent while lyrics are hidden. No API key, account, or persistent identifier is used.
• Apple (geocoding) — MapKit / CoreLocation turns your coordinates into a place name, and turns a place you type into the Weather location search into coordinates, governed by Apple’s privacy policy.
• Sparkle update feed — docktor fetches a signed appcast over HTTPS on launch and about once a day; the request carries only your app and macOS version.
• Cloudflare — docktor’s feedback endpoint runs on Cloudflare Workers, with submissions stored in Cloudflare D1 and R2, governed by Cloudflare’s privacy policy.
• Resend — feedback triage alert emails are sent to the maintainer via Resend.

• Email: petercsauer@me.com
• LinkedIn: linkedin.com/in/petercsauer
• Issues: github.com/petercsauer/docktor-releases/issues