What a JetBrains time tracker can and cannot see
Before you install or enable anything, it helps to be precise about what a tool living inside your IDE is watching, because that boundary decides how accurate your number will be. A JetBrains time tracker observes the IDE process: which file is focused, when you are typing, sometimes which language and project you are in, and in the built-in case, which task you have marked active. That is genuinely useful, and most of it is passive, which already beats a manual timer you forget to start.
Quick Answer
To track time in a JetBrains IDE, you have three practical routes, and the right one depends on how much you need the number to hold up. The fastest is a passive plugin like WakaTime from the Marketplace, which records active editing and per-language stats across IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, and the rest without you starting a timer. There is also a built-in option most people forget: JetBrains ships a Tasks and Contexts feature with a Time Tracking tool window that clocks time per task while the IDE has focus. Both are useful, and both share the same blind spot. A JetBrains tracker only sees JetBrains. It misses the integrated terminal, standalone CLI work, and the agent sessions you run through Claude Code, Codex, or JetBrains' own AI Assistant and Junie, which in 2026 is often where a real share of the hours go. So the honest answer has layers. For a quick heatmap of your editing, a plugin or the built-in timer is enough. For hours you can trust and stand behind, you want telemetry from an editor-agnostic tracker with a git baseline as a cross-check. This guide covers every route, what each one captures, and how to pick.
The boundary is the IDE window itself. Most developers hit this the first time they check a plugin dashboard after a heavy day and the total looks thin. The reason is that modern work leaks out of the editor constantly. You run builds and tests in the integrated terminal, you drive an agent from the command line, you read docs in a browser, and you jump to DataGrip or a second IDE for one task. A JetBrains tracker counts none of that as coding time, because from its point of view the IDE is idle. IDE-based tracking measures IDE activity, which is a subset of your real work, and the subset keeps shrinking as more of the job moves to the terminal and to agents.
The four ways to track time in a JetBrains IDE
There are really four routes, and they differ in what they see and how much you have to trust them. Here they are side by side before we go deep, so the trade-offs are visible up front.
| Method | What it captures in JetBrains | What it misses | Setup | Best for |
|---|---|---|---|---|
| Built-in Tasks and Time Tracking | Time per active task while the IDE is focused | Terminal, CLI, agents, other apps, and untracked tasks | Enable in Settings, mostly manual | Billing against a specific issue you remember to switch |
| Editor plugin (e.g. WakaTime) | Active editing, per-language and per-file time | Terminal, CLI, agent sessions, other editors | Install from Marketplace, add API key | A quick passive heatmap of your editing |
| Git-based inference | Sessions reconstructed from commit timestamps | Effort behind small commits, misreads big AI diffs | Nothing installed in the IDE | An approximate baseline with zero setup |
| Telemetry (editor-agnostic tracker) | Real activity across IDE, terminal, and agents | Nothing structural, needs a tracker running | Lightweight extension or CLI | Accurate hours you can prove |
The shape of that table is the lesson. The two methods that install cleanly into JetBrains see the least of your day, and the method that sees the whole day needs a tracker that is not tied to the IDE at all. There is no option that reads your true hours from nothing. Below, each route in turn.
Route 1: the built-in task timer (already in the IDE)
Many developers do not realise JetBrains has a native answer here, so this is worth naming first. Under Settings, the Tasks and Contexts feature lets you open a task, optionally link it to a tracker like YouTrack or Jira, and the Time Tracking tool window will accumulate time against that task while the IDE is in focus. If you have ever needed to say how long a specific ticket took, this is the closest thing to a built-in stopwatch, and it needs no plugin.
The limitation is that it is task-scoped and focus-based, which means it leans on your discipline. It counts time only for the task you remembered to switch to, only while the JetBrains window is the active application, and it stops having any idea what happened the moment you drop into the terminal or a browser. In practice this makes it a decent record for deliberate, ticket-by-ticket billing and a poor measure of your true coding time, because the gaps it cannot see are exactly the ones that have grown. It is a manual timer with a nicer home, not passive tracking.
Route 2: an editor plugin (the fast passive path)
Most people who want tracking without babysitting a timer start here, and it is a reasonable place to start. You install a plugin like WakaTime from the JetBrains Marketplace, paste an API key, and from then on it records your editing passively across whichever JetBrains IDEs you use. If you have ever wanted to know which languages ate your week or how long a project has kept you in the editor, this is where those charts come from, with no behaviour change on your part.
The limitation is coverage, and it matters more every year. The plugin sees the JetBrains IDE and only that, so a terminal-heavy or agent-heavy day reads as light editing. It also does not travel cleanly: if you open the same project in VS Code or drive a task from the command line, that time is invisible unless you install and configure matching tooling everywhere you work. This is exactly why the "no plugin" search intent exists, and the phrase is worth being precise about. A coding time tracker without an IDE plugin means one editor-agnostic tracker instead of one plugin per IDE, or a git baseline that needs nothing installed, rather than no software at all. If you are weighing the plugin category itself, the best WakaTime alternatives lay out the options, and the DevClocked vs WakaTime comparison covers where an editor plugin stops being enough. There is also a WakaTime alternative page if you have already decided to switch.
Route 3: git-based inference (zero setup)
If enabling a feature or installing a plugin feels like friction, the appealing idea is to skip the IDE entirely and read your time from git, since the commits are already sitting in the repo. You can get a real baseline this way, and it works identically whether you commit from IntelliJ, PyCharm, or the command line. A good git-based estimate does not count commits, because a commit can represent five seconds or five hours. It reconstructs sessions by grouping commits that sit close together 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 applies to JetBrains work as much as anywhere: git records output, not effort, and in 2026 those two have come apart. An agent generates a huge diff in seconds, so a large commit can represent almost no time, while a one-line fix can follow an hour of debugging in the IDE. The thing git can see, the size and timing of the diff, no longer maps cleanly to the thing you want, which is time spent. Treat git as a strong benchmark and a cross-check, never as an accurate clock. Tracking coding time from git goes deeper on getting the most out of the baseline without over-trusting it.
Route 4: telemetry from an editor-agnostic tracker (the accurate path)
If a plugin measures the editor, the built-in timer measures the task you flagged, and git infers time after the fact from output, telemetry measures the work while it happens across your whole environment, which is the only way to get an honest number. Telemetry here means lightweight activity signals captured as you work: active editing in the JetBrains IDE, yes, but also terminal sessions and agentic coding sessions. Because it observes the work directly rather than the IDE window alone, it catches the hour you spent in the integrated terminal and the agent run that produced a giant commit in two minutes, precisely the cases where a plugin, a task timer, and a git estimate all get it wrong.
This is what makes a JetBrains time total trustworthy. In a world where code is cheap to generate and much of the work happens next to the IDE rather than inside it, watching the real activity is the only reliable measure. 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 work. That is the trade across the whole table: a little software watching, in exchange for hours you do not have to reconstruct or defend from memory. If you also spend time in VS Code or a fork, the same logic carries over, which is what VS Code time tracking and tracking Cursor usage walk through, and an editor-agnostic tracker is what lets one number span all of them.
How to pick a route for your situation
The right choice is rarely one route, it is usually a small stack, and it depends on why you are tracking at all. Most JetBrains developers land in one of a few situations, so match yourself to the closest.
If you want a sense of your editing habits with the least effort, the WakaTime plugin is fine, as long as you remember it is undercounting your terminal and agent time. If you bill against specific tickets and you are disciplined about switching tasks, the built-in Time Tracking tool window gives you a per-issue record without any extra install, though it will still miss the work you do outside the focused IDE. If you build heavily with AI, whether through JetBrains AI Assistant, Junie, or an external CLI agent, an IDE-only tracker will undercount you badly, because so much happens in the terminal and in agent sessions the plugin never sees, and git will misread the diffs, so telemetry is doing the real work. And if you want a rough number with zero setup, the git baseline is a reasonable starting point as long as you treat it as approximate and expect it to drift the more you lean on AI. The pattern across all of these: the more your hours need to survive someone else's scrutiny, the more you want measured activity rather than a partial or self-reported figure.
Common mistakes
A few errors show up constantly with JetBrains tracking, and they are easy to avoid once named. The most common is assuming the plugin's total is your real coding time, when it is only your in-IDE time, so a terminal-heavy day looks lazy on the chart. The second is relying on the built-in task timer and forgetting to switch tasks, which quietly attributes hours to the wrong ticket or to nothing at all. The third is trusting commit volume as a proxy for effort, which was shaky before AI and is now wrong. The fourth, and the one that quietly matters most, is treating any of these numbers as proof when they are really claims. A plugin heatmap, a task timer you drove by hand, or a padded commit graph proves nothing to a client or an employer on its own. The fix in every case is the same move: measure the work as it happens across the whole environment, and keep the record, rather than reconstruct a partial view 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 keystrokes in one IDE. The mechanism is the combination this guide keeps pointing at: a git baseline that needs no per-IDE plugin, plus telemetry from a lightweight extension and an editor-agnostic CLI that covers the terminal and agent sessions JetBrains plugins miss, 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 all you want is a per-language heatmap of your editing and you never leave IntelliJ, the WakaTime plugin is less to think about and does that job well. If you bill strictly ticket by ticket inside one IDE and you are diligent about the task switch, the built-in Time Tracking tool window may be all you need, with nothing extra installed. If you refuse to run 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, a real share of it happens in the terminal and in agents rather than the IDE, and you want an accurate measure that doubles as a record you can stand behind. A developer dashboard is where those hours turn into something you can read and show.
Related Guides
- Developer time tracking: the complete guide: the four methods to track coding time and how to pick, in depth.
- Coding time tracker without an IDE plugin: what "no plugin" really means and the editor-agnostic option.
- VS Code time tracking: the same routes and trade-offs for the other major editor.
- Track Cursor usage: tracking time and agent sessions in the VS Code fork.
- Track coding time from git: how the git baseline works and why it is a benchmark, not a clock.
- Best WakaTime alternatives: the ranked comparison if the plugin route is not covering your work.
- Developer dashboard: turning tracked hours into something you can read and show.
