What developer time tracking is for
Before you pick a tool, it helps to be clear about why you are tracking at all, because the right method depends entirely on the reason. Developers track coding time for four common reasons, and they pull in different directions.
Quick Answer
Developer time tracking is measuring how long your coding work takes, and in 2026 there are four ways to do it: manual timers, editor plugins, git-based inference, and telemetry. Each answers a slightly different question, and the one most people reach for first (manual timers) is the least reliable. The short version: manual timers are honest in theory but forgotten in practice, editor plugins capture keystrokes but miss terminal and AI work, git-based inference gives a useful baseline but is no longer an accurate clock now that AI generates huge diffs in seconds, and telemetry measures real activity as it happens and is the only layer that stays accurate. The best setup combines a git baseline with telemetry so you get a number that is both accurate and easy to stand behind. This guide walks through each method, when to use it, and how to pick.
The first is billing: freelancers and contractors need defensible hours for invoices. The second is estimation: you want to know how long features really take so your next estimate is not fiction. The third is self-knowledge: where does your day go, and when do you do your best work. The fourth, increasingly, is proof: showing a client, an employer, or your future self what you genuinely shipped and how much of it was you versus an agent. In practice most developers want two or three of these at once, which is why a single manual timer rarely satisfies anyone for long. Hold your real reason in mind as you read, because it decides which trade-offs you can live with.
The four ways to track developer time
Here is the honest map of the options, so you can see the trade-offs side by side before we go deep on each. Each row is a real method with a real failure mode, not a product pitch.
| Method | What it measures | Strength | Where it fails | Best for |
|---|---|---|---|---|
| Manual timer | Whatever you remember to start and stop | Simple, explicit, no setup | You forget; estimates drift up | Occasional billing, quick spot checks |
| Editor plugin | Keystrokes and active file time in one editor | Passive, code-aware, per-language stats | Misses terminal, CLI, and agentic work; per-editor | Solo devs living in one IDE |
| Git-based inference | Sessions reconstructed from commit timestamps | No per-editor plugin, works from history | Commit size no longer maps to time, worse with AI | A quick baseline, a cross-check |
| Telemetry | Real activity events captured as you work | Accurate, covers terminal and AI sessions | Needs a lightweight tracker installed | Anyone who wants a number they can trust |
The pattern in that table is the whole point. The methods that need nothing installed are the least accurate, and the method that is accurate needs a small amount of software watching the work. There is no free lunch where a tool reads your true hours from thin air. Below, each method in turn.
Manual timers
Most developers start here, usually with a Toggl or Clockify tab open, because it feels responsible and it is easy to explain to a client. You hit start, you code, you hit stop, and the number is whatever you clicked. This is the point where reality diverges from intention. You forget to start after a coffee, you leave it running through lunch, and by Friday you are reconstructing Tuesday from memory. Reconstructed hours almost always round up, which is why manual timesheets tend to overstate real work.
Manual timing is not useless. For a developer who bills a handful of clearly bounded sessions a week, a timer you actually remember to use is fine, and the explicitness is reassuring to a client. But as your primary source of truth it is fragile, because it depends on the one thing humans are worst at during deep work: remembering to manage a stopwatch. If you want the honest version of why, manual timesheets lie walks through the overestimation in detail. For general timers specifically, see how Toggl and Clockify compare as developer options and the switching case in Clockify alternatives for engineering teams.
Editor plugins
The next step most people take is a passive editor plugin, and WakaTime is the one that defined the category. You install an extension, and it records active editing time and per-language stats without you starting anything. This is a real upgrade on manual timing, because it removes the human from the loop. If you have ever wanted a heatmap of which languages ate your week, this is where that comes from.
The catch is coverage. A plugin sees the editor it is installed in, and modern coding does not stay in the editor. You run builds and scripts in the terminal, you drive an agent like Claude Code or Codex from the command line, and you switch between two editors depending on the task. A per-editor plugin misses all of that, and it needs installing again in every tool you use. This is why the "no plugin" search intent exists at all, and it is worth being precise about what "no plugin" means: a git baseline needs nothing installed, and an editor-agnostic CLI tracker is one tracker across your tools rather than one plugin per editor. See coding time tracker without an IDE plugin for that angle, and if you are evaluating the plugin category itself, the best WakaTime alternatives and the DevClocked vs WakaTime comparison lay out the differences.
Git-based inference
If plugins feel like too much to install, the appealing idea is to skip tracking entirely and read your time from git, since the commits are already there. You can get a genuine baseline this way. A good git-based estimate does not count commits, because a commit can be five seconds or five hours. It reconstructs sessions by grouping commits that sit close in time and treating long quiet gaps as breaks, then estimates elapsed time from the shape of that activity.
Most "track time from git" advice skips the limitation that matters most: git records output, not effort, and in 2026 output and effort have come apart. An agent generates hundreds of lines and an enormous diff in seconds, so a large commit can represent almost no time, while a one-line fix can follow an hour of reading and prompting. The thing git can see, the size and timing of the diff, no longer maps to the thing you want, which is time spent. This is why a pure git tracker misjudges AI-assisted work: it is measuring the artifact, and the artifact stopped correlating with the hours. Treat git as a strong benchmark and a cross-check, never as an accurate clock. Tracking coding time from git and estimating hours from commits go deeper on getting the most out of the baseline without over-trusting it.
Telemetry
If git infers time after the fact from output, telemetry measures it while it happens, which is the only way to get it right. Telemetry means lightweight activity signals captured as you work: active editing, terminal sessions, and agentic coding sessions. Because it observes the work directly, it reflects elapsed active time regardless of how much or how little code resulted. It sees the hour you spent debugging that ended in a one-line change, and it sees that the giant AI-generated commit took two minutes, precisely the cases where the other methods are fooled.
In a world where code is cheap to generate, watching the work as it happens is the only reliable way to measure it, and that is what makes the number trustworthy. The cost is that telemetry needs a small tracker running, either a lightweight editor extension or an editor-agnostic CLI that also covers terminal and agent sessions. That is the trade you are making across the whole table: a little software watching, in exchange for hours you do not have to defend from memory.
How to pick a method for your situation
The right choice is rarely one method, it is a stack, and the stack depends on why you are tracking. Most developers land in one of a few situations, so match yourself to the closest one.
If you bill clients, accuracy is not optional and neither is defensibility, so you want passive capture rather than a timer you will forget, plus a record you can show. If you mostly want self-knowledge, an editor plugin or telemetry gives you patterns without any billing pressure. If you build heavily with AI, editor-only tools will undercount you badly, because so much of the work happens in the terminal and in agent sessions, and git will misread the diffs, so telemetry is doing the real work. And if you just want a rough sense with zero setup, a git baseline is a reasonable starting point as long as you remember it is approximate and drifts the more you lean on AI. The through-line across all of these: the more your hours need to survive someone else's scrutiny, the more you want measured activity rather than a self-reported number.
Common mistakes
A few errors show up again and again, and they are easy to avoid once named. The most common is trusting commit volume as a proxy for time, which was shaky before AI and is now wrong. The second is relying on a manual timer as the single source of truth, then quietly rounding up every reconstruction until the totals stop meaning anything. The third is installing a plugin in one editor and assuming it captures your whole day, when half of it happens in the terminal and in agent sessions the plugin never sees. The fourth is treating any of these numbers as proof when they are really claims: a self-reported timer or a padded commit graph proves nothing to a client or an employer. The fix in every case is the same move, measure the work as it happens and keep the record, rather than reconstruct it later and ask people to take your word.
Where DevClocked fits
Full disclosure: I build DevClocked, so treat this as the honest placement, not a verdict. DevClocked leads with leverage and output, measuring what you and your AI coding agents shipped, not just hours in an editor. The mechanism is the combination this guide keeps pointing at: a git baseline that needs no per-editor plugin, plus telemetry from a lightweight extension and an editor-agnostic CLI that covers terminal and agentic work, with a model that learns the relationship between your commits and your measured activity so the estimate calibrates over time.
Be honest about when it is not the answer. If you only ever bill one clearly bounded session a week and you reliably remember a timer, a plain timer is less to think about. If you want your entire non-coding workday tracked, a general tracker like RescueTime fits better, and WakaTime vs RescueTime covers that split. If you refuse to install any tracker at all, you are left with the git baseline alone, and you should treat it as approximate. DevClocked earns its place when your work is code, you want an accurate measure rather than a commit-count guess or a self-reported total, and you want that measure to double as a record you can stand behind, including for invoicing. See developer time tracking for invoicing for the billing workflow.
Related Guides
- Track coding time from git: how the git baseline works and why it is a benchmark, not a clock.
- 9 best time tracking tools for developers: the full ranked comparison across manual, plugin, and git-based tools.
- Coding time tracker without an IDE plugin: what "no plugin" really means and the editor-agnostic option.
- Estimate developer hours from commits: using the git benchmark for estimates and invoices, with the caveats.
- Developer time tracking for invoicing: billing from accurate, telemetry-backed hours.
