jetbrains-wakatime reports your coding activity from inside the IDE

A plugin that watches the editor, not a timer you start

WakaTime is described as an open source JetBrains plugin for metrics, insights and time tracking automatically generated from your programming activity.

The phrase automatically generated is the design. A conventional time tracker asks you to start and stop a timer, and the data is only as good as your discipline in remembering to. This plugin instead derives the activity from the events the IDE already produces, so opening a file, editing it and running something are the input, and the time and the language and the project are the output.

That has an obvious consequence, and the project does not hide it. What is measured is typing and editing, so a day spent reading documentation, in a design review, or talking to somebody about an architecture produces very little data. The dashboard is a picture of the code you wrote, and the readme says the activity is displayed on your WakaTime dashboard without making claims about what that picture is worth.

The plugin is open source, and the licence is BSD-3-Clause. The primary language is Java, which is what an IntelliJ Platform plugin is written in, and the repository is small: a src directory, a META-INF directory for the plugin descriptor, the WakaTime.iml module file, an AUTHORS file and the LICENSE.

The audience is a developer who wants to know where their own time went, and who is comfortable with the fact that the measurement is derived from editor activity and sent to a hosted service.

Installing it is five steps and one API key

The installation section is the shortest part of the readme and it is completely standard for a JetBrains plugin.

Inside the IDE you select Preferences, then Plugins, search for WakaTime, click the green Install button, and re-launch the IDE. Then you enter your API key in Tools, then WakaTime API Key, and click Save. After that, the readme says to use your IDE and your coding activity will be displayed on your WakaTime dashboard.

The API key comes from the WakaTime settings page, and the plugin is distributed through the JetBrains Marketplace under plugin id 7425, with badges for the version and the install count. So the whole install is a marketplace install, which also means JetBrains handles the update path, and the plugin is not something you compile or deploy.

Two details are worth noting for a first install. The re-launch step is not optional, because the plugin does not start collecting until the IDE restarts, and the key is entered through a settings dialog rather than written into a file, so a fresh machine needs the key pasted in again.

If you are working across several IDEs, note that the same key works for all of them, which is the point of the shared configuration described in the next section.

One .wakatime.cfg file for every WakaTime plugin

The configuration section is short and it is where the design becomes clear.

WakaTime for JetBrains IDEs can be configured via Tools, then WakaTime Settings. And for more settings, the WakaTime plugins share a common config file called .wakatime.cfg located in the user home directory, with the available options listed in the wakatime-cli usage documentation.

The shared file is the point. The plugin is not a self contained application with its own settings model; it is one front end for the wakatime-cli tooling, and the configuration that decides what gets sent, what gets filtered and how often the heartbeat fires lives in one file that every other WakaTime plugin also reads. So the same file that configures the JetBrains plugin configures the command line version and the editor plugins, and the settings that you would otherwise hunt for in a dialog are the same ones documented in the CLI usage page.

That design has an obvious benefit for a developer who already runs WakaTime, since the behaviour is identical everywhere and one file travels with you. For a developer who does not, it means the settings surface is a file rather than a UI, which is more powerful and less discoverable.

The uninstall instructions follow the same logic. You go to Preferences, then Plugins, find the WakaTime plugin and click Uninstall, and then you delete the ~/.wakatime.cfg config file. The plugin removal does not remove the shared file, because the file is not the plugin's, it is the user's.

Eleven IDEs, one plugin

The list of supported IDEs is longer than the repository title suggests, and the readme lists eleven: Android Studio, AppCode, CLion, DataGrip, GoLand, IntelliJ IDEA, PhpStorm, PyCharm, Rider, RubyMine and WebStorm.

The repository topics cover most of them, with an intellij-plugin topic alongside phpstorm-plugin, pycharm-plugin, webstorm-plugin, rider-plugin, rubymine-plugin, gogland-plugin, appcode-plugin, androidstudio-plugin and datagrip-plugin, plus time-tracking.

The reason one plugin covers all of them is that they share a platform and a plugin API, so the work is in the IDE integration layer rather than in eleven separate implementations. The thing the plugin has to understand is JetBrains activity, which is a single event model exposed to every IDE on the platform.

