An automated time tracker runs in the background and logs what you're doing without any manual input. No timer to start. No timer to stop. No selecting a project from a dropdown before you're allowed to work. The computer already knows what app you're in, what window has focus, and how long you've been there — an automated tracker just captures that stream and makes it readable.
This is different from tools like Toggl or Harvest. Those are billing tools, and for billing they work well: you start a timer, label it, stop it, invoice the hours. For understanding your own patterns — where focus time actually goes, why some days feel productive and others don't, whether the six hours you think you spent coding was actually four — manual timers fail at the first hurdle. You have to remember to use them.
What Gets Tracked
The fundamental unit is an app switch. Every time you move from one application to another, the tracker logs the previous app, its window title, and how long you were in it. Idle detection — keyboard and mouse inactivity — strips out the time you were technically "in" an app but had walked away from the computer. What remains is active time, not calendar time.
xeve tracks this at the OS level on macOS and Windows. The macOS app is a Swift/SwiftUI menu bar process. The Windows app is a WinUI 3 system tray process. Neither is a browser extension or a web app that approximates tracking. Both sit at the layer where the window focus events actually happen.
From those raw events, sessions get categorized into nine fixed buckets:
- Development — editors, IDEs, terminals
- Productivity — docs, spreadsheets, project management
- Communication — Slack, email, video calls
- Browsing — any web browser session
- Entertainment — music apps, video, anything recreational
- Design — Figma, Sketch, image editors
- Writing — note-taking apps, writing tools
- System — OS utilities, system preferences
- Uncategorized — anything else
The categorization is automatic based on app name and bundle ID. You can add custom rules in settings, but the defaults cover most developer workflows without any configuration.
Coding Time Specifically
General app tracking tells you how much time you spent in VS Code. It does not tell you which project you were working on, which file, or whether you were actively typing or staring at a problem.
The VS Code extension solves this. It sends heartbeats as you type — per file, per project — so the coding dashboard shows session-level breakdowns: 2h 15m on the API server, 45m on tests, 20m in the config files. If you have multiple workspaces open across the week, each gets its own timeline.
The Claude Code hook does the same for AI sessions. xeve installs a shell-based heartbeat hook that fires whenever you're actively working with Claude Code, treating it as a separate tracked activity rather than lumping it into "Terminal" time. If you're spending four hours a day in agentic coding sessions, that shows up as its own category rather than disappearing into background noise.
Beyond the Screen
Time-on-screen data has a ceiling. It tells you what apps you were in and for how long. It doesn't tell you anything about the state you were in while using them — whether the two hours in the editor were sharp or fragmented, whether the afternoon Slack spiral correlated with a bad night of sleep.
xeve adds three external data streams to close that gap:
GitHub activity. Commits, pull requests, code reviews — synced daily. When you correlate GitHub output with tracked editor time, you get a ratio: how much focused coding time actually produced shipped work versus how much was planning, debugging loops, or rework. That ratio varies a lot by day and most developers have never looked at it.
Spotify listening history. Every track, timestamped. Useful mostly in correlation — whether you produce more during instrumental listening versus podcasts, or whether your highest-output sessions tend to be silent. The raw data is also just interesting to have: a full archive of what you listened to while building something.
Heart rate via Bluetooth. The macOS app and the iOS companion both support BLE heart rate monitors — Polar chest straps, Whoop, any standard HRM. Resting heart rate data alongside screen time data lets you ask questions most productivity tools can't: did the week where I logged 50 focused hours also show elevated resting HR? That kind of correlation isn't a medical answer, but it's information about sustainable pace that pure screen time data misses entirely.
The Correlation Engine
The dashboard has 19 auto-computed correlation pairs across tracked metrics. Sleep duration versus coding output. Heart rate versus focus time. GitHub activity versus late-night sessions. These aren't presented as causal claims — correlation isn't that — but over weeks of data they surface patterns that don't show up in any single day's numbers.
The most common thing people notice when they first look at a month of data: the gap between perceived coding time and actual coding time. Developers consistently estimate 20-30% more focused coding than the tracker logs. Some of that gap is genuine error in self-estimation. Some of it is that "working" includes a lot of Slack, email, and tab switching that doesn't feel like distraction in the moment but adds up to hours across a week.
The tracker doesn't tell you what to do about that. It just makes the gap visible.
How the Sync Works
App sessions queue locally in memory and sync to the backend every 60 seconds. If the sync fails — network issue, brief offline period — the sessions re-queue and go out on the next cycle. Nothing is dropped.
The sync cycle means there's no significant delay between working and seeing the data in the dashboard. By the time you've switched apps a few times and opened a browser tab, those sessions are already logged and categorized.
The tracker filters out a handful of OS system processes that produce noise without signal: loginwindow, ScreenSaverEngine, UserNotificationCenter. These show up in raw window focus data but add nothing useful to a developer's time picture.
xeve vs Timing vs Rize vs ActivityWatch
The space has a few established tools worth knowing.
Timing (Mac only) is excellent for freelancers who need to reconstruct billable hours from automatic tracking. It goes deep on file-path tracking and produces clean PDF reports for clients. If your goal is billing, Timing is hard to beat. If you want health correlations, coding-specific metrics, or Windows support, it stops there.
Rize is the closest cross-platform competitor. It runs on macOS and Windows, categorizes sessions automatically, and has a focus coaching layer with AI-powered insights. Good product. No coding-specific integration, no external data streams (health, GitHub, Spotify), and no API or MCP server for connecting it to other tools.
ActivityWatch is open source, completely free, and stores everything locally. If data leaving your machine is a concern, it's the right choice. The trade-off is that correlations, health integration, and the iOS companion aren't there — you're working with raw app usage data and writing your own analysis on top.
xeve is built for developers who want all of those streams in one place: app time, coding time, GitHub output, health, and music — with the correlations already computed and a dashboard you don't have to configure.
Getting Started
The macOS tracker is a menu bar app. The Windows tracker is a system tray app. Both start tracking automatically on launch with no configuration required for basic app usage data.
The VS Code extension is one install from the marketplace — it reads your active workspace and file and sends heartbeats with no additional setup. The Claude Code hook is a shell script that runs on session events; install instructions are in the xeve dashboard under Settings → Integrations.
The automated part is the point. The tracker runs, the data accumulates, and after a week or two you have enough history that the patterns start to show up — usually in places you didn't expect to look.