Time tracker data: where it lives and who can read it
· 7 min read
Time tracking data lives in one of three places: a file on your Mac, a company’s servers, or both. Who can read it follows directly from that. On your disk, it is you and whatever backs up your disk; on a server, it is the company, its staff with access, its subprocessors, and anyone it is legally required to hand data to. Find out which case you are in before you install, because the answer rarely changes afterward.
What the data actually contains
It is tempting to think of time tracking data as a column of hours. Look at the raw record of most trackers and it is much closer to a diary.
At the plainest level, it is a timestamp, an app name, and a duration, repeated thousands of times a week. That alone reveals your working hours, your days off, when you start, when you stop, how often you switch, and which tools you live in. Add window titles and it includes document names, email subjects, the names of people you message, and the titles of pages you read. Add URLs and it is a browsing history. Add idle detection and it knows when you went to lunch. Add screenshots and it is everything.
Even the plain version is sensitive. A year of timestamps is enough to tell whether someone was job hunting, working a second job, or taking a lot of sick days. So the question “who can read it” is not academic, and it applies even to trackers that record nothing but app names. The reason trackers collect the richer versions is covered in why most time trackers want your window titles.
Three places it can live
Only on your disk. The app writes to a file in your home folder and never sends it anywhere. Readers: you, anyone with access to your user account, and any backup that includes the file (Time Machine, a cloud backup service, a company device-management agent). If the Mac is personal and the backup is yours, that is the shortest list possible.
Only on a server. The app is a front end for a web service. Entries go up as you make them; the local copy, if there is one, is a cache. Readers: the company’s engineers and support staff to the extent of their access policies, the cloud provider hosting the servers, any analytics or support vendors the company shares data with, and governments or courts that compel disclosure. Plus you, while your account is active.
Both. A local file and a synced copy. This is the common case for trackers with an account. It has the reader list of the server case, with the added wrinkle that deleting one copy does not delete the other, and you can only verify the local one.
The phrase to look for in a privacy policy is “we store your data to provide the service.” That places you in case two or three. “All data is stored locally on your device” places you in case one, and it is rare enough that companies say it loudly when it is true.
How to find where a Mac app keeps its data
You do not have to take the product page’s word for it. The Mac will show you.
- Quit the tracker, so the file is in a settled state.
- In Finder, choose Go, then Go to Folder, and enter ~/Library/Application Support/. Look for a folder named after the app or the company.
- If it is not there, try ~/Library/Containers/ (for sandboxed apps; the folder is named with a reverse-domain identifier like com.company.app) and ~/Library/Group Containers/.
- Open the folder and look at the files. A .sqlite, .db, .json, or .csv file of any size is your record. Change the date on it by opening and closing the app to confirm it is live.
- If you find nothing, or only a file that stays the same size no matter how much you work, the record is remote. The app is sending entries up and keeping, at most, a cache.
The broader map of where apps keep things is in where Mac apps keep your data and how to find it.
Who can read it, case by case
Put the cases side by side and the difference is stark.
For a local-only tracker, the list is: you; anyone who can unlock your Mac or your user account; anyone who can read your backups; and, if the Mac is company-managed, whoever administers the management software. You control three of those four, and you know about the fourth.
For a server-backed tracker, the list starts with the same four and then continues: the company’s staff, governed by an internal access policy you cannot read; the cloud hosting provider; support and analytics vendors listed (or not) as subprocessors; a future acquirer of the company; and any authority that can compel the company to produce records. You control none of those, and the list can change without notice when the terms are updated.
What to do before you stop using a tracker
Leaving is where the data question becomes concrete, and it is worth doing in order.
- Export everything first, in the plainest format offered. CSV is ideal; it opens in any spreadsheet and will still open in twenty years. See export your time data to CSV and keep it forever.
- Check the export for completeness. Does it include the whole history or only the current period? Does it include the detail you care about, or only daily totals?
- If the app has a server, request deletion through the app or the privacy contact, and note the date. Most policies give a timeline.
- Delete the local copy: the folder you found in the section above, plus the app itself.
- If it had an account, close the account last, after the export and the deletion request, because some services wipe the export option the moment the account closes.
Punchcard: one file, on disk
Punchcard is a local-only tracker in the strictest sense. It records which app is in front (app names only, never window titles, document names, URLs, keystrokes, or screen contents) and at the closing time you set prints a paper receipt of the day. Everything it knows lives in one SQLite file at ~/Library/Application Support/Punchcard/punchcard.sqlite. You can open that file with any SQLite tool, export it to CSV from the app, or use “Burn the roll” to delete everything. It contains no networking code at all; the release build fails if a networking symbol appears. There is no account, no sync, no analytics, and no crash pings, so the reader list is the short one: you, your Mac, and your backups.
The limits are part of the same picture. Because there is no server, Punchcard cannot sync two Macs (a license covers two, but each keeps its own file), has no iPhone app, no team features, and no hosted backup. If your disk fails and you have no backup, the roll is gone. If those trade-offs suit your question, the data question is answered by design, and the procedure in the previous section collapses to “export the CSV and delete one folder.”
Questions
Does a local-only tracker’s data end up in iCloud?
Only if the file is in a folder you sync. ~/Library/Application Support is not synced by iCloud Drive by default, and Desktop and Documents are only synced if you turned that on. Time Machine and third-party backup tools will include it unless you exclude the folder.
Can my employer read a local file on a company Mac?
If the Mac is managed, assume yes. Device-management software typically has the access to read user files. A local-only tracker keeps the data off the vendor’s servers, not off a managed machine. Ask before installing on company hardware.
Is a CSV export enough to count as “owning” my data?
It is the practical definition. A format you can open without the app, containing the full history, at any time, is what ownership means in practice. A “download your data” button that produces a proprietary file or a partial range is a weaker version.