The homepage is wakatime.com/intellij-idea, and each IDE has its own page linked from the readme.

Proxies, debug mode and idea.log

The troubleshooting section is the most useful part of this readme, and it deals with the failure that anyone deploying this behind a corporate proxy will hit.

If you are using a proxy, the advice is to try excluding *.wakatime.com from using your IDE proxy. The screenshot in the readme shows the JetBrains proxy settings with that exclusion, and the reason is simple: the plugin is a client inside the IDE, so it inherits the IDE's network configuration, and many corporate proxy setups do not like the host that the plugin talks to.

Then the next step is to turn on debug mode from Tools, then WakaTime Settings, and restart the IDE. Debug mode is what turns a silent failure into a log line.

And there is the failure mode that catches people. If the plugin was not loaded, you will not have a WakaTime Settings menu, and in that case the readme tells you to check for error messages in the IDE's idea.log file indicating why the plugin could not load, reachable through Help, then Show Log, with a link to the JetBrains support article on locating IDE log files.

The last line points at the WakaTime CLI troubleshooting documentation for anything more general, which is the right place to look because the plugin is a front end for that tool.

What the plugin measures, and what it cannot tell you

There is a limit to the measurement that is worth stating plainly, because the dashboard is more persuasive than the underlying data.

The plugin derives its numbers from programming activity, which means the events the IDE reports while you work. Files opened, files edited, the language of those files, the project they belong to, and the time between them. That is a good description of typing, and a poor description of engineering.

Two things in particular are invisible to it. Reading, thinking, and discussing produce no editor events, so a day of design work and a day of typing are not comparable in the dashboard, and the tool has no way to know they happened. And since the data is generated from the IDE rather than from a timesheet, it measures one machine and one person's editing, which is why the project is framed around personal metrics and insights rather than around tracking a team's hours.

The other constraint is architectural. The plugin has to reach the WakaTime service from inside the IDE, over the network, and the proxy advice in the troubleshooting section is really a warning about that dependency. There is no offline mode described in the readme, and no local aggregation, so an IDE on a network that cannot reach wakatime.com produces no data, and the user has no way to tell from the IDE that anything is wrong.

That combination, a personal dashboard fed by editor events with a network dependency, is the tool's scope. It is good at what it measures and it should not be read as a record of what you did.

Maintenance, licence and who this is for

The repository is not archived, and the last push was on 2026-05-01, a little under six months before this writing. There are no GitHub releases published from the repository, which is normal for a JetBrains plugin, since the distribution channel is the JetBrains Marketplace and the Marketplace entry, plugin id 7425, carries the version and the install count.

So the release history of the plugin is on the Marketplace rather than in the repository, and the repository is where the code and the readme live. The readme also links the general WakaTime project, so the dashboard, the pricing and the wider product live elsewhere.

The licence is BSD-3-Clause, which is the permissive end and the standard choice for a plugin that a company installs into every developer's IDE.

Who should adopt it is easy to answer. If you want to see your own coding time per project and per language without maintaining a reporting pipeline of your own, and you are happy with the data leaving your machine, this is a good fit, and the eleven IDE coverage means a team with mixed tooling gets consistent numbers. If you need hours for billing, or per person accountability, or an audit trail, this is the wrong tool, because what it records is editing and what you would need is a claim about work. And if the environment blocks wakatime.com, the plugin silently does nothing, which is worth checking before you roll it out to a team.

Editorial conclusion

jetbrains-wakatime is worth installing if you already use WakaTime, or if you want per project, per language visibility on your own work without building a reporting pipeline, because the plugin covers eleven JetBrains IDEs with one shared configuration file and one API key. It is the wrong choice if you need team or business reporting, since the product is a personal metrics dashboard rather than a time tracking system with accounts and billing, and it is the wrong choice if the network path to wakatime.com is closed, because the plugin has to reach the service from inside the IDE. Before you install it, read the troubleshooting notes about proxies, and note that the last push was on 2026-05-01 with no GitHub releases published from the repository.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. Project website
4. README
5. wakatime/jetbrains-wakatime on GitHub